I am using Crypt::LE for Windows on multiple servers in our environment, and I want to make sure our processes are best practices as well. I have read that it is not mandatory to use a new private key, but it is better security (like changing a password over time). Here’s one of the threads that made me think along these lines: https://stackoverflow.com/questions/2787653/renew-certificate-with-java-keytool-reuse-old-csr
Should I be generating a new CSR (and/or private key) each time I renew a certificate? Here’s the renewal command I use for Crypt::LE
The above is a piece from a larger batch script. In this command, I’m specifying the path to the “csr” & the “csr-key” (which seems to be the private key).
If I need to generate a new CSR or private key each time, I could just make my script delete the existing one(s) before running the above renewal command. Then, since this command has “–generate-missing” it should create whatever isn’t there. @leader - maybe you can shed some light on how your client handles CSRs/private keys and what is best practice with it.
Similar to changing a password, the idea of rotating (replacing) keys is that if somehow bad guys learn an old one, but you’ve replaced it that won’t matter. The only reasons to generate a new CSR would be that you had a new Private Key, or that you change which names you want on the certificate. The Certificate Signing Request essentially proves that somebody who knows this Private Key wants a certificate for a particular identity (one or more names), so if you (cause software to) choose a new Private Key you must also (cause software to) make a new CSR to go with it.
Private Keys used for the Web PKI will be far too large for a bad guy to ever guess them, unlike some passwords, and so the only possible way they can know a key is by getting a copy of it (for RSA keys there can be some corner cases where bad guys don’t have the key but get the benefit of it via an Oracle, but they probably aren’t relevant to you). You should consider whether you have any practices that would make it easier for bad guys to get keys after a time - maybe old backup tapes are thrown in the trash six months after the last backup taken with them, a bad guy could steal one from the trash.
But yes, the most secure way forward would be to generate new keys periodically, and every time you renew a certificate is a perfectly reasonable time to do that unless there’s something that makes it difficult to do. The Python “Certbot” tool does this by default.
That is correct, removal of those files would result in generating a new key and csr. The client application does not enforce any specific policies on the user regarding that - as long as the files are in place, they will be used. If they are not, then the process will either stop (if --generate-missing was not used), or will generate new ones (if --generate-missing was used).
How often you would want to rotate is entirely up to you in this case - the best policies might need to be adjusted to the specifics of your infrastructure (and how you store and distribute the certificates and related data).
Just thought about this some more, and I had some more questions…
If I’m replacing the private key (and thus generating a new CSR), is this still considered a cert “renewal” or am I basically generating a new cert?
If I’m generating a new cert, should I revoke the old cert?
Trying to figure out if I should be throwing away the private key / CSR every cert renewal (since it’s automated, why not?) or maybe do that once a year or every 180 days.
According to Let's Encrypt, the certificate is identified as a "renewal" or "duplicate" only by the subset of your domains contained in the certificate. So even if you use a different key and CSR, but have the same subset (same domains in the CSR than your old certificate), that certificate is considered as "renewal".
You probably should not do this unless you have a reason to think the old key is compromised. The old certificate will expire naturally. You could choose to revoke the old one immediately, but it makes it awkward if you have any sort of "roll back" scenario even one you might not think about in this context. For example suppose you back up the servers every night, on Monday morning your system automatically generates a new key and requests a new certificate, restarts any services - then revokes the old one. Tuesday morning the server is unresponsive and making a strange purring noise, rebooting doesn't help. You restore the Sunday night backup to another server, but it has the old certificate, which was revoked. You may take several hours to discover what is wrong and fix it.