If a certificate has a limited duration of, say 5 years, but it gets somehow compromised after 2 years, waiting the 3 remaining years for it to get invalid is not a real solution to the breach problem. (3 years is eternity in IT, I guess)
Also, if the encryption method gets cracked (à la WEP), you also need to update everything immediately.
What are the advantages to limit the validity in time (except for the issuer to make money on a regular basis, I mean)?
The technical reason is to keep CRL size under control: CRL list the serial numbers of revoked certificates, but only for certificates which would otherwise be still valid, and in particular not expired. Without an end-of-validity period, revoked certificates would accumulate indefinitely, leading to huge CRL over time.
However, since network bandwidth keeps on increasing, and since modern revocation uses OCSP which does not suffer from such inflation, this technical reason is not the main drive behind certificate expiration. In reality, certificates expire due to the following:
Inertia: we set expiration dates because we have always set expiration dates. Traditions, in information security, often lead to dogma: when security is involved, people feel very inhibited when it comes to changing long-standing habits, in particular when they don't understand why the habit is long-standing in the first place.
Mistrust: ideally, certificate owner should seek a renewal when technological advances are such that their keys become inadequately weak (e.g. they had 768-bit RSA because it was fine back in 1996). But they don't. Expiry dates enforce renewals at predictable moments, allowing for gradual, proactive evolution.
Confusion: expiry dates can be viewed as a translation of housekeeping practices from earlier military cryptosystems, before the advent of the computer, where frequent key renewal was required to cope with the weakness of such systems. Some people think that certificate expiration somehow implements that practice (which is obsolete, but hey, Tradition is Tradition).
Interoperability: existing deployed implementations of X.509 expect certificates with an expiry date; the field is not optional. Moreover, some of these implementation will refuse dates beyond January 2038 (that's the year 2038 problem).
Greed: if you are a CA in the business of selling certificates, well, you really like it when people have to come buy a new one on a yearly basis.
Although the certificate has a finite validity period it can be revoked at any time. The act of revocation places the serial number of that certificate into a certificate revocation list (CRL). Each certificate will include a link to a location where the latest CRL has been published by the issuer of that certificate. This means that if a certificate is no longer needed or becomes compromised the bearer or subject of that certificate can request that it be revoked. During the validation of a certificate chain all certificates are checked to see if they have been revoked. If the certificate appears on the list it cannot be trusted.
Certificates have a validity period for a number of reasons. Firstly, key length. The validity period is set so that the key length of the certificate will not be "theoretically" broken during the validity period of that certificate. Also, keys should be re-generated, rather than re-issued. This can be enforced by using the private key usage X.509 extension.
Secondly, in a certificate chain the most trusted certificate will have the longest key length. Look at root certificates and you will find that these normally have at least 4096 bit RSA keys. The validity period of the certificate will also be longer. For a root certificate it will be between 10 and 20 years. This depends greatly on the hierarchy of the PKI. PKI hierarchies will usually be 2 or 3 tiers. E.G. RootCA->PolicyCA->IssuanceCA or RootCA->IssuanceCA. The private key of the CA should only be used for half the length of the validity of the certificate. If we take a 3 tier hierarchy, the validity periods of the certificates will be something like:
Root CA (20 years) -> Policy CA (10 years) -> Issuing CA (5 years) -> End Entity (2 years max).
The private key usage period for the CA will be:
Root CA (10 years) -> Policy CA (5 years) -> Issuing CA (2 years max).
The reason for doing this is so that no certificate issued under the root CA will every become invalid because it parent certificate has become invalid. In the above example the 2nd certificate for the policy CA will be issued under the 2nd key of the root CA, even though the first certificate is of the root CA is still valid. The second certificate of the root CA will be issued after 10 years, just before the 2nd certificate of the policy CA.
It limits the amount of time that a stolen certificate can be used by the thief. Certificate Recovation Lists exist, but they work only when the certificate owner (or issuer) actually notices and acts to revoke the certificate.
While I'm not sure whether your question pertains just to certificates used with the HTTPS protocol, or more generally, there are non-web uses where expiration time comes into play.
For instance, I've encountered systems where certificates were used internally as a transient authentication method, somewhat like a session token, where the issuing CA had no record of the certificates it had issued, and thus no way to revoke them.
The only simple mitigation was to drastically reduce the validity time, which had no reason to be long-term anyway since new certificates were constantly being issued.
In case of a compromise the
These are 4 different acts, which happen mostly in very different times, and not always in this order.
The expiration of the certificates makes the chance of the successful attack lower by the significant lowering of the usable time-interval for the attackers.
