How do I distinguish between these two certificate situations?

Situation 1 (safe):

Website was vulnerable to heartbleed and using a certificate not valid before 2012-10-21
Website upgraded to an unvulnerable version of OpenSSL
Website re-keyed and got a their certificate reissued, with with same not-valid-before date of 2012-10-21
Today, when I inspect the site, I find it not vulnerable to heartbleed, and using a certificate with a not-valid-before date of 2012-10-21

Situation 2 (unsafe):

Website was vulnerable to heartbleed and using a certificate not valid before 2012-10-21
Website upgraded to an unvulnerable version of OpenSSL
Today, when I inspect the site, I find it not vulnerable to heartbleed, and using a certificate with a not-valid-before date of 2012-10-21

As far as I understand things, these two situations are indistinguishable to me as an end user who has never visited the website in question before. What am I missing?

FYI, situation 1 is apparently the case for *.wikipedia.org. They said that's just the way Digicert reissues certificates.

user148324

Posted 2014-04-10T05:53:34.787

Reputation:

I disagree - While this IS a security issue, it is also the type of issue of interest to Superuser users, and should remain here. – davidgo – 2014-04-10T07:01:16.237

We can keep this here. It's on topic for our scope too. If you don't get good answers within, say two days, then we can still migrate it over. – slhck – 2014-04-10T07:49:14.020

I don't think there actually is a way without knowing the serial number (which you can either compare with the current one or check for in the CRL [List of revoked certs]). – UKB – 2014-04-10T09:56:30.443

@UKB Thanks! If you're sure of that, could you write an answer? – None – 2014-04-10T14:43:16.250

@Articuno We actually created a website to track this as best as we could. We grabbed the certs to the top 1 million websites and check to see if they are still vulnerable, and if the cert has changes since we cached it. http://Heartbleedstatus.com ( I'm not sure it is actually an answer though, so let me know)

– Jacob – 2014-04-12T05:33:45.457

@Jacob This is great. Once I realized this is what it would take, I wanted to do this, but didn't have the time or resources. Although, I don't see where the certificate information is being shown. Oh, nevermind.. I see it now. Perhaps make it clearer to users that they should check that other page and not just rely on the test of current vulnerability. – None – 2014-04-12T06:55:58.927

@Articuno Would you mind if I posted it as an answer? – Jacob – 2014-04-12T07:04:23.730

@Articuno: Bear in mind too that some services had private knowledge of Heartbleed before the public announcement, and those services will have revoked their old certs and issued new ones prior to the date of the public announcement. Cloudflare has explicitly said that they did this, and given that Google Security helped discover the bug in the first place, I am confident that Google did as well.

– Daniel Pryden – 2014-04-14T03:03:46.163

@Jacob Yes, please. Although, I'd like this not to turn into a list of all the solutions like yours, so it would be good to also explain a bit about this ambiguity in the x.509 certificates. – None – 2014-04-14T15:56:52.150

Answers

Zmap.io have a list of changes to certificates for the top 5,000 most popular sites. Note that the date listed there does not rely on the Not Valid Before date of the certificate itself and therefore should represent an accurate date for when the certificate was last changed. (I used Wikipedia.org to check this as they get their certificates from DigiCert who backdate the Not Valid Before date when re-keying certificates.)

They link to the raw data they used which presumably covers a lot more than just the top 5,000 sites but at the time I am writing this, the site is not responding.

Another project that collects certificate fingerprints is Convergence. I haven't explored yet to see if you can extract fingerprints and dates out of it but if you were using it before HeartBleed, it would probably warn you when a site's certificate changed (unless a majority of other people using it had already accepted the new certificate for that site). Ironically, no warning in this situation would be an indication that you were not safe and a warning would be an indication that you were safe.

Ladadadada

Posted 2014-04-10T05:53:34.787

Reputation: 174

This is good. Were any sites doing this all along? It seems like if we wait until after vulnerabilities are announced and responded to, we might lose some of the old certificates if the site responds very quickly to the issue. – None – 2014-04-14T16:00:02.890

The source data is back online now and it looks like it stretches back for years. It covers the entire IPv4 address space so it's likely to include any site you care about. – Ladadadada – 2014-04-15T12:16:08.627

Awesome! Seems to me this is a hole in the x.509 specification if we need to rely on a service like this for issue-date determination. – None – 2014-04-15T15:50:28.753

You can search for the Certificate Authority's CRL (i.e. http://www.verisign.com/repository/crl.html from VeriSign) and see if they have recently revoked an the old certificate but to do that you will generally need the old certificate's serial number. You could also, if you had the old serial number, just compare it to the new one.

The problem is that there isn't much you can really do to see if it is a different certificate than before without the old certificate serial number.

UKB

Posted 2014-04-10T05:53:34.787

Reputation: 51

Maybe check the internet archive for the site a week ago to see the old cert? – Dan L – 2014-04-10T20:28:59.617

@DanL Does the internet archive save certificates? – None – 2014-04-10T21:15:48.190

@Articuno Hmmm, wayback machine doesn't, google cache doesn't. Ok, change the maybe to a don't bother. Sorry about that, should have realized that the secured sites wouldn't let you have a cached version of the page. – Dan L – 2014-04-10T21:27:25.037