Maximum validity of TLS certificates is now 398 days

And, possibly, 90 days in future

Anyone who has ever browsed the internet should be aware of the small padlock icon on their browser’s address bar. It is an indication that the content is loaded securely, and any information provided on the web page will be securely transmitted to website’s servers. There are two parts to this padlock though, (i) browser makes sure no one is impersonating the website by verifying the server’s TLS certificate, and (ii) browser negotiates session keys with the server and encrypts all bytes sent to it.

To verify the server’s TLS certificate though, a chain of trust is used, with the root certificates of Certificate Authorities (CA) included in the browser as the trusted ones. When a web server presents its TLS certificate, the browser follows the chain and checks if it ultimately leads to a signature by trusted root certificate. One should note that all Certificate Authorities are treated equally, ie., Certificate issued by one authority is equally trusted as another authority.

All these certificates, including the root certificates, have a validity period beyond which they shouldn’t be trusted. One may wonder, who decides these validity periods? It used to be decided, until recently, by a ballot in CA/Browser Forum, whose members are the popular browser vendors and the certificate authorities. Starting September 1st, 2020, Apple Safari, Google Chrome and Mozilla Firefox will stop recognizing newly generated certificates with validity period more than 398 days. How did we get here?

TLS Certificate as Data

A decade ago, the TLS certificates were simple data files in X.509 format. If you needed to buy one from a certificate authority, all you had to do was pay for ‘X’ years, download the certificate file and place it on the server. And, typically, you don’t touch those files for several years. This was possible until a few years ago.

The browser vendors have since took interest in reducing the lifetime of the certificates, due to problems in certificates issued by CAs and in deprecating weak ciphers. This put them at loggerheads with the Certificate Authorities, as evidenced in Ballot 185 (Feb ‘17). One thing to note here is that only one CA voted for the motion, against 24 other CAs. That CA was none other than Let’s Encrypt.

Let’s Encrypt provides free TLS certificates that are valid for 90 days, which can be renewed automatically, through the ACME protocol. This requires an ACME client to be installed on the servers though, to periodically check and renew the certificate. The motion (Ballot 185) to limit the lifetime of TLS certificates doesn’t affect Let’s Encrypt at all, as their certificates are valid only for 90 days.

Timeline

We are here because of the update provided by Apple in a CA/Browser Meeting (Feb ’20). Apple unilaterally decided to enforce a limit on certificate validity. The minutes and presentation (Slide 12) are self explanatory,

Apple is moving to enforce a policy change capping the lifetime of certificates to 398 days.

There is a history to this though, a plan to reduce the lifetime of certificates to 398 days first failed with Ballot 185 (Feb ’17). Following which, the lifetime was reduced to 825 days, likely as a compromise, with Ballot 193 (Mar ’17). And, the second attempt to reduce the lifetime to 398 days also failed with Ballot SC22 (Sep ’19).

Argument

Apple has published an article on the subject, About upcoming limits on trusted certificates (Mar ‘20). The primary argument for the change is to improve web security for users. The core issues are explained well in Ballot SC22 — Benefits of reduced lifetime, a few points are as follows,

• Implementation issues cause improperly formed and validated certificates
• It can take four and half years for certificate problems to be resolved
• CRLs and OCSP are not viable at Internet scale
• Misalignment of certificate lifetime with Domain Name System (DNS)

Apart from the above mentioned points, having witnessed Heartbleed vulnerability, SHA-1 deprecation and TLS 1.0/1.1 deprecation, the effort to make the overall system more dynamic is beneficial. However, only time will tell whether this will improve web security.

It is likely that the problem shifts to server maintainers. Consider the recent Let’s Encrypt CAA Rechecking Bug, the idea of revoking more than 1 million certificates doesn’t sound like improving web security.

Evolution of TLS Certificate into an Application

There is a high possibility that the browsers will enforce the TLS certificate validity of just 90 days, in the not so distant future. This will essentially mean, TLS certificates cannot be managed without automation. And, hence, they will cease to exist as simple data files. It will mark an end of era for TLS certificates.

In the future, ACME clients will manage TLS certificates, and getting TLS certificates to work on servers will become synonymous with getting ACME client to work on them. All the downsides of the ACME client, such as installation issues, dependency issues, maintenance and so on, will befall on the once simple data file which was a TLS certificate.

At 0th Root, we provide solutions to secure internal web applications of organizations with TLS client certificates. We have already integrated Certbot ACME client into our product 0th Root Secure Network — 0SNet, to obtain Let’s Encrypt TLS server certificates for managed web applications.

0th Root Secure Network — 0SNet provides a triple layer of security with TLS client certificate verification, along with authentication and authorization. It provides a certificate manager, a user manager for authentication and a role based access controls system for authorization.

Know more at www.0snet.com