The Heartbleed bug in OpenSSL caused a lot of heartache for Web sites and services around the Internet. I don’t use SSL on any of my sites but the discussion of encryption and Web privacy got me wondering how hard it would be. Other than my own logins, there really isn’t anything to protect but it made me curious if, perhaps, I should join the many sites that are encrypting everything. If you’ve visited the site in the past month, you may have noticed that it was using SSL. This is how I activated it and also why I’ve turned it off.
Getting Started – Your Certificate
The first thing you need is to get your SSL certificate. You can create fake certificates but Web browsers are getting increasingly good at catching those and throwing up warnings that indicate that there is no certificate-granting authority behind them. If you are using SSL on the Web, you should really get a certificate from someone. I decided to use a free service called StartSSL which offers a one year free certificate. Comodo, which has endpoint protection software, also has a free certificate but it is only good for 90 days.
There’s not much to say about the process. You sign up and provide a certain amount of information. It is surprisingly little considering that you are warranting that the connection is secure. There appears to be a check by StartSSL people to confirm that the site appears to belong to me. Once confirmed, there were a number of files that I needed to download in order to be able to start serving up secure connections:
These files enabled the secure communication with the StartSSL servers to confirm that, in fact, I had an authentic certificate. It is worth noting this because it was the first time I’d really dealt with “what happens when you make an SSL connection”. Normally, when you hit a Web server for a page, it sends it – and any associated files – to your browser and you’re done. With SSL, it does the same thing but it also engages in a number of back-and-forth exchanges with the certificate provider. You can see this in a Cloudflare post that shows the handshaking that happens.
Setting Up Apache
Once I had the certificate, I needed to configure Apache, my Web server software, to use it. I came across Nik van der Ploeg’s tutorial – which includes how to get a StartSSL certificate – and was able to continue from there. My steps were exactly the same:
- make a directory for those four files downloaded, above. You may have more depending on your certificate. I placed them in /etc/apache2/ssl;
- edit your virtual hosts file, which should be located in /etc/apache2/sites-enabled. If it isn’t 000default, it will be something similar unless you have renamed it.
Here is where I ran into a couple of changes. Once you have set up the <VirtualHost *:443> for the SSL connections, you need to indicate which protocols to use. I tested my installation out after finishing using Qualys SSL Labs free SSL Test service. It showed that SSL was working but that it didn’t support forward secrecy. Long story short, if a key used in the SSL is exposed in the future, forward secrecy ensures it doesn’t expose anything. To add this functionality, I had to tweak a line in Nik’s tutorial to go from:
SSLProtocol all -SSLv2 -SSLv3
to include additional elements in the SSLCiphersuite line:
SSLProtocol all -SSLv2 -SSLv3
SSLCipherSuite “EECDH+ECDSA+AESGCM EECDH+aRSA+AESGCM EECDH+ECDSA+SHA384 EECDH+ECDSA+SHA256 EECDH+aRSA+SHA384 EECDH+aRSA+SHA256 EECDH+aRSA+RC4 EECDH EDH+aRSA RC4 !aNULL !LOW !3DES !MD5 !EXP !PSK !SRP !DSS”
Once added and retested on Qualys’ site, the SSL was supporting forward security.
The last step was to force all visitors to this site – http://www.ofaolain.com – to go, instead, to the new SSL version – https://www.ofaolain.com. This is another easy change in your Apache sites-enabled file. In my case, at the end of my <VirtualHost *:80> – my original, unencrypted virtual host entry – I added:
Redirect permanent / https://ofaolain.com/
The solitary / represents anything from the current Web site and the following URL shows where to send it. The page name, folders, etc. in the rest of the URL is just appended. If you are using Google Webmaster, they now handle https:// and http:// versions of the site separately. You will need to set up a new profile for the secured content or you will see a drop off on your Webmaster view and not see the redirected visits.
SSL and WordPress
SSL was now working just as it should and visitors were being placed on the https: version automatically. But in WordPress, some content – like images – may be coded to use http:// instead of https://. If this happens, then the Web browser may indicate that, while the site is saying it is secure, it is displaying a mixture of secure and insecure content.
This post by Clifford Paulick is a great overview of what the issue is and a variety of ways to fix it for WordPress. The easiest solution for me was to use a free HTTPS fixer plugin and I selected the SSL Insecure Content Fixer. I have WordPress in a multi-site environment, so I installed it and activated for the network and it immediately fixed the problem for my SSL sites.
Turning Off SSL
It was an interesting experiment. I decided to turn off SSL because it really is pointless for a content site like mine. It was useful to gain the deeper understanding about how all of this works but, in the end, it just meant that my little server was even slower as it was going through all of those handshakes.
If I had a reason to use SSL again, I would not use StartSSL. Since getting my free certificate, I have seen complaints about their processes for getting rid of certificates. If I was paying, I’d go with a company with which I’d already done business, like GoDaddy or Comodo. There are plenty of other certificate providers and for US$60 you can get a one year SSL certificate that you can use on your Web site and mail server if needed.