Should I change the private key when renewing a certificate?

Question

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 :)

Answer 1

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.

Benefits

• 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.

Drawbacks

• 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.

Answer 2

Changing the private key is not a best practice, it is a widespread practice; it has in fact very little to do with security, and a lot to do with how common CA handle certificate renewals, i.e. most of the time like a new certificate, with a new private key generation. It is simpler, on the CA side, not to do anything special for a renewal. Hence the habit of changing the keys.

The same sysadmins will not insist on generating new keys yearly for their SSH servers, even though the situation is similar, from a security point of view. Or, more precisely, changing a SSH server key is a bit inconvenient since it breaks the .ssh/known_hosts files of clients. Therefore it is customary to avoid changing SSH server keys. Thus, SSH server keys are long-lived. Nobody really skips a heartbeat on that. Why should they worry about SSL keys of similar cryptographic strength ?

The best practice is to change the key when technological advances have made your key somewhat vulnerable, taking into account the general paranoia (often called "for compliance reasons"); so you would consider that right now, in 2013, a 1024-bit RSA key ought to be replaced with a longer one, even though we are still far from being able to break such a key. If your RSA key is 1536-bit or wider, there is no cryptographic reason to make a new one (but, there again, maybe it is just more convenient to change it, on the CA side).

Answer 3

The answer is not technical or crypto, it's about people. With things like job changes (heard of disgruntled admins?), server migrations, DR tests, backups and such the private keys can become a bit exposed.

Given the above, key renewal is a security best practice.

Answer 4

Don't worry about somebody factoring your RSA key. Factoring a 1024 bit RSA key might be possible for state level adversaries, but even for them it's probably not cost effective. Factoring 2048 bit keys probably won't be possible for some decades.

I'd worry mainly about your private key getting stolen in a server compromise. The gain in case of past compromises is a bit unclear, since the attacker might have persistent malware on your server. So you'd need to re-install the server to secure the new key.

Another problem is that some weak SSL suites(mainly the RSA encryption based family) use your long term key for confidentiality, and not just for authentication. With those a compromise of your server key allows decryption of all past SSL communications with your server that used such a weak suite. Using a new key and securely deleting the old one limits the impact of such an attack.

So if your server still has those suites enabled, I strongly recommend changing the key regularly.

Answer 5

• Did you change your keys after HeartBleed?
• What do your data center techs do with bad hard drives?
• Has anyone left the ops org in the last year?
• When's the last time you rotated admin passwords and ssh keys?

All of these questions should start you thinking about the integrity of your keys. I'm not saying it's likely they're compromised or that anyone is going to be able to misuse them. I'm trying to get you to think about why you might want to rotate them.

Rotating keys should be super easy and is a good security hygiene. If you're not doing it because it's hard that's a serious problem. Build the tools and processes to make it easy. If you don't, you'll end up failing to rotate far more important things.

Answer 6

The more you use a key, the more time you give an attacker. Even though breaking 2048 bit is not considered possible with the current technology, being extra cautious and replacing the key is not at all a bad thing.

Moreover, someone could have managed to get your private key,without you being able to detect it. If he cannot repeat the action, then the advantage of the renewal is very clear.

Answer 7

While I agree that there is little technical reason to generate new keys every time you renew a certificate, I would not immediately challenge your security team/managers and call them on the issue.

There can be non-technical reasons which are just as valid to generate new keys. For example, in a large organisation where there are varying levels of IT centralisation, skills, procedures and sound practices, a centralised security management area may require such practices to assist in mitigating some of the risks.This can also help keep procedures smaller and more manageable. While more complex procedures may be more correct from a technical perspecitve, they are harder to document and make it harder for staff to know they are following them correctly. Provided the practice does not create significant overhead, it may well be easier to adopt and maintain the simpler always do X approach.

Think about it from another perspective. Is everyone in your organisation who has any responsibility for managing certificates have the same awareness and understanding of the issues as you and are they as thorough/dedicated? What is the level of staff turnover and to what extent is there a need to be concerned about the amount of sensitive data ex-employees may have access to etc.

Whenever considering security, the human factor is nearly always as important or more important than just the technical aspects. Policy and procedures need to consider the human element and try to ensure that these policies and procedures are structured in such a way as to help enable staff to do the right thing, even when they may not fully understand why they need to do it.

Answer 8

Several people have brought up the fact that ssh host keys are rarely rotated as an argument for not rotating ssl keys. That just seems like another problem to solve. (I apologize for a slightly off-topic answer, but several people here mentioned it so it seems appropriate)

See my answer above for why one might wish to rotate keys.

The following will be particularly useful for everyone who, for compliance reasons, is required to rotate ssh host keys, but who worries about the usability impact on end users.

1) Deploy an ssh_ca (Remarkably complete instructions in man ssh-keygen)

ssh-keygen -f ssh_ca -b 4096

2) Distribute the certificate to your users: Add certificate authority line to ~/.ssh/known_hosts

@cert-authority *.domain.name ssh-rsa AAAAB3[...]== Comment

3) Sign your host keys (be sure to restrict each to an individual host)

ssh-keygen -s ssh_ca -I host.domain.name -h -n host.domain.name -V +52w /etc/ssh/ssh_host_rsa_key.pub

4) Configure server(s) to present certificate (/etc/ssh/sshd_config):

HostCertificate /etc/ssh/ssh_host_rsa_key-cert.pub

Any host key signed by the CA is now trusted by the client (no more blindly accepting a key sig the first time you connect)

Rolling the host key can now be done with no disruption to clients. The key signing can be rolled into the host build/orchestration process.

This is a good reference. This project created some useful tools around using ssh_ca for auto-expiring user access.

Answer 9

SP 800-57 Part 1 Revised, Recommendation for Key Management

NIST recommendations on RSA cryptoperiods seems to be 1-2 years.

Answer 10

It's the same as changing passwords really. If someone is in the process of cracking your password when you change it, they'd have to start over. Or if the password, or private key, was stolen, renewal would invalidate their stolen key (assuming that they can't easily steal it again).

It might be a good habit to change the private key every year or every few years just so that you know it won't break anything when you need to change it, but it's not necessary for the certificate's security per se.

Answer 11

Old topic - but an important aspect not covered here is that a "renewal" can generally be actioned within a 90 day window - from 60 days prior to 30 days after expiry. Ref: https://ie.godaddy.com/help/renewing-my-ssl-certificate-864

A "rekey" on the other hand requires the certificate to be updated within 72 hours. https://ie.godaddy.com/help/rekey-my-certificate-4976

The question to ask is "are we concerned that the key may have been compromised?". If the answer is "No" then a renewal requires less time and is easier to coordinate, especially when involving multiple parties.