93

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?

Community
  • 1
sharptooth
  • 2,161
  • 1
  • 19
  • 22
  • 5
    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
  • 18
    @Shadur: Never heard of being poisoned by an SSL certificate. – sharptooth Feb 25 '13 at 10:36
  • I wouldn't be surprised if certificate revocation stopped working at that point. No need to tell the client about the revocation, since it's already expired and thus invalid. – CodesInChaos Feb 25 '13 at 12:09
  • 16
    @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
  • 21
    @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
  • 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. – zigg Feb 25 '13 at 16:15
  • 2
    I recently quaffed Tylenols that expired in 2006. Headache gone. It's my "lifetime supply" bottle. – Kaz Feb 25 '13 at 16:33
  • 1
    [Shelf-life](http://en.wikipedia.org/wiki/Shelf_life) is the name... and SSL certificates don't have a shelf-life – woliveirajr Feb 25 '13 at 17:39
  • @zigg agreed, there's a risk but that's no reason to write off all the milk. It depends on what milk you're sniffing, I wouldn't be anywhere near as confident with meat past it's date. The metaphor translates to security I think. – Smalltown2k Feb 27 '13 at 15:08
  • @woliveirajr Are you sure about that? Microsoft just stopped accepting 512-bit RSA certificates in IE not that long ago. They were once "fresh". – zigg Feb 27 '13 at 16:04
  • @zigg: I'm not sure I understood your point. Your talking about this [security advisory](http://support.microsoft.com/kb/2661254/en-us)? That 512 bits RSA certificates, although not expired, weren't accepted anymore, because Microsoft decided so? That's ok, MS can decide what to accept or not, and her users decide whether to apply the update or not. The issuer, also, can declare that under some circumstances, the certificate is revoked, before it's expired... – woliveirajr Feb 27 '13 at 16:21
  • @woliveirajr You cannot dismiss the fact that all private keys have finite lifetimes with a blithe "because Microsoft decided so." You'd be a fool to use a 512-bit certificate in 2013—more so to use one you generated and published back when 512-bit certificates were still acceptable. – zigg Feb 27 '13 at 16:46
  • @zigg: yep, I totally agree with that. The point of the question, comment, answer, etc, is that when a certificate is expired, it doesn't make sense to keep using it, as if it had a shelf-life. That doesn't mean that all certificates should be trusted with closed-eyes just because they haven't expired yet. – woliveirajr Feb 27 '13 at 17:10
  • 1
    @woliveirajr Okay, I think we were talking at cross-purposes… To your point, yes, it's true, non-expiry does not assure non-compromise; far from it. But it's a useful mechanism to keep key pairs fresh, if you will. – zigg Feb 27 '13 at 20:25
  • @Shadur, What's wrong with that? It' being done all the time. – Pacerier Jul 04 '15 at 11:51

10 Answers10

108

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.

Thomas Pornin
  • 320,799
  • 57
  • 780
  • 949
  • 7
    Your *unofficial reason* don't match for self-signed (free of charge) certificates who have to expire too! – F. Hauri - Give Up GitHub Feb 25 '13 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). – Thomas Pornin Feb 25 '13 at 13:46
  • 2
    Are you using ou did you already try [*OpenSSL*](http://www.openssl.org/) suite? – F. Hauri - Give Up GitHub 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
  • 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. – AJ Henderson Feb 25 '13 at 18:46
  • 4
    @ThomasPornin Then let's roll our own non-commercial CA - [with blackjack and hookers](https://www.youtube.com/watch?v=z5tZMDBXTRQ) – Tobias Kienzler Feb 25 '13 at 20:23
  • @Kaz what if this is the first time seeing that certificate? – user253751 Mar 13 '14 at 08:36
  • 1
    This is only half true, RedHat says: [By default, CRLs do not contain information about revoked expired certificates. The server can include revoked expired certificates by enabling that option for the issuing point.](https://access.redhat.com/documentation/en-US/Red_Hat_Certificate_System_Common_Criteria_Certification/8.1/html/Admin_Guide/Revocation_and_CRLs.html#Revocation) Microsoft also says [...You can enable a registry setting on a CA to ensure that revoked certificates that have expired are not removed from the CRL.](http://technet.microsoft.com/en-us/library/cc737180%28v=ws.10%29.aspx) – MDMoore313 Dec 18 '14 at 18:40
  • Some CA can include expired certificates in CRL, subject to a cut-off date that is later than the certificate expiry date (and possibly infinitely remote in the future), but that's CA specific, and verifiers cannot count on it unless it is documented as an appropriate CRL extension. There is no standard extension for that (there is a Microsoft-specific one, though). Adjustable cut-off is a nice idea, but this is still an expiry date (expiry on the revocation information, not on the certificate itself), and cannot be reliably used until it becomes widely supported (and right now it is not). – Thomas Pornin Dec 18 '14 at 19:00
  • @TobiasKienzler, Link broken. What's that about? – Pacerier May 23 '15 at 12:29
  • @Pacerier Aww, silly copyright... [Here](https://www.youtube.com/watch?v=BGi6Q1pNbS0)'s another go, or [kym](http://knowyourmeme.com/memes/im-going-to-build-my-own-theme-park-with-blackjack-and-hookers). Not that the video contributed anything to this answer :P – Tobias Kienzler May 26 '15 at 15:46
  • @TobiasKienzler, I don't get the link at all. What's the joke all about? – Pacerier Jul 02 '15 at 16:24
  • 1
    @Pacerier I was responding to [Thomas' comment](http://security.stackexchange.com/questions/31463/why-do-we-not-trust-an-ssl-certificate-that-expired-recently/31482?noredirect=1#comment48658_31482) about the inconvenience of "free" CAs with "then let's run our own CA" but in an attempt to be funny quoting good old Bender's "I'll start my own park, with blackjack and hookers. In fact, forget about the park and blackjack"... – Tobias Kienzler Jul 02 '15 at 18:07
  • @ThomasPornin, actually there is an standard extension when querying certificate status through an OCSP service. See RFC 6960, "4.4.4. Archive Cutoff". – Jaime Hablutzel Jun 07 '19 at 17:22
72

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.

Sam Whited
  • 958
  • 5
  • 16
  • 40
    +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 Feb 25 '13 at 09: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... – Shadur Feb 25 '13 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 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
  • Just my 2c... If you are a big enough customer, you can get "normal" (Non-EV, etc.) VeriSign certs for <$100/yr as well. Verisign Internal certs are even cheaper, at about 1/4th the price. – JZeolla Feb 25 '13 at 13:57
  • +1. One *could* design a grace period that is more than just an extension of the validity period: it would be a period during which the certificate would work, but with a warning. However, the question is whether the cost of the complexity increase would be worthwhile. In order for the grace period to be effective, all software between the certified server and the end user would have to understand and pay attention to this additional nuance. Currently, most software doesn't even tell you if a cert is expired... it just gives a connection error. – LarsH Feb 25 '13 at 13:59
  • 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 Feb 25 '13 at 14:42
  • 4
    @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. –  Feb 25 '13 at 16:14
  • @MichaelKjörling: Depends on what each software component is doing with the information. That's why I say all software between the certified server and the end user -- including the C2C connections -- would have to understand and pay attn. What they should do with the warning info requires separate design decisions for each piece of software. Doesn't seem like something that would fly very well. – LarsH Feb 25 '13 at 19:44
  • @LarsH: How about a CA providing a mechanism for Captcha-guarded expiry-check routine that would be guaranteed usable for a month after the cert expired, so that someone who wanted to make sure that their connection to `https://mybank.example.com` was legit could do so, at the expense of a little effort, even if the cert was expired, but no cert owner would want clients to go through that hassle. – supercat Dec 17 '14 at 18:15
  • @supercat No one would want to deal with the hassle, as you said, however, this is essentially the same as just showing a warning "This service uses an expired certificate" and letting the user click through. If the client is savvy enough to verify with a captcha or ignorant enough just to click through, they're savvy enough (or ignorant enough) to just hit the "okay, accept this cert even though it's expired" button. – Sam Whited Dec 17 '14 at 18:39
  • @SamWhited: How about having certificate authorities provide separate "List current certificates that are revoked" and "List recently-expired certificates that are revoked" functions, but have the latter function perform much slower than the former? If the latter function reported the cut-off where certificates would be dropped, then browsers could inform people that their connection was running slowly because the certificate was expired, but was nonetheless secure. – supercat Dec 17 '14 at 19:01
  • I still don't really understand the point of wanting to do this, but sure; you could maintain two CRL's and add something to OCSP. There's just no point to having a grace period or soft-fail period. – Sam Whited Dec 17 '14 at 20:48
  • @SamWhited: The idea would be to have a mechanism of degrading service sufficiently that companies would have a strong incentive to renew their certs in timely fashion, but at the same time ensure that momentary lapses don't weaken security. – supercat Dec 18 '14 at 15:46
  • 1
    @supercat Sounds like overengineering for a problem that doesn't exist to me. If a company can't be bothered to renew their certs on time I doubt an early warning will do anything. It's essentially just pushing the expiration date forward (albeit with a soft fail instead of a hard fail). – Sam Whited Dec 18 '14 at 16:41
  • @SamWhited: I've encountered failed SSL certificates as a user, but they've gotten fixed pretty quickly. The sites which don't have automated certificate updating probably aren't ones where security is a super hot issue, but from a philosophical perspective it would seem better to have a system remain secure if practical. – supercat Dec 18 '14 at 16:47
  • @supercat I don't disagree, I just don't necessarily think this sort of system would help. The comments probably aren't the best place to discuss it though. Ping me on chat if you really want to continue this conversation. – Sam Whited Dec 18 '14 at 17:38
22

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.

zigg
  • 321
  • 1
  • 6
  • 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 Feb 25 '13 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 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 Is Fiddling By Firelight 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
  • @DanNeely Good point. Sometimes I get a little too optimistic, heh. – zigg Feb 25 '13 at 19:33
6

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

dr jimbob
  • 38,768
  • 8
  • 92
  • 161
5

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.

H.-Dirk Schmitt
  • 159
  • 3
5

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.

Shadur
  • 2,495
  • 21
  • 19
  • 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. – CodesInChaos Feb 25 '13 at 16:41
3

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

woliveirajr
  • 4,462
  • 2
  • 17
  • 26
2

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

Jan Schejbal
  • 617
  • 4
  • 4
  • 2
    What does this answer add over [that of Thomas Pornin](http://security.stackexchange.com/a/31482/2138)? – user Feb 25 '13 at 14:45
2

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

Nux
  • 121
  • 3
1

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.

Chloe
  • 1,668
  • 3
  • 15
  • 30