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)?

  • Possible duplicate (or related to) security.stackexchange.com/questions/31463/…
    – Corneliux
    Commented May 15, 2014 at 8:20
  • Thanks. The answer there argues that the only reason is to limit CRL size. So is there no security implication in choosing a certificate duration of 200 years?
    – Philipp
    Commented May 15, 2014 at 8:28
  • 2
    "except for the issuer to make money on a regular basis, I mean": I believe that this is the main reason.
    – executifs
    Commented May 15, 2014 at 8:38

5 Answers 5


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.

  • 4
    2038 Problem? ... is often referred to as the Unix Millennium Bug. Great... we just has the Y2K problem. Then the end of the Mayan Calendar. Now this? Guess I'll start stacking up on rice and freeze dried potatoes because I have no faith that systems will be updated by then.
    – WernerCD
    Commented May 15, 2014 at 17:44
  • 3
    @WernerCD Well, Y2K problem was almost 15 years ago! Soon we will have plenty of people on Stack Exchange who were born later than that. Will be interesting to see how the two events compare.
    – Sander
    Commented May 15, 2014 at 20:27
  • If CA's had no vested interesting in renewals, all of the issues could be solved by using 100+ year expiration with periodic "hey, your 128-bit cert is rather weak today, buying a 512-bit cert wouldn't be a bad idea!" I think the greed component plays a very large role in the expiration process.
    – Brandon
    Commented May 16, 2014 at 13:02
  • Would privacy weaknesses in OCSP, and scalability concerns in CRLs also be a reason supporting expiration dates? OT- Do you know of any alternate methods of revocation x509 or not? Commented May 16, 2014 at 14:14
  • 2
    One way to look at revocation is that it is an optimization over renewal: imagine that each certificate owner receives a brand new certificate on a daily basis (with the same public key and name), and the certificates expire after one day. In that view, a CRL is merely a "delta": it says "assume that all certificates have been renewed, the CRL lists the (rare) certificates for which this is not true". Commented May 16, 2014 at 14:22

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.

  • And even then, CRLs aren't fully reliable.
    – Brian
    Commented May 16, 2014 at 14:18

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

  • opening of the security hole (or the possibility of the compromise)
  • the real compromise
  • the closing of the compromise
  • the usage of the compromise

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.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .