Hacker News Reader

Comment by gojomo | Hacker News Reader

Notably some sites are using fresh certificates that have the same (months-in-the-past) starting-validity date as their old certificates. For example, Heroku has done this.

(I can think of a few process and fee reasons this approach might be picked. Perhaps a CA might offer a free new cert and revocation, if and only if the new cert has the same validity range as the one it replaces. An ops team might prefer one consistent time of year for the ceremony of non-emergency certificate rotation.)

I didn't notice any field in the cert-viewers of Firefox or Chrome that could reliably tell the true issue-date of a new certificate.

Is LastPass just looking at the start of the validity, or does it have some way to know if the certificate is truly new?

View on HN

We haven't found a way to do this -- we're using openssl s_client to get the start date, but one of our own certificates for LastPass.eu also reissued without changing the date so we know it's a problem.

We wish we had all site's certificate fingerprints from before this started so we could utilize that data -- if anyone has it, an email to securit@lastpass.com would be greatly appreciated.

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

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.

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

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.

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.

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.

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

Reply on news.ycombinator.com