Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

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?

share|improve this question
3  
Would you like to drink from a carton of milk that's a mere two days past its sell-by date? –  Shadur Feb 25 '13 at 10:32
9  
@Shadur: Never heard of being poisoned by an SSL certificate. –  sharptooth Feb 25 '13 at 10:36
10  
@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. –  Smalltown2k Feb 25 '13 at 12:18
11  
@Shadur Absolutely, and more people should - far too much perfectly good food is wasted on this planet. –  Alan B Feb 25 '13 at 12:50
2  
@Smalltown2k I doubt there's a smell test for a compromised certificate that is anywhere near as reliable as the one for sour milk. –  zigg Feb 25 '13 at 16:15

10 Answers 10

up vote 57 down vote accepted

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.

share|improve this answer
1  
Your unofficial reason don't match for self-signed (free of charge) certificates who have to expire too! –  F. Hauri Feb 25 '13 at 13:10
3  
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). –  Thomas Pornin Feb 25 '13 at 13:46
1  
Are you using ou did you already try OpenSSL suite? –  F. Hauri Feb 25 '13 at 16:10
    
You would know that the revocation was recent because you would remember that it worked yesterday or last week. –  Kaz Feb 25 '13 at 16:34
    
@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. –  AJ Henderson Feb 25 '13 at 18:46

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.

share|improve this answer

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

share|improve this answer

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...

share|improve this answer

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 ;-).

share|improve this answer

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".

share|improve this answer
1  
What does this answer add over that of Thomas Pornin? –  Michael Kjörling Feb 25 '13 at 14:45

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.

share|improve this answer
    
+1 for client applications to issue a warning ahead of cert expiration, regardless of some official grace period protocol. (Turn-offable, of course!) –  LarsH Feb 25 '13 at 14:04
1  
+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. –  james Feb 25 '13 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. –  zigg Feb 25 '13 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. –  Dan Neely Feb 25 '13 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 Feb 25 '13 at 16:39

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.

share|improve this answer
    
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. –  CodesInChaos Feb 25 '13 at 16:41

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.

share|improve this answer

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.

share|improve this answer
32  
+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. –  Michael Kjörling Feb 25 '13 at 9:45
1  
Mind, the "lots of money" is a bit hyperbole; rapidssl doesn't charge more than a hundred bucks for a two-year cert... –  Shadur Feb 25 '13 at 10:43
4  
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 Feb 25 '13 at 12:05
1  
@Shadur +1 for RapidSSL; I use them on all of my sites and they've been a joy to work with (the security model may be broken, but at least there are some good companies out there who won't try to screw you over at every turn)... As you might imagine, I've had some bad experiences with other providers in the past, so please forgive my little joke in the answer :) –  Sam Whited Feb 25 '13 at 13:34
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? –  Michael Kjörling Feb 25 '13 at 14:42

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.