TLS Certificate Lifetime Limit Drops Again - to 398 days from 2020-09-01

From today, most web browsers will reject TLS Server Certificates which are

• Signed by Globally recognised CAs
• Issued today (2020-09-01T00:00+0) or later
• Which have a lifetime > 398 days

Certificates issued by a Private CA which your browser has been instructed to trust are unaffected by this change.

The maximum acceptable lifetime of these certificates has been reducing over time; from ten years to five years to three years to two years, and now to 398 days.

Why Reduce Maximum Certificate Lifetime?

The theory is that the less time for which a certificate is in use, the less time there is to compromise it. But this theory is badly flawed because of the processes used by many organisations, and because of what “compromising it” actually means.

A Brief Reminder

The components we need to understand here are:

1. A KEYPAIR generated by the organisation; one of the pair is PUBLIC and one of the pair is PRIVATE.
2. Identifying information - most critically the hostname part of a URL in general.
3. A CERTIFICATE AUTHORITY
4. The TLS CERTIFICATE itself, including a valid-from and valid-until date/time.

It is the last of these which is critical; it contains the public key from (1), the identifying information from (2), and is signed by a private key belonging to (3) to assert the binding of the public key to the identifying information.

The certificate itself (4) is public - a web server hands it out to anyone. The only parts which need protecting are the Certificate Authority's private key (which is their entire business so they should be good at this) and the organisation's private key (corresponding to the public key in the certificate).

The Illusion

And here is the problem: when renewing a certificate which is due to expire, many organisations still simply reuse their existing keypair by generating a new CSR (Certificate Signing Request) using the existing key material. Yet it is not the lifetime of the certificate which really matters - it is the amount of time for which the same private key is used. I've seen private keys in use for scarily long periods - ones so old that they were almost certainly compromised years ago by HeartBleed, for example.

The benefit of shorter certificate lifetimes cannot be realised unless new key material is used each time a new certificate is requested.

“Good and Well-Managed TLS”

This is a phrase I use often, but it needs to be understood that these are two separate things. Good TLS can be badly managed, and poor TLS can be well-managed. You need both Good TLS and Well-Managed TLS if you want real security.

Good TLS

Good TLS is about using appropriate protocol versions and ciphersuites. Currently the protocol version would be TLS 1.2 or later. SSLv1,v2,v3 are far outwith the definition of Good TLS, as are TLS 1.0 & 1.1 now. And you should be allowing only strong ciphersuites, and preferring ciphersuites which are ephemeral - these will be the only ones supported from TLS1.3 onwards in any case.

Well-Managed TLS

Well-Managed TLS is about having good processes around the protection of the private key, and good processes around the life-cycle of key material - and not reusing key material for new certificates is a basic element of this.

Summary

Whilst we should in general welcome the 398-day limit, organisations need to make sure that their operational processes are up-to-scratch otherwise they will gain nothing from this reduction.