4 ms·
Your speculation is correct -- we re-keyed the certificate just as a precaution. Rolling a new cert is tough as thousands of people's clocks are wrong, so we t
by pwman 15y ago
Your speculation is correct -- we re-keyed the certificate just as a precaution. Rolling a new cert is tough as thousands of people's clocks are wrong, so we thought we'd give it a full day so those people wouldn't receive errors -- we didn't realize the old one would be revoked so quickly (it was automatic with the rekey).
- rdl 15y agoBest practice in this case would be to get your new cert from a new CA, then revoke the old one with the original CA once you've got the new cert in place. Plus, of course, announcing everything in advance. (I'd wait a month or so unless you had specific fear of the old one having been compromised).
- sixcorners 15y agoJust wondering.. Why use a new CA?
- rdl 15y agoThe new CA won't invalidate your old CA's cert. You want to preserve availability of the old CA's cert until the new one is deployed across all your servers. In practice, SSL (with CA certified keys issued by lame public CAs) is only really protection from passive eavesdropping anyway; there are enough bad or lax CAs out there that you have to assume an attacker can get a key for an arbitrary site, or can steal a site (not protected in an HSM) from almost any site. There's nothing really wrong with the X509 PKI in the abstract, but it doesn't really work well for real identity on the Internet. Protection from passive attacks is worthwhile, but it's not worth the disruption to your users to push beyond that to try to keep only one key at a time out there.