Every SSL certificate has an expiration date. Now suppose some site's certificate expired an hour ago or a day ago. All the software by default will either just refuse to connect to the site or issue security warnings.

This recently happened to Windows Azure Storage and since most of software in dependent services defaulted to refusing to connect lots of services experienced major degradation.

Now what's the logic in here? I mean a day ago the certificate was valid and everyone was happy to use it. Now a day later it's formally expired and noone likes it anymore.

I've read this answer and I don't find it convincing for this specific edge case. To every security model there is a threat model.

What's the threat model here? What could have happened between now and a day ago that a certificate is treated to be unusable to such extent that we even refuse to connect to the site?

  • 5
    Would you like to drink from a carton of milk that's a mere two days past its sell-by date? Commented Feb 25, 2013 at 10:32
  • 21
    @Shadur: Never heard of being poisoned by an SSL certificate.
    – sharptooth
    Commented Feb 25, 2013 at 10:36
  • 19
    @Shadur sure, but first you smell the milk to check if it is off. If not, then you tentatively taste it. If the milk is not off then you use the milk. Commented Feb 25, 2013 at 12:18
  • 23
    @Shadur Absolutely, and more people should - far too much perfectly good food is wasted on this planet.
    – Alan B
    Commented Feb 25, 2013 at 12:50
  • 3
    @Smalltown2k I doubt there's a smell test for a compromised certificate that is anywhere near as reliable as the one for sour milk.
    – Mattie
    Commented Feb 25, 2013 at 16:15

10 Answers 10


When a certificate is expired, its revocation status is no longer published. That is, the certificate might have been revoked long ago, but it will no longer be included in the CRL. Certificate expiration date is the cut-off date for CRL inclusion. That's the official reason why certificates expire: to keep CRL size bounded.

(The unofficial reason is to make certificate owners pay an annual fee.)

So you cannot trust an expired certificate because you cannot check its revocation status. It might have been revoked months ago, and you would not know it.

  • 8
    Your unofficial reason don't match for self-signed (free of charge) certificates who have to expire too! Commented Feb 25, 2013 at 13:10
  • 4
    Well, I am right now in the process of renewing my free-of-charge SSL certificate, and it is so irksome that I am seriously considering switching to a non-free CA. I suspect StartSSL does it on purpose (free certificates are advertisement, to grab attention). Commented Feb 25, 2013 at 13:46
  • 2
    Are you using ou did you already try OpenSSL suite? Commented Feb 25, 2013 at 16:10
  • 1
    @ThomasPornin - yeah, personally I love StartSSL, but I also use their level 2 verified option. Was still the cheapest wildcard cert I could find. Also, appreciate that they actually use a client side certificate based authentication system for their accounts. Commented Feb 25, 2013 at 18:46
  • 4
    @ThomasPornin Then let's roll our own non-commercial CA - with blackjack and hookers Commented Feb 25, 2013 at 20:23

A good question. The simplest answer is that having an expiration date ensures that you have an "audit" every so often. If there were no expiration date, and someone stopped using a certificate (and protecting the private key), no one would ever know. However, by having an expiration date you ensure that the user goes back to the company that sold them the SSL certificate and pays them lots more money err, I mean, has an audit and is re-validated as the person or service they claim to be (I'll try to leave rants about the current internet security model out of this question).

The problem then becomes: If you're going to have a grace period in which you ignore expired certificates, how long does it last? A day? A week? A month? At some point you simply have to stop trusting the certificate; if you make that point a day after the expiration, you can still ask yourself: "What could have happened between today and yesterday?" And you fall into a loop.

Essentially, you're right: People don't magically stop protecting their private keys as soon as the expiration date hits (or they may have stopped protecting them a long time ago and no one knows because they didn't revoke them and they haven't expired yet). The expiration date says nothing about the security of the certificate, but if you don't have a cut off you'll never know that a certificate may be forgotten about whereas with one you at least know that much.

  • 42
    +1 for "If you're going to have a grace period in which you ignore expired certificates, how long does it last?". That's the real reason, I believe, why a grace period would never work: it simply artificially extends the validity period, which means you could just as well use a longer validity period to begin with. Which all software would implement in the same way.
    – user
    Commented Feb 25, 2013 at 9:45
  • 2
    Mind, the "lots of money" is a bit hyperbole; rapidssl doesn't charge more than a hundred bucks for a two-year cert... Commented Feb 25, 2013 at 10:43
  • 6
    Its also worth noting that the Certificate Authorities are running infrastructure to validate your certificates, this infrastructure has running costs so having people renew certs every so often is good for their business and keeps everything running.
    – NULLZ
    Commented Feb 25, 2013 at 12:05
  • 2
    @LarsH Suppose you're looking at computer-to-computer communications (let's say web services, e-mail transfer, ...) rather than user-to-computer (perhaps but not necessarily web browsing). Where should the warning go, in order to be effective?
    – user
    Commented Feb 25, 2013 at 14:42
  • 5
    @Michael Right - if driving 10 km/h over the 100 km/h speed limit is waved away then everybody drives 110 and complains about the ticket they get at 113 because they 'were only 3 over'. The same inflation applies.
    – user13695
    Commented Feb 25, 2013 at 16:14

If there was a universal five-day grace period, nobody would notice the certificates' expiry until five days later, leaving you with an identical net effect to refusing an expired certificate immediately. It's the fact that SSL connections stop working that creates the pressure.

