Testing upcoming Safari cert validity changes

I can comment of the first question. In regards to, "What defines 'user-added or administrator-added Root CAs'?"

This shorten validity period only affects certificates created with a root that already exists in the trust store of the device. If you have an enterprise root that is added to your device via MDM or for user testing, you will not be affected. The policy applies if the server’s certificate relies on a chain of trust that ends in the CA root that’s built in to the OS trust store.

In regards to testing with Safari, I would keep an eye on the Safari Technology Preview release notes as the September 1st deadline starts getting closer.

Matt Eaton

DTS Engineering, CoreOS

meaton3 at apple.com

Matt,

Thanks kindly for your prompt reply. For some reason the forums had defaulted to Noticiations "On", but all of the checkboxes -- including email -- were unticked, so was never notified of a response.

Both of your replies are very helpful.

> "This shorten validity period only affects certificates created with a root that already exists in the trust store of the device. If you have an enterprise root that is added to your device via MDM or for user testing, you will not be affected. The policy applies if the server’s certificate relies on a chain of trust that ends in the CA root that’s built in to the OS trust store."

We add the cert as part of our .pkg installer to allow a successful SSL connection back to our app from the browser. So although it doesn't "ship with the device" it is added to the System Keychain on install (or via profile on mobile), removed on uninstall.

We've baked in our own renewal process (we use Jetty, which offers fantastic live cert replacement support) but we've noticed in previous iterations of shorter cert lengths, the entire OS would enforce this policy.

For those reasons, we're trying to decide if:

• We just shorten the length for all certs in anticipate of something like Ballot 193 happening again (but for this newer, shorter span)
  -- OR --
• We just stay within the current 825 day requirement.

If our System cert will continue to work for 825 days after this change without unintended side-effects we'll keep that standard. (we understand certs installed before this time will continue working, but our certs are part of our installation process, so we'd like to avoid the influx).

> "In regards to testing with Safari, I would keep an eye on the Safari Technology Preview release notes as the September 1st deadline starts getting closer."

Ok, I'm linking the actual release notes for others: https://developer.apple.com/safari/technology-preview/release-notes/

Is it safe to say that this change will be spelled out in the release notes for the version which includes it? If not, is there a support path to obtain this information from Apple?

I cannot say with 100% certainty this will appear in the release notes. If you do not see anything in the release notes as we get closer to September 1 send a ping on this thread and I can take a closer look.

| Is it safe to say that this change will be spelled out in the release notes for the

| version which includes it? If not, is there a support path to obtain this information

| from Apple?

Matt Eaton

DTS Engineering, CoreOS

meaton3 at apple.com

Hi,

@meaton Per recommendation, I'm pinging you 2 months later hoping to find out the path to verifying the new -- shortened -- CA cert behavior on Safari.

I've read the Release Notes for the Technology Preview but I still cannot seem to find mention of this change.

I'd also rest assured knowing that this stament is guaranteed to be correct:

-- "This shorten validity period only affects certificates created with a root that already exists in the trust store of the device."

Our certificate is generated just-in-time using a CA<--->intermediate<--->SSL to be compliant with Firefox, then installed using security add command line interface. It sholud not qualify as "Already existing in the trust store of the device", but having a way to confirm this prior to the change would vastly improve the confidence of our prodcut for the future of Safari.

Best regards,

Thank you for the follow up. I do not have anything new in to share in regards to a testing date for this change in Safari Technology Preview.

If are using a root that exists in the trust store already on the device I would plan for this change. If you are using a certificate from a user-added or administrator-added Root CAs, this change will not affect you.

| I'd also rest assured knowing that this stament is guaranteed to be correct:

|

| -- "This shorten validity period only affects certificates created with a root that

| already exists in the trust store of the device."

|

| Our certificate is generated just-in-time using a CA<--->intermediate<--->SSL to be

| compliant with Firefox, then installed using security add command line interface. It

| sholud not qualify as "Already existing in the trust store of the device", but having a

| way to confirm this prior to the change would vastly improve the confidence of our

| prodcut for the future of Safari.

Matt Eaton

DTS Engineering, CoreOS

meaton3 at apple.com

Thanks. I'll mark this as resolved for now and plan accordingly. Meanwhile if the feature makes it into a release (either through release notes or silently) having a unit test to prove the app will survive this update would be the most favorable outcome.

Despite the response from Apple stating the following:

"This change will not affect [...] administrator-added Root CAs."

This change seems to have affected the cabforum, specifically SC31, which seems to make no mention of this administrator-added exception.... https://github.com/cabforum/documents/pull/195

