It was recently announced that Google Chrome will be joining Apple Safari in implementing a change to publicly trusted SSL/TLS certificates. This change, however, will impact organizations operating their own internal PKI as well.
While the change was initially submitted to the official CA/Browser Forum, the vote failed last year. However, both Apple and Google have unilaterally announced that as of September 1, 2020, their browsers will only trust SSL/TLS certificates valid for 398 days or less (consider this 1 year, with a 10% fudge factor).
Since Google and Apple represent the large majority of browsers in use (over 80%), their adoption of this change makes it a near industry standard regardless of the CA/B Forum and other browser behaviors.
This is similar to the impact on internal PKIs we saw as the industry moved from SHA1 to SHA256 as well as the change in 2018 as the industry moved from 3-year certificates to 2-year certificate maximums.
Any existing SSL/TLS certificates you have will remain valid as long as they were issued PRIOR to September 1, 2020. Any certificates issued on that date or later, must have a validity period no longer than 398 days. This will not impact certificates used for other purposes since browsers wouldn’t be involved – such as Domain Controller certificates, RDP, Client Authentication certs for WiFi/VPN, etc…
So at this point, you should be aware of the need to change your SSL/TLS certificate templates on or before September 1, 2020, to reflect this new shortened validity period.
We do recognize the impact this will have for many internal organizations as most SSL/TLS certificates are manually enrolled and renewed. This shortening from 2 years to 1 year will double that enrollment effort. If you aren’t already using or reviewing a Certificate Management solution, now might be a good time to do that. We would be happy to discuss the options with you further as well of course!
21 Responses
If google handle this the same way apple handles this it not relevant for private CAs
https://support.apple.com/en-us/HT211025
This change will affect only TLS server certificates issued from the Root CAs preinstalled with iOS, iPadOS, macOS, watchOS, and tvOS.
Well, yes and no. For Apple and Safari, they control and know the contents of their trust store and can make this distinction. For Chrome, they don’t have their own trust store and thus don’t know if a trusted root is a public or private CA. So as a result, Chrome affects all SSL/TLS certificates in this way. So, if you are only using iOS devices with Safari you won’t be affected internally. If you use IE and Windows OS, you won’t be affected. But if you use Chrome on any OS, you will be affected. At least for now.
Chrome knows if a certificate is from a user installation or if it’s default trusted
https://github.com/chromium/chromium/blob/ccd149af47315e4c6f2fc45d55be1b271f39062c/net/cert/known_roots_win.h
Chrome has used that distinction during the SHA1 deprecation:
https://www.chromium.org/Home/chromium-security/education/tls/sha-1
Well, the last statement is no longer valid. Google issued a statement where they clarify how they handle 1yr TLS policy: https://chromium.googlesource.com/chromium/src/+/master/net/docs/certificate_lifetimes.md#upcoming
Specifically: This will only apply to TLS server certificates from CAs that are trusted in a default installation of Google Chrome, commonly known as “publicly trusted CAs”, and will not apply to locally-operated CAs that have been manually configured.
On Windows, Chrome uses Windows Certificate Store and differentiate private and public (members of Microsoft Root Program) CAs via looking at different stores.
On non-Windows, Chrome ships their own root certificate bundle.
Apple statement is similar: only public CAs are affected https://support.apple.com/en-us/HT211025.
Specifically: This change will affect only TLS server certificates issued from the Root CAs preinstalled with iOS, iPadOS, macOS, watchOS, and tvOS.
Mozilla’s statement is not very clear: https://blog.mozilla.org/security/2020/07/09/reducing-tls-certificate-lifespans-to-398-days/. They don’t mention whether only pre-installed roots are affected, or custom roots are too.
That is the way it is supposed to work. We found many times Chrome misidentified trusted roots and internal SHA1 PKI infrastructures – still to this day, are flagged as untrusted. Same requirement for SAN only names.
Interesting. Have you identified the reason for that?
Might be a good idea to file a bug for chromium.
PS:
This Policy must be set
https://cloud.google.com/docs/chrome-enterprise/policies/?policy=EnableSha1ForLocalAnchors
(Edit)
PPS:
SHA1 was only support until chrome 72 even for enterprise CAs
We are still waiting on official notes from the CA/B Forum, but Dean Coclin announced the decision on Twitter: https://twitter.com/chosensecurity/status/1270819404452937729
From what I’m reading, it doesn’t sound like this will have any affect on validity periods for privately issued intermediary/root certificates. Does anyone know if if that’s the case, or if those will need to be shorted as well?
That is the official word. What I was pointing out was that in the past we saw changes such as SHA2 requirements and SAN only subject names target public CAs but found collateral impact to internal PKI issued certificates. So out of an abundance of caution, we are advising customers to be aware in case there is an unexpected impact after the September 1 date.
Mozilla is leaning towards implementing the same rule:
https://github.com/mozilla/pkipolicy/issues/204
https://groups.google.com/forum/#!msg/mozilla.dev.security.policy/J9IC3FgRatw/nNH9KRW3AQAJ
A CA/B Forum vote through unilateral decisions! Thanks Dean.
Hi mark,
Thanks for the post.
https://chromium.googlesource.com/chromium/src/+/ae4d6809912f8171b23f6aa43c6a4e8e627de784
Also here they state “Enforce publicly trusted TLS server certificates…”
I guess we will need to wait for the beta’s to see if there is some impacts on private CAs too.
Is this going to affect Internal generally PKI Certificates as well or just Public Generated Certificates?
That is still an uncertain issue. Lots of comments about this, while the manufacturers are intending this to be for public certificate chains only, we have continued to see issues in the past with other similar changes that wound up affecting internal certificates.
Thanks PKIGuy for your comments.
This statement from Chrome is quite clear that the 1 year policy will not be forced onto locally added/private Root CA’s:
https://chromium.googlesource.com/chromium/src/+/refs/changes/90/2258690/2/net/docs/certificate_lifetimes.md
“This only applies to the set of CAs that are trusted by default by Google Chrome, and not CAs that are operated by an enterprise and that have no certification paths to CAs that are trusted by default. ”
Also Apple and Mozilla make these statements:
https://support.apple.com/en-us/HT211025
“This change will not affect certificates issued from user-added or administrator-added Root CAs. ”
ttps://blog.mozilla.org/security/2020/07/09/reducing-tls-certificate-lifespans-to-398-days/
https://groups.google.com/d/msg/mozilla.dev.security.policy/EPTMdyIKcYg/ZTXu_jfCBQAJ (Latest comment)
Why should we not trust these statements?
No reason not to trust their statements, but there are grey areas. Many customers purchase and use internal certificates from public CAs – these would obviously be affected. Some customers have subordinated or managed PKIs that MAY or may not chain to a trust public root. While it looks like a dedicated CA to them, it would be affected if the provider is included in the list of publicly trusted CAs. Additionally, in the past, we have seen similar statements regarding SHA1 deprecation, and SAN only requirements that were intended for public CAs also unintentionally affect internal CAs. So we are simply advocating organizations to be aware of the pending change and be on the lookout for potential impact.
Issues to be aware of indeed, thank you!
Is there any update to this? Is Safari / Firefox / Chrome enforcing the validity period to internal certificates?