Hacker News Reader

Comment by IgorPartola | Hacker News Reader

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.

View on HN

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.

Reply on news.ycombinator.com