I have a question about the renewal process of certbot/letsencrypt. Does it request a new certificate for the same private key, or does it generate a new private key every time?
I’m unclear on this from the user guide. It just says:
“During the renewal, /etc/letsencrypt/live is updated with the latest necessary files.”
Later:
“Note that options provided to certbot renew will apply to every certificate for which renewal is attempted; for example, certbot renew --rsa-key-size 4096 would try to replace every near-expiry certificate with an equivalent certificate using a 4096-bit RSA public key.”
which implies you can change the private key at renewal. The question is, does it always do so?
As an experiment, I tried “certbot --force-renewal”, and the shasum of privkey1.pem and privkey2.pem are different, so it appears to be generating a new key.
But since certbot can use an externally-generated csr, presumably you could stick with the same private key if you wanted to. Is my understanding correct?
Aside: the reason I have for this question is for a slightly odd application of letsencrypt: for RADIUS servers with wireless authentication. I can set up a webserver for “wireless.mydomain.com”, get a private key + cert for it, and then push them out to my RADIUS servers. The underlying issue is: on renewal, do I need to push out a new private key and cert, or just the renewed cert?
Yes, by default certbot will generate a new private key each time. Changing keys is a good idea, usually we don’t change keys often because it’s easier not to, but with a fully automated setup we might as well change keys every time.
Yes, if you generate your own CSRs, or if you used a client which lets you choose not to generate a new key, you can stick with the old one, and it isn’t necessarily unsafe, although the fresh key would always be safer all things being equal. Because the keys are in pairs, with each private key necessarily corresponding to one public key, Let’s Encrypt would be able to choose to detect key re-use and reject it if they wanted to even though they never know what your private key is - but they do not do this.
For your RADIUS setup I would consider whether you have a secure way to push the private keys out to the servers. If so, I would suggest allowing the keys to change and be updated periodically along with the certificate just because it’s simpler. If delivering new keys securely will be difficult, you might consider using a CSR to force the keys to stay the same for a longer period so that you only have to transport certificates (which are harmless if stolen, though they do need to be delivered intact)
I think I implemented this default in Certbot and the reason was that we're doing most of the steps for you automatically on renewal, so for many configurations and cases we're not making life harder by replacing the key. And we can think of cases where changing the keys frequently would help:
If you have clients that don't negotiate a PFS ciphersuite, changing the private key creates a kind of forward secrecy window, where compromising the private key only compromises the sessions of clients that connected while that particular private key was in use, rather than all sessions.
If there are cryptanalytic attacks that work well against some kind of private key (including because of an RNG weakness or protocol behavior that leaks partial information about the key), changing keys frequently increases the frequency with which an adversary would have to mount the attack and increases the resources required.
If a server is compromised in a non-persistent way, changing keys frequently reduces the impact of that compromise.
If people lose control of key material on old servers or backup media, changing keys frequently makes it unlikely that the old private keys will be useful.
If embedded systems or unattended servers hadn't properly initialized their RNGs when getting their first certificates, changing keys on renewal means that subsequent certificates are more likely to contain a safe subject key, as long as the systems have a long uptime, rather than reusing the more questionable first-boot key.
Some disadvantages:
Changing keys frequently reduces the usefulness of tools like Cert Patrol that could try to tell users about key changes (because there would be frequent false alarms).
Changing keys frequently means that they have to be distributed if they're going to be used somewhere other than where they're generated, which means more people may have access to them and there may be recurrent opportunities to attack the key distribution process.