BlogJune 17, 20202020, Apple iOS, Browsers, CA/Browser Forum, Certificate Templates, Certificate Validation, PKI, Standards, Watch Out
Changes to SSL/TLS Certificate Validity Periods – September 2020
by Mark B. Cooper
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.
Expand Your PKI Visibility
Discover why seeing is securing with revolutionary PKI monitoring and alerting.
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!
Related Resources
Blog
October 4, 2024
Announcing the October 2024 PKI Spotlight® Release
PKI, PKI Spotlight
Blog
August 16, 2024
To Revoke or Not to Revoke: Balancing Security with Performance and Operational Complexity
CA, Certificate Authority, Certificate Revocation List, CRL, OCSP, PKI, VPN
Blog
August 1, 2024
PKI Insights Recap – Past, Present, and Future of PKI with Brian Komar
PKI, PKI Insights
Mark B. Cooper
President & Founder at PKI Solutions, Leading PKI Cybersecurity Subject Matter Expert, Author, Speaker, Trainer, Microsoft Certified Master.
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.
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.
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.
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.
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.
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. ”
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.