37

What are the security implications of an expired SSL certificate? For example if an SSL certificate from a trusted CA has expired will the communication channel continue to remain secure?

Thomas Pornin
  • 320,799
  • 57
  • 780
  • 949
Imran Azad
  • 813
  • 2
  • 9
  • 11
  • Are you talking about a certificate for a server you own, or for other servers in general? The expiration does not necessarily mean the certificate is not secure anymore, but you should not trust it to be secure. – efr4k Oct 26 '11 at 10:51
  • If you are using expired SSL CA certificate there may be chances of Man in the middle attack . –  Dec 10 '14 at 09:03
  • Vinuth - this doesn't answer the question (and in fact is not correct - the chance of MITM is not due to the expiry, directly) – Rory Alsop Dec 10 '14 at 09:41

4 Answers4

33

The communication is still encrypted, but the trust mechanism is undermined. But usually the most important factor is that users will get ugly warning messages about the security of your site. Most won't make informed judgements about the integrity of the connection, they'll just go buy stuff elsewhere.

m-ric
  • 103
  • 3
symcbean
  • 18,278
  • 39
  • 73
  • 12
    Someone voted this up today - so it came back across my radar. My answer above is now a bit dated: if the service has HSTS enabled, then it will not be accessible using an expired certificate from an HSTS capable browser - see https://www.owasp.org/index.php/HTTP_Strict_Transport_Security – symcbean Mar 03 '14 at 11:37
  • 4
    Use the edit function. – Pacerier May 23 '15 at 12:23
33

On a theoretical basis, an expired certificate is a certificate which must not be used any longer. This is made explicit in the the Internet X.509 Profile in the certificate validation algorithm (section 6.1.3, item a.2). In practice, this has two consequences:

  1. The key owner (the server) must keep its private key, well, private. Anybody who gets a copy of the private key may impersonate the server. Keeping some data private is not totally immediate; e.g. you have to think about how you do your backups. Once the certificate has expired, the server may simply cease to bother about key privacy, since the corresponding public key is not to be used anymore. If you (as a SSL client) decide to accept an expired server certificate, you take the risk of using a public key for which the corresponding private key has simply been abandoned and scooped up by a bad guy.

  2. There is such as thing known as revocation. When a CA revokes a certificate, it says: "yeah, that's my signature on that certificate, but let's all act as if I never signed that". A typical revocation situation is when the private key was compromised. The CA constantly publishes the revocation status of the certificates it has emitted through CRL (lists of revoked certificates) and OCSP (a dedicated revocation status check protocol). A SSL client is supposed to get information on the server certificate revocation status before accepting it (in a Web / HTTPS context, most clients do not bother). The key point is that once a certificate has expired, the CA ceases to keep track of its revocation status (this avoids having CRL grow indefinitely). Hence, a client accepting an expired certificate takes the risk of unknowingly using a certificate which has been revoked during its lifetime.

As Peter Gutmann says it, the end of validity date in a certificate "denotes the time at which you have to pay your CA a renewal fee to get the certificate reissued". The business model of commercial CA inherently relies on clients honouring the end of validity date. This also explains why Web browsers are keen on displaying scary warnings when a certificate is expired.

Community
  • 1
Thomas Pornin
  • 320,799
  • 57
  • 780
  • 949
  • If a certificate is expired for a server `example.com` from CA `XYZ`, can attacker ask `XYZ` to sign a certificate for `example.com`, and then use this certificate to fool client trusting certificate for `example.com` from `XYZ` ? – Jake Nov 07 '15 at 20:56
3

In a practical sense, I would look at the expiration date. If the date is only a few days past expired, then I, personally, would trust it.

However, certs that are years past the expiration date could've been compromised and should not be trusted. (In fact, if a site you often use comes up suddenly comes up with a cert that's been expired for quite a long time, then thats a pretty red flag.)

IE- If the the cert expired yesterday, the connection is really no less secure than it was yesterday. It doesn't automatically become insecure once the expiration date has passed.

You do, however, have to draw the line somewhere... and that's what the expiration date is for.

user606723
  • 822
  • 5
  • 10
1

One more thought on expiration of a certificate is addressing the question of asymmetric key algorithm itself. From a public key is it possible to determine the private key? Well the answer it is improbable rather than impossible. Generally it is assumed it would take a million years to for a computer to find the private key from a public key. But what if you run a million computers for one year. You might end up with the private key and now when you think of using that private key it would be really frustrating to realize that the user has renewed the certificate. (That DOES NOT mean he has paid money to retain the old certificate, but it means a new certificate with a new public key is in place now and the million computers would have to start their work from scratch)

Btw, what if I use all these computers to keep generating public & private key pairs and store the two in a two-column table in a database. Is there any chance of reading the private key directly from the public key that is entered?

krish
  • 21
  • 1