I suspect it would be more productive for SSL client applications to warn loudly of an impending certificate expiration, so that the users of those applications could pressure their service providers ahead of time.

  • 2
    +1 for client applications to issue a warning ahead of cert expiration, regardless of some official grace period protocol. (Turn-offable, of course!)
    – LarsH
    Commented Feb 25, 2013 at 14:04
  • 2
    +1 for monitoring but it only works if the messages reach a person, and warnings that go into logs still need to be noticed. All our web server certs are monitored by nagios for expiry dates, red text gets plenty of attention. And the issuing cert authority was probably sending emails to someone at 60/30/15/7/1 day intervals about the expiry anyway.
    – jqa
    Commented Feb 25, 2013 at 15:39
  • @james Kudos to you for watching your certs and the CAs who warn too, but I think my point stands—if the clients started complaining, then service providers who weren't quite so on top of matters would have some external pressure to get their acts together before trouble started.
    – Mattie
    Commented Feb 25, 2013 at 15:43
  • 1
    Until something blows up and stops working I doubt more than an extremely miniscule fraction of clients are going to say anything. Clicking ignore, or coming back in a day or two on the assumption that the admin is working on the issue, is far less effort than trying to figure out how to contact a sites admin to report the problem. Commented Feb 25, 2013 at 16:29
  • There could be a periodic task which runs daily, which sweeps through the certificate store and produces warnings for all certificates that are about to expire.
    – Kaz
    Commented Feb 25, 2013 at 16:39

I agree the current system is suboptimal.

A better certificate system could have a "yellow"-state period for certificates that are about to expire ("green" being a valid certificate, and "red" being an expired certificate), expiring within 1 month. Every N-year certificate would expire after N years + 1 month, though they ideally they would be updated within the N year period. However, during the last month every application that uses a certificate should present a mild warning indication to the user. For web-browsing, you could do something like color the URL yellow instead of green -- with a hover/click message to the effect:

This website's certificate will expire on Mar 25, 2013 and should be updated by the domain owner before they expire. The certificate is still perfectly valid and should be fully trusted at this date, but applications that rely on this certificate will stop working on Mar 25, 2013 if the certificate is not updated by then.

Would this be perfect? Probably not, as some applications may not pass these messages to the user and the expiration date will still be reached. Also, there has to be agreement codified in a standard for how soon before certificates expire that they should be updated (one day? one week? two weeks? one month?). But it definitely seems to be an improvement.

(Granted, I do agree Microsoft really dropped the ball when they let their Azure certificate expire -- that is a sign of incompetence for a platform trying to support enterprise applications).

  • This should be the selected answer.
    – Pacerier
    Commented May 23, 2015 at 12:32

The answer is as simple as the business: "The bill isn't payed"

The certificate authority claims for a distinct period of time that this certificate is valid. But this says not much about the trustiness of the certificate authority and the processes by the certificate owner.


It's got to do with perception and proper security practices.

When you create a certificate with, say, a one-year expiry you're basically saying "We can't guarantee the certificate's integrity for more than a year, so we will roll out a new certificate before then."

So a site with an expired certificate is a sign that the administrators didn't keep to their promise to renew within the time they set for themselves, which suggests poor security practices.

It's the same reason you catch hell for missing a car inspection even if your car seems to be running fine, or why products have a sell-by date.

  • 1
    1) By using a non forward secure ciphersuite you need to guarantee the secrecy of the private key even after the certificate expired 2) Compromises happen at random times, so you can't say "I can keep the key secure for a year". So your perishable goods comparison isn't a good fit. Commented Feb 25, 2013 at 16:41

Shelf-life might be an interesting thing for some products: the manufacturer states that it warrants that the product will be valid during a certain time but he can't warranty that the original properties will be present if you consume the product after that period.

One certificate has the same thing: it has a period where the issuer states that it is valid. During that time the certificate should be ok. And if it isn't, there'll be some recall about it: a revocation list by the issuer will tell the whole world "don't trust that certificate again, because somehow it might be compromised".

After the expiration date, the issuer won't keep track anymore of that certificate: it has passed the date it was good, so anyone who still trust it should do based only in his belief, not on the issuer (or anyone else).

After the expiration date, the certificate isn't bad, broken, smelly... it is just not guaranteed anymore to have been revoked. And why do we not trust a SSL certificate that expired recently is because we want security, and we use certificates to warranty something. If we can't be sure if it was (or would be) revoked, you can't be sure it was compromised, and you don't have any security using it...


Besides the already mentioned things (it is good practice to change such keys on a regular basis, the CAs want to get paid, re-auditing the identity etc.), there is also a technical reason. Browsers inform you that they cannot verify the validity of the certificate.

Certificates can be revoked, i.e. marked as invalid, in case their keys get compromised, the CA notices they were misissued, etc. This revocation information is guaranteed to be provided during the validity period, but not after. This allows to keep CRL (Certificate Revocation List) sizes small. Although CRLs are rarely used today in browser-based SSL, this could affect other means of checking validity, too.

For this reason, enforcing the validity date makes technical sense and is not done purely because "certificates should be renewed to ensure reaudits" and "CAs want to get paid".


Setting expiry date for certificates is done for about the same reason you should change your password from time to time and have a policy to make users change it from time to time. Not always needed but might come in handy sometimes.

For example your ex-employ having your job (internal) CA might sign his phising website and you would not spot any differences at all between his site and your bank site (including your browser saying the connection is secure). Having an expiry date at least on internal CA makes you change it from time to time and avoid this.

You still can say "I don't care" and set certificate date to e.g. 2300 (if you are the owner of CA). Of course commercial, external authorities might want to make you set it to your license expiry date ;-).


It depends on what you are securing. It's relatively safe. It amounts to a zero-day, man in the middle attack. An attacker would have to know the certificate expired, know that you use that certificate, and insert themselves between you and the server in the span of a few days. If you are guarding nuclear secrets, it's too risky to trust. If you send your credit card number, it would be ok for a few days or weeks (not that you are liable anyway). If you blog about dictators in Iran, while in Iran, you are risking your life, and it might not be worth the risk.

You must log in to answer this question.

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