On public TLS certificates lifetime

 September 13, 2020

On September 1st, 2020, the maximum lifetime of TLS certificates signed by Public Certificate Authority got reduced to 13 months. How did we arrive here, and what’s to come? Let’s start from understanding who decides the maximum lifetime of certificates and many other limitations around them.

Who decides the TLS certificate guidelines

Ultimately, the client (often a browser or an operating system) identifies the certificate as trustable or not (based on the CA that signed it as well as many other parameters), so the client can decide which parameters to look for and which values are acceptable and which are not. This clients’ freedom makes the whole situation very messy since every client can decide their own set, and a subset of the options accepted by every client can be very small if not empty.

Since the various CAs are different companies (and often competing among themselves), the problem of coordination is not a new one. In 2005, Melih Abdulhayoğlu, founder and CEO of Comodo Security, proposed to create a voluntary consortium of Certificate Authorities, browser creators, and other companies related to the Public Key Infrastructure (PKI). In November 2005, the first meeting of The Certification Authority/Browser Forum (CA/Browser Forum) took place in New York.

Since the large majority of PKI stakeholders are represented in the CA/Browser Forum, it is in a unique position to be able to mediate the stakeholders’ wishes and to create guidelines that are then (voluntary) followed by everyone.

To ensure that everyone’s interests (with additional focus on CAs interests) were preserved, to pass any ballot, a proposal has to obtain at least 66.6% of positive votes from the CAs and at least 50% of positive votes from the browsers.

A little bit of history

Historically, many Certificate Authorities (CAs) did provide signatures for certificates up to 60 months (5 years) in length. I remember that it was common for CAs to offer signatures for:

• 1 year
• 2 years
• 3 years
• 5 years

This offering changed in 2014, when the CA/Browser Forum decided, among many other things, that all certificates signed after April 01st, 2015 should not have a signature validity longer than 39 months ( 3 years, 3 months). This change meant that 5 years certificates were no longer issuable. If you are wondering why they decided for 39 months and not 36 months, they made this decision to allow CAs to sign the certificates for a more extended period than the period advertised to the user to simplify the customer operations of certificate rotation at the end of the certificate lifetime.

The reduction to 39 months of maximum certificate length was not going to last for an extended period, though. On February 24th, 2017, the Ballot 185 to reduce the maximum length of certificates to 398 days (1 year, 33 days) failed, because no CAs (except for Let’s Encrypt) voted in favor even though 50% of Browser voted in favor. On March 02nd, 2017, with the successful vote of Ballot 193, it was decided that the maximum length of a certificate should have been 825 days (2 years, 95 days) for all certificates signed from March 01st, 2018 onward.

On September 10th, 2019, Ballot SC22 was proposed. This ballot was proposed to reduce to 398 days (1 year, 33 days), as Ballot 185 submitted a couple of years ago. The result this time was more positive: 11 CAs voted positively, but since 20 voted negatively (and 2 abstained), the ballot failed. In this ballot, all 7 voting browsers voted positively.

What happened in 2020

On March 03rd, 2020, Apple unilaterally announced that their software will not trust any certificate signed after September 01st, 2020 if the length was longer than 398 days (1 year, 33 days). On June 22nd, 2020, a patch to Chromium (the open-source base of Google Chome) implemented the same limitation that Apple announced a few months prior.

As a result of those actions, the Ballot SC31 was proposed on July 2nd, 2020, to officialize this change as well as other client-specific limitations. The ballot passed on July 16th, 2020.

What this all means

I think that Apple’s decision to ban certificates longer than 398 days that was contrary to the CA/Forum ballot that happened less than six months prior highlights the reality of who makes decisions on what the CA can and can not do. This event also clearly highlights that some players (this time was Apple, but I think that Google is in a similar situation) do not worry about using their power position to enforce their agenda.

Now, the real question is: what is their agenda on certificates lifetime?

Obviously, I do not have the crystal ball, so I can only speculate. Speculating on Apple’s plan on certificates lifetime is relatively hard, I think, since I’ve not found anything “peculiar” about their usage of TLS certificates. They do buy off-the-shelf one-year-long certificates from DigiCert (and maybe others) and seem to use them similarly to many other companies. The only thing that I think is worth noting is that in the last few years, Apple is positioning itself as a secure-first company, so I think they will try to be as strict as their strictest competitor or - if possible - even stricter.

If you look at Google, I think the picture is very different.

• Google is a Let’s Encrypt sponsor. Let’s Encrypt is a publicly trusted Certificate Authority that provides free 90 days certificates in an automated way
• Google has its own CA (Google Trust Services) that is trusted by the majority of browsers and operating systems, and it is cross-signed by many other CAs
• The certificates signed by Google Trust Services are all 85 days longs, as far as I can see

I think that all of those indicate what Google thinks it’s a sensible lifetime for certificates: 85 to 90 days.

I expect Google and Apple to push for 90 days as the maximum certificates lifetime in the next few years, with or without the consent of the CA/Browser Forum.