-
Notifications
You must be signed in to change notification settings - Fork 9
Re-use of private key #9
Comments
Maybe I'm missing something, but aren't private keys supposed to be the same when the certificate is renewed? |
That is not my understanding... Luckily backed up by Qualys SSLlabs 😄 https://www.ssllabs.com/downloads/SSL_TLS_Deployment_Best_Practices.pdf
Thing is that you want to prevent a compromised private key to be used to decrypt traffic after you've renewed (and potentially even revoked). Obviously doesn't apply to PFS sessions... |
There's a nice discussion of this; but regardless, it appears that certbot does what you suggest (see their issue/231. As it's the "official" client, I guess I should do that too. For the record, the technical rationale seems pretty thin. The only use case really covered is where you don't know the key has been compromised, in which case the interval during which traffic can be decrypted is bounded by the next renewal. If the key isn't compromised, it doesn't matter whether you use the key for three months or years: with 4096 bit keys, cracking isn't feasible. If this becomes the default behaviour, the old keys and certificates shouldn't be backed up: they should just vanish to prevent an ever-growing directory. However, I'll probably add a backup option anyway as well. |
Generating a new private key will require some form of backup or temporary key/cert in any case. If the certificate renewal fails you don't want to have the working cert/key to be destroyed. My (not so private) renewal script already includes a backup, with the downside of not cleaning up. I'm backing-up in my current renew scripts already https://brnrd.eu/security/2016-06-18/letskencrypt.html#the-renew-script |
One of the reasons I like acme-client is because it doesn't create RSA key every time new certificate is created. I'd rather it stays like this. If the default changes, at least provide an option to keep the old behaviour. It's really helpful when you use DANE or HPKP. |
Current implementation does not generate a new domainkey when a new certificate is requested.
Proposed behaviour on renewal (both TTL < 30days and forced):
Subseqently a user may easily revoke without having backed-up the domainkey+cert
The text was updated successfully, but these errors were encountered: