Is it necessary to periodically re-key end entity SSL certificates apart from typical scenarios like Key lost/key compromise? What benefits does it provides in terms of security and others? Is there any guidelines for that period?
The security comes from replacing your private key in case it was exposed. Exposure doesn’t always mean a bad guy got it, they can just be accidents that leave your org vulnerable if a bad guy shows up and tries to exploit them.
Exposures can happen in a lot of ways: the password can be written to a log file, the key could be stored on a system unencrypted in 644 mode, copied on backups that are not properly secured, etc. Every rotation has the potential to reset things so the mistakes made handling the old keys within the prior period no longer matter.
Of course correcting the underlying mistakes is another issue entirely. But here’s a win: let’s say the mistake of the last period was an insecure backup, and your backup team recently solved their problems. The next time you rotate the key, you’ve eliminated the exposure without doing anything extra.
Also, if an attacker does obtain a key, we know that formulating an attack utilizing the stolen key can take time. An aggressive rotation schedule with short expiration dates might prevent the attacker from exploiting it.
This means that replacing a certificate too far in advance of its scheduled expiration is of no value. Replacing a certificate doesn’t alter the expiration of the previous one.
Another thing to consider is if your organization is bound by external contracts such as PCI DSS, they may be required to have an info sec policy that says, “all keys shall be rotated annually.” In that case, there’s no point in holding a discussion — certificate rotation is simply a requirement.
So, there are some security benefits to generating new keys and issuing new certificates. What are some of the drawbacks?
All X.509 certificates have an expiration date. If they’re allowed to expire because someone forgets to renew them, you will suffer an outage. These can range from small to catastrophic. Paradoxically, a short expiration period can be a benefit here, as it will incentivize the sysadmin to automate the certificate renewal process (certbot is your friend.) A long expiration period may be so long that manual maintenance gets forgotten.
TLDR : no it is not necessary as far as your certificate has a 1 or 2 years validity period.
Re-key a SSL certificate means a complete change of it (as the public and the private keys are changed). You cannot keep some parts of the file and change others at the owl file is signed. So "re-key" a certificate is more like put it in the trash and make a new one.
The main benefit of re-key a certificate is obviously to address the scenario where the private key is compromised.
If you know that your private key is compromised, the response is to revoke the certificate, not only renew it.
If you have no clue that your private key is compromised but you want to address the risk in the event of an unknown compromise, the correct periodicity should be something like every year. And, basically, one year is a common validity period for an end point certificate (3 months with let's encrypt). So, in any case the certificate expires after one or two years and the new one will have a different keypair (except if you explicitly mention that you want to reuse the same key).