You might consider reaching out to the people behind the Perspectives Project. They run 10 public notary servers [0], and chances are good that they have fingerprints for most of the widely-trafficked websites.

For example, here's the Perspectives report on lastpass.com showing the brand-new key as well as the old ones: http://i.imgur.com/hJkFTAy.png

[0]: http://perspectives-project.org/notary-servers/

Thanks, looks like a good lead.

You might want to contact the maintainers of HTTPS Everywhere at the EFF. They collect and archive certificates for the SSL Observatory project.

https://www.eff.org/observatory

you might want to try contacting netcraft, they have all the certificate information for most major sites[1]

[1] - news.netcraft.com/archives/2014/04/08/half-a-million-widely-trusted-websites-vulnerable-to-heartbleed-bug.html

Take a look a scans.io. They have internet wide https scans every couple weeks.

Maybe you could use look for a cert with the same date on a revocation list. A site isn't really secure until the old cert is revoked anyhow.

I believe if you use a new private key but sign the same CSR the dates will not change. Ideally the old certs should be revoked which should provide some info on this. I saw this explanation on the discussion of the herokuapp.com's cert's dates not changing.

This is entirely up to the issuing CA's process. Thawte, for example, happily revokes-and-reissues certificates for free (perhaps only for "enterprise" customers?), and the newly issued certificate has the same end-validity date as the revoked certificate but the start-validity date is set to the time of issue.

I notice herokuapp.com's CA is DigiCert, so perhaps they have the opposite policy, of giving the reissued cert the same start date as the revoked cert.

I don't think there's a standard field in an X.509 cert for issue date.

It's possible to download a CA's CRL and look for revoked certs, but all you get are serial numbers and revocation dates, not subject names.

I think this explains what we've seen best.

From what I had to go through, you can't really "sign the same CSR". What you do is generate a new CSR with a new private key, using the same details as the previous certificate. Then you ask your provider for a re-key. You provide the CSR, they provide you with a new certificate, and revoke the old certificate within 72 hours (in Go-Daddy's case).

I am far from an expert in this so perhaps I

The public key in the CSR should match the private key it's associated with so this wouldn't work. Also the notBefore date in the certificate is set by the CA; it's not in the CSR.