Comment by westurner
5 days ago
Root certificates need expiration dates for the same reason that LetsEncrypt certs need an expiration date: risk of cert compromise and forgery increases over time.
Over a long enough timeline, there will be vulns discovered in so much of the software that guards the CA certs in RAM
> risk of cert compromise and forgery increases over time.
And what if the certificate is compromised before it expires? Right, there's a revocation mechanism for that. So why expire them then if they can be revoked anyway IF they get compromised?
The reason why domain TLS certificates expire is that domains can change owners. It makes sense that it should not be possible for someone to buy a domain for one year, get a non-expiring TLS certificate issued for it, and then have the ability to MitM its traffic if it ever gets bought by someone else later.
Domain certificates are sent as part of the connection handshake, so them expiring is unnoticeable for the end users. However, root certificates rely on the OS getting updates forever, which is unsustainable. Some systems lack the ability to install user-provided root CAs altogether, and some (Android) do allow it but treat them as second-class.
Because the most dangerous secret is one that has been compromised and you don’t know it. This sets a time limit for their usefulness. Sometimes the stories about terrible default choices that are insecure sink in and architects choose a better path.
Also, details about the certs and the standards for them change over time. This makes it easier for the browser venders (via the CA forum) to force cert providers to update over time.
1 reply →
The revocation mechanism is basically just a list of revoked certificates. Without expiration dates, those lists will grow infinitely.