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?
-
2Are 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.– efr4kCommented Oct 26, 2011 at 10:51
-
If you are using expired SSL CA certificate there may be chances of Man in the middle attack .– user62240Commented Dec 10, 2014 at 9:03
-
2Vinuth - 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 ♦Commented Dec 10, 2014 at 9:41
Add a comment
|
4 Answers
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.
If the service has HSTS enabled, then it will not be accessible using an expired certificate from an HSTS capable browser - see https://owasp.org/index.php/HTTP_Strict_Transport_Security.
-
16Someone 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 owasp.org/index.php/HTTP_Strict_Transport_Security– symcbeanCommented Mar 3, 2014 at 11:37
-
7
-
@Pacerier : you can edit this in yourself. and symcbean can approve .– serv-incCommented Nov 25 at 11:27
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:
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.
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.
answered Oct 26, 2011 at 12:29
-
If a certificate is expired for a server
example.comfrom CAXYZ, can attacker askXYZto sign a certificate forexample.com, and then use this certificate to fool client trusting certificate forexample.comfromXYZ?– JakeCommented Nov 7, 2015 at 20:56
EDIT: I might be wrong. See @john deter's comment.
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.
-
1"If the date is only a few days past expired, I would trust it". Moxie Marlinspike gave a brilliant talk at DEFCON17 where he exploited that behavior: youtu.be/5dhSN9aEljg?t=440 . "the second thing that users do after checking the name is check the time stamp to see whether it's expired so you could on the fly create certificates that expired 10 minutes ago where the signatures are totally bogus and it would pop up a dialogue "this certificate expired 10 minutes ago" and most users would be "well it only expired 10 minutes ago I mean you know that's not that bad." Commented Nov 25 at 20:13
-
@JohnDeters well that's f*cking good to know. My logic is sound as long as the browser behaves as I would expect. (which means that it's still validating everything but it finds it expired.) But if it's not doing that, then my advise is incredibly bad. And my bad for making an assumption like that. Commented Nov 27 at 4:43
-
It's been a dozen years, I think browser makers have addressed this somehow. But Moxie's point is still 100% valid: it's natural human behavior to make an allowance for one negative aspect before considering all aspects. And that behavior can be exploited. Commented Nov 28 at 14:57
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?
