2024-01-07
TLS certificate expiry times are fundamentally a hack
Famously, TLS certificates expire, which even today can take websites offline because they didn't renew their TLS certificate in time. This doesn't just affect websites; people not infrequently create certificates that are supposed to be long lived, except sometimes they make them last (only) ten years, which isn't long enough. When people argue about this, let's be clear; TLS certificate expiry times, like most forms of key expiry, are fundamentally a hack that exists to deal with the imperfections of the world.
In a spherical and frictionless ideal world, TLS certificate keys would never be compromised, TLS certificates would never be issued to anyone other than the owner of something, TLS certificates could be effectively invalidated through revocation, and there would be no need to have TLS certificates ever expire. In this world, TLS certificates would be perpetual, and when you were done with a website or some other use of a TLS certificate, you would publish a revocation of it just to be sure.
We don't live in a spherical and frictionless world, so TLS certificates expire in order to limit the damage of key compromise and mis-issued certificates. That TLS certificates expire only imperfectly limits the damage of key compromise, not only because you have to wait for the certificate to expire (hence the move to shorter and shorter lifetimes) but also because there's generally nothing that stops you from re-using the same key for a whole series of TLS certificates. Since we don't have effective certificate revocation at scale, both mis-issued certificates and certificates where you know the key is compromised can only really be handled by letting them expire. If they didn't expire, they would be dangerous forever.
(If you're a big place, the browsers will give you a hand by shipping an update that invalidates the required certificates and keys, but this isn't available to ordinary mortals.)
This isn't particularly specific to TLS; other protocols with public keys often have the same issues and adopt the same solution of expiry times (PGP is one example). There are protocols that use keys without expiry times, such as DKIM. However, DKIM has extremely effective key revocation; to revoke a key, you remove the public part from your DNS, and then no one can validate anything signed by that key (well, unless they have their own saved copy of your old DNS). Other protocols punt and leave the whole problem up to you, for example SSH keypairs.
(Some protocols have other reasons for limiting the lifetime of keys, such as making encrypted messages 'expire' by default)
The corollary of this is that if you're dealing with TLS certificates (or keypairs in general) and these issues aren't a concern for you, there's not much reason to limit your TLS certificate lifetimes. Just don't make their lifetimes be ten years.
(My current personal view is that there are two reasonable choices with TLS certificate lifetimes. Either you have automated issuance and renewal, in which case you should have short lifetimes, or you have manual issuance and rollover, in which case they should be as long as you can get away with. TLS certificates that live for a year or three and have to be manually rolled over are the worst of both worlds; a key compromise or a mis-issuance is dangerous for a comparatively long time, and the rollover period is long enough that you'll have issues keeping track of it and doing it.)