Should I change the private key when renewing a certificate?
My security department insists that I (the system administrator) make a new private key when I want a SSL certificate renewed for our web servers. They claim it's best practice, but my googling attempts have failed to verify their claim. What is the correct way?
The closest I've found is Should I regenerate new SSL private key yearly?, but it doesn't really explain why it would be necessary to change the keys.
I know it's not a big deal to change the keys while I'm at it, but I've never been one to just do what I'm being told without a proper reason or explanation :)
Personally I was really surprised that CAs even allow renewal with the same key.
Interestingly as @Thomas Pornin mentions below, The same security department `will not insist on generating new keys yearly for their SSH servers, even though the situation is similar, from a security point of view.` `...it is inconvenient since it breaks the .ssh/known_hosts files of clients.`
I would say that their suggestion isn't a very solid one, unless you're using horrifically small key sizes - in which case you have a different problem altogether.
A 2048-bit key, by most estimates, will keep you safe until at least the year 2020, if not longer than that. If you're running with 1024-bit keys or less, you're below the standard, and I recommend updating to 2048-bit immediately. If you're currently using 1536-bit keys, you should be safe for a year or two.
Of course, this is all academically speaking. The likelihood of someone being able (or inclined) to crack your 1024-bit SSL key within a year is extremely low.
As mentioned in the question you linked, there are benefits and drawbacks.
- Gives an attacker less time to crack the key. Somewhat of a moot point if you're using reasonable key sizes anyway.
- Halts any evil-doers that may have compromised your private key. Unlikely, but unknown.
- Gives you a chance to increase your key size to be ahead of the curve.
- Doesn't really give you any concrete protection against key cracking unless you're using terribly small keys.
- SSL checking / anti-MitM plugins for browsers might alert the user that the key has changed. This is, in my opinion, a weak drawback - most users won't be using this.
- Might cause temporary warnings in relation to more strict HSTS policies and implementations.
- It requires work. You could be doing something else.
So on both sides there are some weak reasons, and some corner-cases you might need to consider. I'd lean slightly towards the "don't do it unless you need to" angle, as long as you're using 2048-bit keys or higher.
The most important thing is to ask them why they think it's necessary - it may be that you have an infrastructure-related reason for updating the keys which we don't know about. If they can't come up with a solid argument ("why not?" isn't really valid) then they should probaly re-evaluate their advice.
Why does using a new keypair in the certificate require significantly more work than a renewal with the same key?
@CodesInChaos It doesn't, but updating any associated client certificates is certainly a lot more work. If I remember correctly, when you update the server cert without changing the key, you can keep all of the client certs with no issue. But if you change the key, you have to renew all of the client certs too.
Also you will often need a full restart of your web server (Referring to Apache, but assuming others would require the same) if you change your key, but you can do a graceful restart (No downtime) if you're only changing the certificate. Of course all of this could be mitigated by having a HA environment, but still...
@SteelCityHacker That only becomes an issue if you're running a site with thousands of hits per minute. In most cases you might be unlucky and get a single request during the restart of the Apache service, since it's so fast.
It is important to note that silent loss of control of the key is another risk. Are you certain that nobody has mishandled a server in the past years in a way that may have leaked a key? That nobody has some copy laying around? New cert, new key. Starting that clock over again usually matters **more** than the risk of somebody factoring your key no matter what the keysize.