Skip to content
This repository has been archived by the owner on Dec 1, 2018. It is now read-only.

Re-use of private key #9

Open
Sp1l opened this issue Jul 16, 2016 · 5 comments
Open

Re-use of private key #9

Sp1l opened this issue Jul 16, 2016 · 5 comments

Comments

@Sp1l
Copy link

Sp1l commented Jul 16, 2016

Current implementation does not generate a new domainkey when a new certificate is requested.

Proposed behaviour on renewal (both TTL < 30days and forced):

  1. Rename domainkey (append seconds since epoch?)
  2. Move contents of certdir to certdir/secondssinceepoch to allow for revocation after new certs are generated
  3. Create new domainkey
  4. Generate new cert/chain/fullchain.pem with new domainkey

Subseqently a user may easily revoke without having backed-up the domainkey+cert

@kristapsdz
Copy link
Owner

Maybe I'm missing something, but aren't private keys supposed to be the same when the certificate is renewed?

@Sp1l
Copy link
Author

Sp1l commented Jul 19, 2016

That is not my understanding...

Luckily backed up by Qualys SSLlabs 😄 https://www.ssllabs.com/downloads/SSL_TLS_Deployment_Best_Practices.pdf

Renew certificates every year, always with new private keys.

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...

@kristapsdz
Copy link
Owner

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.

@Sp1l
Copy link
Author

Sp1l commented Jul 24, 2016

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

kristapsdz pushed a commit that referenced this issue Jul 28, 2016
@pkubaj
Copy link

pkubaj commented Jan 14, 2017

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.

kristapsdz pushed a commit that referenced this issue Dec 1, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants