As you already know, due to the heartbleed bug, we need to perform re-keying on our web servers (>10), before I do that, I want to check if my proposed strategy is a proper way or not

a. Generate a new CSR, submit to Godaddy to re-issue the cert

b. Install the cert and key on web server, and restart as fast as possible

My questions:

  1. Are there any steps I have missed?
  2. In step (a), when the new cert is re-issued, I assume the old one is revoked, but before the new cert is deployed, are there any risk during that time, the client check the revoked cert and experienced error?
  3. Will the client (desktop/mobile) cache the revoked cert? And it will fail to communicate for my new private key even after I have installed the new cert?
  • Can you take your servers off the public-accessible network, then do the update? If only you can reach the server then nobody can use heartbleed to compromise the server while you do the update.
    – Andy Brown
    Commented Apr 14, 2014 at 14:18
  • make sure you upgrade openssl package. With that upgraded, your keys will not leak.
    – user43488
    Commented Apr 14, 2014 at 14:38
  • Important: if you generate a new CSR you also need to generate a new key. It is not uncommon to request new certrificates with the old key. But this is generally bad and especially bad for heartbleed mitigation.
    – eckes
    Commented Apr 25, 2014 at 12:10

2 Answers 2


You assume incorrectly: a cert does not have to be revoked when re-issued. It is typically a different process altogether. This means that you should add a last step to your plan: revoke the old certificate once you are done with installing the new one.

Clients will not cache your certificate. In fact, they cannot keep a cached copy since it is your server that is sending your cert as part of the SSL handshake. They might keep a copy of the CRL in cache for as long as it is valid but that should have only very limited impact on security and none on availability.

Finally, you don't have to restart the servers, you can just restart the process/services using your certificates. It will still cause existing connections to be dropped but it should be much faster than restarting the whole server.


Let's assume, for an instant, that you really need to "re-key your Web servers" because of the heartbleed bug (if there is such a need, then you quite logically also need to do it for every other similar vulnerability which shows up, hence several times per year, and you must also do it for vulnerabilities which will show up, so, by that reasoning, your brand new key will be immediately toast as well). Let's also assume that re-keying is sufficient (there again, a fallacy: if an attacker could obtain your private key, then he could also obtain all your confidential data, so the problem has a much larger scope).

Under these assumptions, the model is that of a compromise of your private keys (that's what you fear). You need to do two things:

  1. Declare the old certificate as invalid, so that clients cease to trust it. This is known as revocation.

  2. Obtain a new certificate with a new key that the attacker does not know of.

There is no conceptual need for doing things in that order. In fact, you usually want the new certificate to be up and running before the old one is revoked. It so happens that some CA insist on binding the two operations together, i.e. revoking the old certificate and reissuing the new one concurrently (one reason for doing so is commercial: you paid for one certificate, so you should get one non-revoked certificate at any time).

Fortunately, a few characteristics will help you:

  • Clients do not cache certificates. In the SSL/TLS protocol, the server systematically sends its current certificate, and the client will always use that one, not a cached version.

  • Revocation is asynchronous: when a certificate is revoked, its serial number will be included in the Certificate Revocation List published regularly by the CA. Usually, it will take a few hours before revocation is effective (it depends on the CA policy). Moreover, clients do cache CRL, so even if a new CRL is immediately published by the CA, clients who connected a few hours ago will still operate on the old one, until it expires. (OCSP may reduce the time window, though.)

  • Many clients don't bother checking CRL anyway, so, from their point of view, the old certificate will never be revoked.

It still is in your best interests to complete the procedure quickly, i.e. within a few minutes. Anyway, you MUST be able to do that process properly, because certificates expires: you are just doing it early (out of a sense of deference to the current wave of ill-informed paranoia).

You must log in to answer this question.

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