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

  • 7
    Personally I was really surprised that CAs even allow renewal with the same key. Jan 10, 2013 at 9:36
  • 5
    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. Jan 10, 2013 at 16:09

10 Answers 10


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.

  • 1
    Why does using a new keypair in the certificate require significantly more work than a renewal with the same key? Jan 10, 2013 at 9:38
  • 5
    @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.
    – Polynomial
    Jan 10, 2013 at 10:03
  • 1
    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...
    – JZeolla
    Jan 10, 2013 at 12:57
  • 2
    @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.
    – Polynomial
    Jan 10, 2013 at 13:14
  • 23
    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.
    – Jeff Ferland
    Jan 10, 2013 at 21:51

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

  • Does renewing a CA certificate (vs creating a new one) complicate path construction or validation? Jan 10, 2013 at 16:07
  • 1
    Here we are talking about the server certificate, i.e. an End-entity certificate, not a CA certificate. Renewing a CA certificate while keeping the same key has the benefit of making it immediately applicable to certificates which were issued with the previous CA certificate, so it is nominally good and makes transitions smoother. It does make path construction a bit more complex, but implementations usually cope with it without any problem (it does confuse some network administrators, though). Jan 10, 2013 at 16:20
  • @ThomasPornin SSH has entirely forward-secret key exchanges, but SSL does not. Do you think that makes a difference in this argument?
    – user12048
    Mar 12, 2018 at 18:27
  • @AlexWebr That should not make a difference. In modern networks, attackers who can eavesdrop are in good position to make an MitM attack as well, making the advantage of forward secrecy rather minor. Mar 12, 2018 at 18:54

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.

  • 8
    This is actually a good point, not brought up in any other answer. Lots of people have access to the key over time, whynot change it? Like you change a door code when an employee leaves? (You do that, right?)
    – Luc
    Feb 16, 2016 at 20:11

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.

  • Although I would not use 1024 bit RSA keys, this point is exactly right. The real danger is not in cryptographic weakness of standard algorithms, but in exploitable software vulnerabilities and the people who manage the server.
    – Mike76
    Sep 25, 2018 at 17:01
  • 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.


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.


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.


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.

  • If I understand correctly, you're rotating the host keys, but not the CA...? What is this solving exactly?
    – N.I.
    Dec 9, 2016 at 9:04
  • This creates a chain of trust whereby the user no longer simply has to blindly trust new host keys. In a could environment where hosts are spun up and down all the time, host key verification is useless because users are trained to simply ignore the warning. This solution allows a config manager to sign keys of new authorized hosts allowing the user to trust keys signed by the CA. A rogue host will present an actionable warning. If you need to replace the CA or rotate the key you need to update the identity of the signing CA on every client. (with your MDM perhaps)
    – jorfus
    Mar 8, 2019 at 18:17

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

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

  • 1
    Just in case for future people, in the 4th revision a nifty table can be found on page 45 (or section 5.3.6) with various information on cryptoperiods
    – DeadChex
    Jan 13, 2020 at 22:42

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.

  • There are reasons not to do it, though.
    – Polynomial
    Jan 10, 2013 at 8:49

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .