I have already discussed Heartbleed in detail and have provided instructions on how to close the hole on affected server. Now that the hole is closed the final step is changing your server’s private key and “re-keying” your SSL certificates. Re-keying simply involves creating a new certificate signing request and sending it to your (most likely) external certification signing authority. Once received, they should send you an updated key pair. The last step will be telling your application that uses SSL (in this case, and many others Apache) to use the new keys. Lets dive in!
First – note that nothing with your web application will change until we get down to the step where we send the new CSR to your certificate authority (in this case, I will be referencing GoDaddy, you should know who the CA is that provides you with keys). After you send your new CSR to your CA for re-keying, anywhere from immediately to within a few days your existing SSL key pair on your server will be revoked. If you haven’t updated the keys on your server by that point, people visiting your site will most likely get a nasty warning error from their browser and told things aren’t safe (because your site would still be using a revoked certificate). Once you update the keys in you web application setting, it will be using the new keys and all will be well in the world. So first… lets dive in to generating a new unique private key for your server.
Second – You will most likely need root access to your server and be at least a little comfortable with the command line.
Alright, let’s start typing. Once you are logged into your server command line as root (ubuntu, you can elevate to root with the command “sudo -s”) begin with the following. You need to know where you keep your certs, you can check your sites config file in apache if you aren’t sure. To do so, find your sites config by navigating to here:
You should see a list of enabled site configs. Find the one that looks like yours and then open with a text editor like so (my example is “contoso.com” with a config file named “contoso.com.conf”):
Locate the lines that look like this:
The first line is your websites SSL certificate file. The second line is your website’s private key.
Just a note, the private key in particular should be in a completely non-web accessible location, furthermore, the folder should have 0 access except for the root user (sudoers on ubuntu).
The private key is the file we will be generating on our server. Once we create the new key, we will then generate a CSR from it. Then, we will send that CSR to our certificate authority (cert provider) and they will send us a new certificate file back.
The third line is for a “chain file” – which most external public certificate authorities provide and I include although things usually seem to work without it. Okay, now that we know where to put everything, lets jump into generating a new private key and a CSR from that. You can name your files however you please, I am appending “new” to mine to make it easy to differentiate them.
Generate a new private key:
openssl genrsa -out contoso.com.new.key 2048
Generate a new CSR:
openssl req -new -key contoso.com.new.key -out contoso.com.new.csr
You are going to be asked for some information. It is important that this information matches that of your original CSR for the keys that are being replaced. The most vital information to match is when it asks for the “Common Name” (CN) which should be the fully qualified domain name (FQDN) of your website. For example this site page url might be “https://www.contoso.com/somepage” – the FQDN for the site that would be supplied as the CN would then be:
Next, move the private key file into a private directory (assuming your directory structure is /etc/ssl/private)
mv contoso.com.new.key private/
You should now have a new private key in your private directory and a new CSR. I use Putty to administer my servers and the easiest way to get the CSR for my CA is to open it up in a text editor and copy the contents into a new text document on my windows desktop. I then change the file extension on the text document to .csr and send it along to my CA. For rekeying with GoDaddy here is a good informational page: http://support.godaddy.com/help/article/4976/re-keying-an-ssl-certificate
All public CA’s are a little different. In this example I am using GoDaddy. The important thing is that you need to not just get a brand new key. You need to make sure the old key gets “revoked”. With GoDaddy this process is called “re-keying” as you are sending them a CSR that will be used to generate a new SSL crt that will replace the old one they have on file (which will go on their certificate revocation list). You might need to talk to your CA if you are unsure what to do at this point and explain to them that you are trying to rekey or update an existing key as your server’s private key has changed.
Your CA should then send you an email back with the new certificate file and possibly a chain file. You can open up both using a text editor. On your linux box you can create new blank files and copy the information into them with the following:
#copy and paste your information into the file and then save and close it. Then again for the chain file.
Now that you have your new private key, your new signed certificate file, and possibly a new chain file, you just need to update your website’s Apache config file. To do that:
…and then update the file paths in the config file so they point at the new certificate files. They will now look like this:
Save and close the file and finally restart Apache:
service apache2 restart
Finally, to be sure everything took, visit your website in your browser and examine the certificate file (this varies by browser, google it if you don’t know how). Specifically look for the “issued on” date, it should be for the day that your CA create the new certificate you just installed. If it is showing a much older date, then Apache is still serving your old cert and you need to do some troubleshooting.
I hope this helps you stay secure!