SSL certificates don’t last forever, most of them need to be renewed on a yearly cycle and occasionally you will want to change the type of the SSL certificate mid-cycle.
For a lot of developers this can be the first time they have to get their hands dirty in a server and they can find the whole prospect of
.crt files a little daunting.
This quick writeup of how I have updated some SSL certificates recently should hopefully shed some light on subject.
A note on our setup
This particular guide was written after needing to buy some Extended Validation (EV) SSL certificates and they are being installed on a server running Nginx as its web server. The advice transfers to other scenarios as well.
If you want to see our spanky new certificates in action you can read my guide on speeding up your Mac which was posted on one of the sites.
Buying a Certificate
Step zero in all of this is buying your certificate.
For what it is worth I really like Comodo SSL but there are a lot of offerings so you should shop around to find a SSL type and an authority right for you.
Preparing your Server
During the purchasing process you will be asked to provide a CSR file. This will be explained by the company that you use but the general steps are;
- Log into the server
openssl req -new -newkey rsa:2048 -nodes -keyout server.key -out server.csr
This command will ask you some questions about your company and server and once you have answered them it will generate two files.
The first is the private key that will stay on your server and be used to decrypt your SSL certificate.
The second is the CSR, which stands for Certificate Signing Request, this is what you will send to the company. In our example that would be the
If in doubt always follow the instructions sent to you by the company you are buying the SSL from.
The awkward wait
Depending on the type of SSL you are buying you could be issued with an SSL certificate instantly. If you are buying high level one (like we were) then there are some additional tasks you have to perform before you can receive your SSL. These include;
- Verifying you own the domain by receiving an email addressed to it
- Speaking with someone on the phone to verify information
- Having your company address be listed somewhere publicly for verification
In our case we had to do all three.
Setting up your new Certificate
Once you’ve been approved and you have received your new certificates you sometimes need to do some additional setup.
This is because you will be sent several
Most web servers expect to see the
.key file (the one you generated earlier) and one
.crt file, this means that sometimes you need to combine the several files you have received into one.
You should follow the instructions the company sends you but normally you can do something like;
ssl-bundle.crt will be the one
.crt file that we can pass to our web server.
Backing up old Certificates
Since we are replacing certificates we should back up the ones we have. Certificates are text files so this can be as simple as running the copy command;
You will want to do this for both the
.crt and the
If you don’t know where your SSL certs are found you will be able to find them by opening up the config file of your web server, the path to the certs will be listed there.
Adding your new Certificates
Once you have backed up the old certificates just overwrite the two files with your new files.
.key file should be updated with the contents of the new
.key file you generated during the
.csr creation step.
.crt file should be updated with the contents of the
ssl-bundle.crt we created, or the single
.crt file you were sent if it was just the one.
Reloading your Web Server
The final step is to reload your web server so it knows to look at these new certificates.
In our case we use Nginx so it was as simple as
nginx -s reload, some web servers will require a full restart.
You should see the new SSL certificate appear in your browser immediately. If something has went wrong you can always revert back to your backup certificates.