Certificate Lifespans

Transport Layer Security uses certificates to identify the server (and optionally the client) that you are connecting to, to ensure that the connection has not been intercepted. In the early days of the web there was no maximum lifetime for these certificates, and it was not uncommon to come across certificates that were marked as valid for 10 years.

Over the last decade there have been efforts to reduce the maximum lifetime for certificates, and several debates around why this should be done – and in some cases there has been quite significant pushback against these changes.

Key Takeaways

• Understand the benefits to certificates with short lifetimes
• Understand the resistance to enforcing shorter lifetimes and ways to mitigate these concerns.

The History

The Certificate Authority Browser Forum (CA/B Forum) is a voluntary organisation formed from Certificate Issuers, Brower vendors, and other organisations, that promote better industry guidelines on issuing and managing digital certificates.

The CAB produces a document known as the “Baseline Requirements (BR)” which sets certain requirements on certificates, for them to be accepted as valid. For example, the first version of the BR specified:

Certificates issued after the Effective Date [1 July 2012] MUST have a Validity Period no greater than 60 months.

So as of mid-2012, certificates must be valid for no longer than 60 months. However, a few years later this was reduced again:

Certificates issued after 1 April 2015 MUST have a Validity Period no greater than 39 months.

There were a few small exceptions to this rule, such as where a system or software would be difficult to patch or replace without “substantial economic outlay”, but generally as of early 2015, the maximum certificate validity period was set at 39 months.

Less than 2 years later, in February 2017, another CAB Forum ballot would be held, this time to reduce the lifetime to just 398 days (approximately 13 months). However, this did not pass, with 24 of the 28 Certificate authorities voting down this ballot (with 1 yes vote – Let’s Encrypt, and 3 abstaining). Support from the browsers was mixed, with 2 Yes votes, 2 No votes (Microsoft and Qihoo 360) and 1 abstaining (Apple).

This was quickly followed by a vote to reduce the maximum age to 825 days, which passed with zero no votes (4 abstentions). This set the limit, as of March 2018, to a maximum validity period of 825 days.

In 2019 a second vote was held , again with the intention of reducing certificate lifespans to 398 days. Again, it failed.

It should be noted that all 7 “Certificate Consumers” voted yes. There was consensus between Apple, Cisco, google, Microsoft, Mozilla, Opera, and 360. The vote failed due to the Certificate Issuers voting broadly against the proposal. With 20 No votes to 11 yes notes (2 abstentions). So, whilst the Browsers clearly wanted it, the CAs were strongly against it.

This led to an interesting move from Apple: they would enforce the limitation themselves regardless (https://support.apple.com/en-gb/102028). Apple declared that their software would not accept a certificate that was issued on or after 1 September 2020 if it had a lifetime longer than 398 days. This was quickly followed by Google announcing in June that they would enforce the same 398 day limitation. Mozilla announced it in July 2020.

The Benefits of Short Certificate Lifetimes

The CA/B Ballot to reduce the lifespan to 398 was fully supported by the Browser vendors, with the Certificate Authorities putting up strong resistance, highlighting strong differences in the interests of both groups.

However, there are strong benefits to reducing the lifespan of certificates.

Certificate Revocation

The first benefit is that certificate revocation is not effective. Revocation is supposed to be the process by which you can notify everyone that your certificate private key has been stolen and therefore should no longer be trusted. However, this process is a little messy and some of the methods have problems such as privacy concerns.

There are generally two ways to check if a certificate has been revoked, the first is to check a Certificate Revocation List (CRL), which are published by the CAs to include all of their certificates that should no longer be trusted. The second method is an Online Certificate Status Protocol (OCSP) check which is an online check where the CA is asked if a specific certificate should still be trusted. However, the OCSP check can cause a privacy concern, as it may disclose to the CA a list of all website domains that you visit – and some people, understandably, don’t like the idea that a third party gets a list of all the sites they visit.

Additionally, if CRL/OCSP checks fail, then a lot of software will continue with the connection regardless, a sort of “soft-fail” and this is problematic as a threat actor may be able to cause these systems to fail intentionally. When they are most needed.

Another problem is that not all software untilises these features, and they don’t all use them in the same way. For example, Google Chrome does not use CRL or OCSP check by default, and instead they introduced the idea of CRLSets, which is now the primary mechanism for how Chrome handles the requirement to block certificates in emergency situations.

That’s a lot of words to say that the current process for certificate revocation is problematic and reducing the lifespan of certificates is another method of reducing the effectiveness of stolen certificates, which is generally good.

Security Improvement

Another benefit to short certificate lifetimes is the fact that when the industry wants to enforce a new improvement, such as moving away from weaker signing algorithms, these changes will reach systems more quickly.

Additionally, it allows for faster key rotation. With those older certificates that were valid for 10 years, those systems would be using the same keys for a decade. Whereas with shorter certificate lifespans those keys could be rotated much more frequently.

Encouraging Automation

The most effective way to drive down those validity periods is to implement automation such that certificates are generated and installed automatically. A lot of organisations are already doing this, thanks to providers such as Let’s Encrypt (who sets the Validity Period to 90 days!), although they’re not the only ones offering this capability.

Whilst initially the burden of renewing and installation certificates may seem to outweigh the benefits laid down here, given that the entire process can be automated – the effort required ongoing is minimal. In fact, Let’s Encrypt lists only two reasons as to why they enforce a 90-day lifetime on their certificates: it limits the damage from a key compromise or mis-issuance, and it encourages automation.

In 2023, Chrome stated their intention to move to enforce a maximum validity period of 90 days.

The Pushback Against Short Certificate Lifetimes

As stated above, when shorter lifespans are proposed it is often the Browser vendors that are pushing for this change and the Certificate Issuers are frequently against these changes.

For example, in 2019 DigiCert published a blog post regarding the change from 825 days to 398 days stating the following regarding the potential benefits of shorter certificate lifespans:

“So what is the proposed security benefit that justifies this cost? It is far from clear that there is any at all.”

They also stated the following on the potential burden on system administrators that shorter lifespans bring:

“Rapidly reducing certificate lifetimes to one year, or even less, has significant costs to many companies which rely on digital certificates to protect their systems.”

Overall, they stated their position as being against reducing the certificate lifespan to 1 year:

“These changes make it significantly more difficult for many companies to protect their internet traffic and customers, with no benefit, and therefore DigiCert has no choice but to oppose these changes.”

In another post regarding Google Chrome’s proposal to reduce lifespan to 90 days, DigiCert seemed to have changed their stance on shorter lifespans:

“We previously supported shorter certificate lifetimes for a long time as one and two year certificates improve security and enable us to make updates to the certificate ecosystem faster.” ()

However, further into the article their original views are evident again:

“While shorter validity periods may questionably improve security, the change certainly would come with significant burdens.”

“Furthermore, the consequences of mismanaged certificates and outages can be detrimental and an increasing workload for certificate lifecycle management could increase the possibility of human error leading to outages.”

Therefore, given the above, the discussion comes down to one key idea:

“Does a shorter certificate lifespan bring a security improvement that outweighs the burden of implementing and managing that lifespan?”

The security benefits are listed above but I’d summarise them as a small improvement to weaknesses in the revocation process, faster key rotation, and faster deployment of security improvements such as more secure signature algorithms. I’d also note that moving to an automated approach reduces the burden of managing your certificates – something you should look to do regardless of how you feel about the lifespan issue.