Maximum HTTPS certificate lifetime to be 1 year soon

In February 2020 at the CA/Browser Forum in Bratislava, Slovakia (and later officially), Apple has announced that starting September 1st, 2020, maximum TLS certificate lifetime in Safari (and probably in the whole macOS and iOS and all apps) will be just 1 year, 398 days exactly. Apple's change has been followed by both Chrome and Mozilla later that year. That's very good news. But why?

Apple has effectively done what the majority of certification authorities didn't want to do: shorten the maximum validity of issued certificates to cca one year. And even if other browsers have not announced anything similar (yet?), certificates valid for more than one year are basically dead. And by certificates I mean leaf certificates issued by publicly trusted certification authorities.

A bit of history

Maximum TLS certificate lifetime in browsers today is 825 days (a bit more than 2 years), was 39 months (3 years, 3 months) up until March 2018, and in the early days you could have a certificate for 5 years or even 10. EV certificates were always capped at 2 years maximum (825 days since March 2018, 27 months before).

In September 2019, a ballot reducing lifetimes of all certificate types to just 398 days failed. All browsers from the CA/B Forum voted yes but only a third of the CAs liked the idea and that was not enough.

Regardless of the outcome of the ballot, some CAs have decided to limit the maximum validity of issued TLS certificates to 1 year anyway. Let's Encrypt is issuing 90-day certificates (and recommends renewal after 60 days) since day one.

If you want your certificate to be trusted in Safari (and probably other macOS/iOS browsers too) after September 1st, 2020, you'd need to use a certificate issued for 1 year or less. Otherwise your users might see errors like NET::ERR_CERT_VALIDITY_TOO_LONG when visiting your site.

Capping certificate lifetimes in browsers was sort of expected but I was personally betting on Chrome being the first. Google has announced the same certificate lifetimes change in June, followed by Mozilla in July.

The same month a ballot has passed that has changed Baseline Requirements to say that beginning September 1st, 2020, CAs must not issue certificates with lifetimes longer than 398 days. Some authorities couldn't be really bothered and have issues roughly a hundred certificates with longer lifetimes anyway.

Certificate revocation (is broken)

Capping certificate lifetimes is generally a good idea for several reasons: the main one probably being that some browsers omit the online certificate status checks.

You can try it in your browsers by visiting revoked.badssl­.com – my Firefox blocks the page (SEC_ERROR_REVOKED_CERTIFICATE), Chrome on both Windows and iOS as well (NET::ERR_CERT_REVOKED) but both Firefox and Chrome running on Android load the page just fine. Some time ago, my Chrome on Windows has loaded the page too, even though the certificate has been revoked almost right after it has been issued.

To check the validity of the certificate with the CA, browsers would need to download CRLs (Certificate Revocation Lists) and these can get huge and would block page loads. Which I guess would lead to let's disable HTTPS to make the site faster! Browsers could also send a request to OCSP (Online Certificate Status Protocol) servers but these can go down sometimes and then what. To load the page or not to load the page.

OCSP Stapling is yet another option. In this case, the request is sent by the server, and for the next X days, the response will be stapled to the certificate, so browsers will get both the certificate, and its status. But OCSP Stapling is not reliable, TLS Feature (OCSP Must Staple) cannot be used because for example nginx will send a response back without a stapled OCSP status if it hasn't fetched one yet.

Instead, browsers have employed different push update technologies to check the certificate status. Firefox has OneCRL and a new thing being tested right now called CRLite – a technology that can represent all revoked certificates with an initial download of 10 MB (over 30M certificates, less than 1 byte per revocation) followed by daily asynchronous updates of 580 KB on average. Chrome uses CRLSets but those don't contain all revoked certificates.

Seems the surest thing to do is wait until the certificate expires and create a new one with new keys. And waiting 1 year at worst is still much better than waiting 2 years at worst. But even waiting 1 year is too long so we should further continue with capping the lifetimes.

EV certificates (considered harmful)

The online status checks are a bit more complicated as each browser does them (or not) differently, based on certificate types (EV/DV) and some other things. Find more details and graphs and numbers in these posts by Aaron Peters and Matt Hobbs.

TL;DR is that you don't want to use those “green” EV certificates because they're not only wasted money (browsers have moved away the company name previously displayed next to the URL so at the first sight, these certificates look like regular DV certificates) but they will also slow down your page load times.

For EV certificates, Chrome always sends a request to the OCSP server, even if the certificate has an OCSP staple. Firefox skips online certificate checks when OCSP Stapling is used and the browser has recently checked the revocation status online with the CA ¯\(°_o)/¯

In case of DV certificates, Chrome always skips the online checks, Firefox skips them when the certificate has an OCSP staple. OCSP Stapling ❤

Certificate Transparency logs

There's another reason for short lifetimes: Certificate Transparency, a system for logging HTTPS certificates. Each certificate has to be logged into 2 or more logs (depends also on the certificate lifetime) to be accepted by Chrome. But what if one of the logs will be disqualified which has already happened? The log will not be no longer qualified immediately but let's say in a few months after the removal announcement. But with longer lifetimes, the probability that the log will be disqualified during the certificate's li­fetime, goes up – effectively rendering the certificate useless because it will no longer meet the browsers' criteria.

Scott Helme writes about even more reasons: signature algorithm changes, key rotation etc.

Long story short, we want certificates with shorter lifetimes and Apple has sort of managed to cap them at 1 year, thanks! There are almost no reasons left to purchase 2-year certificates now and while you can still do it, soon you don't want to. Buying them would equal throwing money out of window and there are better things to use them on. Like Scott's HTTPS training. Or mine if you're in CZ. Or 🍻. Or all of it.

Personally, I'm happy with 90-day certificates from Let's Encrypt, issued automatically (that's important), renewed 3 weeks before their expiration date (that's also important, in case the automated renewal fails – and that happens, mostly because of me – I still have a few weeks left to fix it), and I also use OCSP Stapling. To get the certificates I use Certbot (supports various Unix-based OSes, and there's beta for Windows), called by my wrapper.

Do you know there was a proposal for “STAR” (Short Term Auto Renewed) certificates that would expire after a few hours, a few days, or at a limit a couple of weeks?

---

Recommended reading

• EV Certificates Make The Web Slow and Unreliable says Aaron Peters
• The impact of SSL certificate revocation on web performance by Matt Hobbs
• Scott Helme shows ~25% of all HTTPS sites will be impacted by this change
• The CRLite paper