Tips for Installing a 123-reg (GlobalSign) Domain SSL certificate on an Amazon EC2 Instance Running Apache 2.*

This process caused me a couple of issues when I came to do it just now, so I hope the following notes might prove helpful to someone (or possibly me next time I come to do this and have forgotten everything I just did!).

In no particular order:

1. Once you have been issued your certificate by 123-reg, I found this page really useful:

http://www.123-reg.co.uk/support/answers/SSL-Certificates/Installing-your-SSL/installing-your-ssl-apache-open-ssl-657/

(Even if there are a couple of all important typo's in there with filenames lol, see if you can spot them! Hint: mydomain.pem should be mydomain.crt in the Apache 1.* instructions. Although I expect most people will be running Apache 2.* nowadays anyway.):

2. Also another thing worth mentioning is that take care when copy and pasting the certificates from the email 123-reg send you, as this seems to have messed the layout up slightly. Once you have your certificate issued you can download a copy of it via your 123-reg control panel.

3. Make sure you have opened up port 443 to traffic in your EC2 Security Group settings.

4. Ensure you have Apache and Mod_ssl installed on your EC2 instance, you can do this by running:

Update: 20th August 2015

I've found the command above can lead to conflicts if you've previously followed the EC2 tutorial for setting up a LAMP web server, so instead try running the following to install mod_ssl (required if you want to install an SSL certificate on your server).

Other than that, the best advice I can give if you're doing this for the first time is to take your time and read everything properly, this isn't complicated, but it's important to get each step right. It's not simply a 'copy and paste' job - well not quite.

Update: 6th February, 2014

Now that I've come to renew my certificate I've found the post above less than complete, so here are a few more pointers about the process and the steps required.

So, taking it from the top...

1. Firstly buy a certificate. I'm going to use 123-reg as I use them for my domains and it's handy to keep things in one place. I've also found them fairly good in the past and they provide lots of useful support articles to help explain the process.
https://www.123-reg.co.uk/ssl-certificates/

I generally opt for a domain SSL as this provides a certificate backed by Globalsign and is still relatively cheap.

2. Once you have bought your certificate, you'll need to assign it to the domain name you want to use. You can do this via the 123-reg control panel.
https://www.123-reg.co.uk/secure/cpanel/ssl

3. During the assigning process you'll be asked to paste in your CSR. This is a text file you'll need to generate on your server. 123-reg have a very handy article here which explains how to do this using OpenSSL
http://www.123-reg.co.uk/support/answers/SSL-Certificates/Generate-a-CSR/generate-a-csr-apache-open-ssl-634/

4. You now need to wait until 123-reg completes your order. They will send you an email once your certificate is ready.

5. The next step is to install your certificate on your server:
http://www.123-reg.co.uk/support/answers/SSL-Certificates/Installing-your-SSL/installing-your-ssl-apache-open-ssl-657/

I'm going to follow the Apache 2.x instructions as that's the version of Apache I have, you probably do as well.

Checking your certificate is installed properly

There is a very handy tool provided by GlobalSign for checking if you've installed your certificate correctly. It's available at:
https://sslcheck.globalsign.com/

In my case I found that the intermediate certificate(s) were not installed correctly, but this was easy to fix as the tool gave me the certificates I needed to install.

Then the following quick update to my apache ssl.conf and a server restart fixed the issue for me.

Another interesting issue is that of BEAST attacks. This is where the hacker is potentially able to decrypt encrypted SSL traffic. To do this they need to have collected lots and lots of encrypted data, and it was originally thought impractical, but apparently in 2011 someone worked out a clever way to do it. So other clever folks have come up with ways to mitigate the problem. Typically modern browsers have fixed this problem client side, but if you want to be ultra safe, then I found the following code seemed to satisfy the checker. More details about the fix can be found here.
https://community.qualys.com/blogs/securitylabs/2011/10/17/mitigating-the-beast-attack-on-tls

Another item pointed out was that our server wasn't including the header 'Strict Transport Security', which forces clients to use secure connections only. This is easily fixed by including the following in the virtual host for SSL traffic.

More on Wikipedia here.

Also for reference, the ssl.conf virtual host looks a little something like the following.

All these fun and games now gives us an A- score, and I'm pretty happy with that.