Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

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

share|improve this question
1  
Personally I was really surprised that CAs even allow renewal with the same key. –  CodesInChaos Jan 10 '13 at 9:36
    
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. –  makerofthings7 Jan 10 '13 at 16:09
add comment

7 Answers

up vote 21 down vote accepted

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.

share|improve this answer
    
Why does using a new keypair in the certificate require significantly more work than a renewal with the same key? –  CodesInChaos Jan 10 '13 at 9:38
2  
@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 '13 at 10:03
    
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... –  Steel City Hacker Jan 10 '13 at 12:57
1  
@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 '13 at 13:14
1  
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 '13 at 21:51
add comment

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.

share|improve this answer
    
There are reasons not to do it, though. –  Polynomial Jan 10 '13 at 8:49
add comment

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.

share|improve this answer
add comment

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.

share|improve this answer
add comment

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

share|improve this answer
    
Does renewing a CA certificate (vs creating a new one) complicate path construction or validation? –  makerofthings7 Jan 10 '13 at 16:07
    
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). –  Thomas Pornin Jan 10 '13 at 16:20
add comment

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.

share|improve this answer
add comment

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.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.