Yes, that’s right. When I inevitably lose control of a key, a shorter certificate lifetime limits how long the attacker can use the stolen certificate/key pair.
I have concerns about the fact that you find it “inevitable” that you’ll lose control of your private keys less than 90 days after issuance in a manner that wouldn’t also compromise the next set generated. The odds of someone having the resources to break the key in that timeframe are effectively zero, so you’d have to be worried about them being exposed somehow. If someone is able to access your servers and copy the key once, they can do it again when you change it.
Why do you believe this to be inevitable?
New vulnerabilities are being discovered daily; it’s inevitable one of these will be for software I’m running that is exposed to the Internet.
In my environment, I store the issuing keypair/account info (aka certbot’s config directory) on a separate machine from the actual Internet-facing machine. Only the fullchain.pem and privkey.pem files are pushed to my Internet-facing machine. When I detect a compromise on the Internet-facing machine (in the worst case, seeing my certificate being used maliciously on the Internet), I can stop giving it new certificates. The renewal keys are safely stored away from the compromised machine.
Since revocation doesn’t really work, I have a strong desire to limit the lifetime of that stolen Internet-facing certificate by issuing shorter-lived certificate in the first place.
Way off topic…
But would a reverse proxy help in hiding/protecting your systems from attacks/exploits?
I personally do not see forcefully changing the 90 day limit as a useful tool. The reality is most certs out there for protecting web servers are 1-2 years and in some cases 3 years so to me sub 90 days is for the paranoid. However I support the option for those users who require it to specify a shorter lifespan. perhaps even specifying the drop dead date.
Unreliable certificate revocation is a different issue. No matter what your certificate lifetime is, if your private key is compromised it only takes minutes to effect an exploit. Unless you become aware your key has been compromised you cannot take action anyway so even a 1 week certificate leaves you wide open. If you are unaware your server is exploited (say a rootkit) then you can change your private key as often as you want, you are still hosed.
I use the very powerful and well written getssl bash script and it has the option to renew private keys every time or not depending on your use case. It also allows user to use a number of different verification methods so for internally accessible only web servers we run an external service (on a completely different machine) that allows for validation. getssl runs on a third machine not accessible externally pushing challenges via sftp to the verification server.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.