Granted, SC31 pertains to issuers, not the applications honoring these rules, but according to Mozilla, they're already prepared to honor this quoting:

a) If that ballot passes, then the requirement will automatically apply to Mozilla’s Root Store Policy by reference.

With SC31 merged combined with an email I've received from DigiCert, I can only assume this ballot has passed, quoting:

[...] all Certificate Authorities are required to stop issuing 2-year TLS/SSL certificates. The new industry-allowed maximum validity will be 1 year (398 days). 

This leads me to believe that Safari may actually be the ONLY browser to allow the 825 day requirement in the edge-case that it was installed by an administrator.

Although this makes the question no-longer Apple-specific, any insight or information is appreciated as any organization attempting to keep ubiquity to the users needs to make an informed decision -- especially considering that the change was in large part spearheaded by Apple.

This leads me to believe that Safari may actually be the ONLY browser to allow the 825 day requirement in the edge-case that it was installed by an administrator.

This assumption was false, at least for Edge and Chrome, quoting Microsoft's tech community:

@stesch79 These changes apply to certificates that are rooted to a public CA trust anchor. Certificates that are rooted to a private PKI CA (“locally-trusted anchor”) are not limited this way.

I'm still waiting to hear back from Firefox.

Thank you for keeping this thread alive as the CA Browser Forum continues to meet on this topic.

This change seems to have affected the cabforum, specifically SC31, which seems to make no mention of this administrator-added exception....

Is your concern that the validity period for certificates from in-house or user managed CAs will be affected by SC31 because it is not explicitly called out in the pull request?


Matt Eaton
DTS Engineering, CoreOS
meaton3@apple.com

I am chiming in on a old post. We have issues with internal CA signed certificates being restricted by this time limit, Root CA and issuing CA certificates have been imported manually to Catalina keychain but certificates signed with those are rejected if their validity period exceeds 825 days. Safari refuses completely to connect to internal systems with such certificates, Google Chrome complains about certificate being invalid but lets use user to bypass error.

Internal root CAs are in System keychain, and Trust is set to Always trust for all functions. I am at loss what is wrong here.

@tphakala

When was the issued certificate that is failing created?

If you are unable to come to resolution here it would be best to open a TSI so I can look deeper into what is happening here.


Matt Eaton
DTS Engineering, CoreOS
meaton3@apple.com

Hi Matt,

One of failing certificates was created in August 2019, one of them has been created in March 2020. I will look into TSI, thanks for heads up on that.

@tphakala

Thanks for the heads up. If you submit a TSI, respond back with the ID and I will keep an eye out for it on my end.


Matt Eaton
DTS Engineering, CoreOS
meaton3@apple.com

I don't know the exact process of submitting a TSI, but I managed to submit a issue through Feedback assistant. ID for that is FB8877676, tested on BigSur Beta and Catalina.

@tphakala

Thanks for opening a bug report, I took a look at your sysdiagnose and did see:

Code Block text
2020-11-02 04:14:35.644-0800 trustd[349:10491] [policy] Non-system-trusted leaf validity period longer than 825 days and issued on or after 1 July 2019
2020-11-02 04:14:35.644-0800 trustd[349:10491] [policy] cert[0]: ValidityPeriodMaximums =(path)[]> 0
2020-11-02 04:14:35.645-0800 trustd[349:10491] [policy] Non-system-trusted leaf validity period longer than 825 days and issued on or after 1 July 2019
2020-11-02 04:14:35.645-0800 trustd[349:10491] [policy] cert[0]: ValidityPeriodMaximums =(path)[]> 0

However, I could not find any markers on whether this was coming from your local Safari traffic or another certificate on the system. The reason this log caught my eye is because it is relatively close (within a few minutes) to when you took the screen shot attached to your bug and because your leaf certificate has an expiration of 10/13/2025, which is greater than 825 days. See this requirement for trusted certificates in iOS 13 and macOS 10.15:

Additionally, all TLS server certificates issued after July 1, 2019 (as indicated in the NotBefore field of the certificate) must follow these guidelines:

TLS server certificates must have a validity period of 825 days or fewer (as expressed in the NotBefore and NotAfter fields of the certificate).

Also note that the original certificate trust requirements mentioned on the top of this thread were regarding 398 days, and not for user-added or administrator-added Root CAs.

<https://support.apple.com/en-us/HT211025>

As for opening a TSI, you can always open one here with your developer account.


Matt Eaton
DTS Engineering, CoreOS
meaton3@apple.com