Did you know that when the Web PKI was first established, it was a bit like the Wild West, with virtually no technical requirements for becoming a certificate authority? This approach worked initially, as the idea of PKI on the web was new and only a few CAs existed. However, as the internet expanded, so did the number of trusted certificate authorities and the variety of practices they employed. As the ecosystem matured, the browsers managing the list of trusted CAs began defining minimum requirements for participation. They ultimately started requiring that CAs undergo third-party audits to meet those standards.
This decision to rely on third-party audits ultimately led to the creation of the CA/Browser Forum, the organization where CAs and browsers meet to discuss the evolution of shared basic operational practices and the minimum requirements that all CAs would meet. Bringing together a pre-existing group like this required the initial rules to be incredibly permissive because if we wanted to see CAs ultimately converge, we had to accept the lowest common denominator of practices and then begin the long journey of bringing those practices to a more consistent, secure and auditable state.
To put this into the context of an issue we are all familiar with when the CA/Browser Forum was established in 2005, there was no maximum validity period for certificates. It was not uncommon to see end entity certificate validity periods being issued for up to 10 years!
Early Efforts to Shorten Certificate Validity Periods
The debate over the appropriate length of TLS certificates is as old as the CA/Browser Forum itself. Back when certificates sometimes lasted 10 years (or longer), acquiring a certificate might have literally involved visiting the CA's office to complete the enrollment! Over time, as the practices of certificate authorities became more standardized, it became possible to begin reducing the validity of certificates to something that more closely matched what was seen as a best practice at the time. That said even then there was pushback, this pushback largely stemmed from the fact that CAs didn’t offer ways to programmatically acquire certificates which meant every time someone had to renew a certificate they had to go and complete many manual steps.
As the world moved to the cloud, customers began asking CAs for APIs to enable automation, and ultimately, standards started to emerge. The evolution of these APIs for certificate enrollment, combined with the development of Certificate Lifecycle Management software, enabled organizations to automate the manual toil of certificate management. While the adoption of these approaches didn't really take off until the early 2010s, by 2016 they had been deployed broadly enough to support the maximum certificate validity being reduced to 3 years. But why not shorter? The answer was simple: there was concern that website operators were still not ready for even that change.
A few years later, in 2018, the maximum was reduced again to 2 years (actually 730 days). This maximum was a function of negotiations between the browsers, which were worried about the security of the internet, and the certificate authorities, who largely wanted to keep things as they were.
In 2019, there was an attempt to further shorten the validity period of TLS certificates to just one year (actually 398 days), but this proposal did not pass initially. It wasn't until 2020 that Apple decided to enforce this limit on certificates recognized in its Safari browser, effectively setting a new de facto standard that other industry players began to follow. Ultimately, the CA/Browser Forum updated its requirements accordingly.
Today, most TLS certificates issued are valid for 90 days or less, a transformation driven by advances in standards, automation, Certificate Lifecycle Management, and numerous incidents that have highlighted the need for agility in managing the certificate lifecycle—not just as a desirable feature but as a requirement to keep systems online.
For example, the DigiNotar incident in 2011 resulted in all certificates that were legitimately issued by that CA having to be replaced with ones from another CA quickly. Similarly, consider the April 2014 Heartbleed incident, where a vulnerability allowed a remote attacker to essentially ask a web server to surrender its private key. This event led to the revocation and re-issuance of millions of certificates, a task that was heavily dependent on effective Certificate Lifecycle Management.
Additionally, the 2018 distrust of Symantec by major browsers forced its customers to switch certificate authorities virtually overnight, underscoring the critical importance of having flexible and responsive certificate management processes.
These are just a few of the incidents that raised the visibility of the need to have a robust certificate lifecycle strategy, which led the industry, without formal requirements, to today's majority of certificates being issued with 90 days or less validity periods.
What is happening now is Browsers and certificate authorities are again working together to adjust the maximum requirements to match what has become the norm, a maximum certificate validity of 90 days.
There have been several discussions at CA/Browser Forum meetings about reducing the maximum validity of TLS server authentication subscriber certificates to 90 days. Notably, at the June 2022 meeting, and since then Mozilla and Google expressed forward-looking perspectives on this change, which was again raised by Apple in October 2023.
Although no formal proposal has been made yet, the ongoing public discussions indicate a proposal is likely to be seen this year. Ultimately, the decision-making process within the CA/Browser Forum involves consensus building through discussions and formal voting, requiring agreement from both browser vendors and CAs to pass any proposal. Therefore, even if a proposal is made, it is possible—like the 2019 ballot for a 398-day maximum certificate validity period that failed—that this proposal could also fail.
I believe it won’t, but even if it does, the question is not if but when this change will happen. For those of you who have not yet deployed a Certificate Lifecycle Management solution that would enable you to be ready for this change, the good news is that once these things pass, there is usually an implementation period of about a year before CAs are prohibited from issuing certificates beyond the new maximum.
This will be the first major change in certificate validity within the WebPKI that truly aligns the maximum duration to what is commonly seen in the majority of certificates in use, but that's not the only benefit of this change. Some of the additional advantages include:
- If a certificate is compromised, it reduces the opportunities for misuse of compromised keys.
- Maintains constant verification of domain control, reducing the risk that changes in domain control could expose sites to impersonation.
- Automation decreases the likelihood of outages and security breaches.
- Facilitates faster and more effective responses to security breaches where key compromises may have occurred.
- Automation cuts long-term expenses associated with manual certificate management and emergency revocations.
- Automation of routine certificate management tasks allows IT staff to focus on strategic initiatives.
- Enables browsers to implement security improvements and respond more swiftly to CA misissuance patterns.
Don’t Delay: 5 Urgent Actions to Prepare for 90-Day TLS/SSL Certificates
Myth: Shorter Validities Increase Operational Burden
Reality: While it might seem that more frequent renewals could increase the workload, the reality is quite the opposite when automation is in place. Automated systems for certificate management dramatically reduce manual oversight and potential human errors. These systems can seamlessly handle renewals, ensuring that certificates are updated without any administrative headache.
Myth: Automation is Prone to Failures
Reality: Automation technology has matured significantly, and when implemented with proper checks, it greatly minimizes risks. Effective monitoring and alert systems can quickly identify and rectify failures, often before they impact operations.
Myth: The Transition to Shorter Validities is Costly and Complex
Reality: Transitioning to a system with shorter certificate validities involves an initial setup, but the long-term benefits significantly outweigh these upfront costs. These benefits include reduced exposure to security breaches, less downtime, and lower long-term management costs due to decreased manual intervention.
Myth: Mandating shorter maximum validity periods will disrupt my internal certificate and PKI.
Reality: Historically, when browsers implement these changes, they apply them only to certificates issued by publicly trusted CAs. Therefore, unless you're conducting split-horizon DNS deployments where a publicly trusted certificate is used for an internal resource—and for some reason, it's a long-lived certificate—your internal certificate usage will remain unaffected if this change goes into effect.
Myth: Browsers need CA/B Forum approval to roll out shorter validity periods
Reality: The CA/Browser Forum establishes baseline requirements, but browsers have the authority to adopt stricter standards to enhance user security.
Myth: All certificates will be impacted by a shortening of maximum validities
Reality: Certificates issued by private CAs, such as those used within an organization's intranet or for internal applications, would not be subject to any new validity restrictions unless they are publicly trusted.
As we have seen, the evolution towards shorter certificate validities in all certificate types is a response to both opportunity and necessity, much like the industry's shifts that took place after the Heartbleed incident. Here are a few practical steps to prepare:
- Understand Where You Use Certificates: As they say, you cannot manage what you cannot measure. Start with an inventory of all your certificates to understand their use within your infrastructure. This helps prioritize deployment areas and identify which teams in your organization to collaborate with.
- Deploy Automation: Implement automation solutions for certificate lifecycle management. Tools that support automated certificate management not only streamline operations but also reduce the risks associated with manual handling and human error.
- Monitor Automation: Regularly monitor your automation systems to ensure they function correctly. Effective monitoring helps preempt potential disruptions and ensures continuous protection.
- Monitor for Misissuance: Utilize Certificate Transparency (CT) logs to monitor and verify the certificates that are being issued for your domains. CT logs provide an open framework for monitoring and auditing SSL certificates in real-time. Watching for unexpected issuances by CAs you do not regularly trust or even ones you don't expect can help you respond swiftly to potential threats.
Adopting shorter certificate validities with automation not only aligns with current security best practices but also prepares organizations for future challenges. It promotes agility, enhances security, and supports continuous compliance with evolving web standards. We now have well over a decade of experience as an industry in rolling out and managing certificates automatically, so with a little bit of planning and organizational support, you will be able to tackle this challenge without a hiccup.