On this page:
Recently, when I’ve been logging into this website on my computer, I’m warned that the connection is not secure and anyone could see my password.
I’ve also been receiving quite a few emails requesting a password change for my admin account.
A while ago, my website was repeatedly hacked, which resulted in the database going down.
All these things have contributed to my decision to secure my website with SSL. This won’t make it 100 % secure, but it’s a start. And I’d get a shiny symbol in the browser’s address bar. The address would also change from http://pandammonium.org/ to https://pandammonium.org/. Snazzy!
The process of securing pandammonium.org
To secure a website, you need a certificate. In the past, this has always seemed to cost extra, so I hadn’t ever bothered. Now, I’m not too bothered how much it costs, as long as it’s not exorbitant.
My domain name is registered with DreamHost, so that was my first stop. To my delight, they now offer free certification using a company called Let’s Encrypt. It seemed very easy: select the domain you want to secure and click a couple of buttons. However, my domain didn’t show up in the drop-down box of available-to-secure domains. I found this frustrating.
I remembered I had Cloudflare doing its thing, so I looked there next. Again, I could secure my site for free using them. There were several options. The first was Flexible SSL, which you could use if you couldn’t control the origin, which I couldn’t. The problem with the Flexible SSL option was that some content might still be insecure. I didn’t want that.
A solution reared its pretty head: I could use Cloudflare to create my own certificate and key. I did that, but then was scuppered at the next step because DreamHost limits access to the file I needed to alter.
DreamHost: help request
I wrote to DreamHost to ask them for help. When I read their reply, I felt like such an eejit: they’re not even hosting my website, Digital Ocean (DO) are. I’d forgotten all about that, in my frustration.
I went to Digital Ocean’s website and looked to see how to add SSL support there. It was all very confusing, because they expect you to know what you’re doing, unlike DreamHost, say, who make it easy for you. I eventually found a community tutorial page on the DO website that told me how to secure Nginx with Let’s Encrypt on Ubuntu 14.04. I was pleased to see there was a method using Let’s Encrypt, so it would be free, but the server was wrong. I hoped there’d be something similar for Apache, so I googled the title, making the relevant changes. I excluded the Ubuntu version number from the search because I didn’t know which one I had on my server.
The search results gave me what I wanted for a choice of Ubuntu versions. Luckily, when I
sshed to my server, the server replied with information such as what version of Ubuntu it was running. That meant that all I had to do was follow the instructions on how to secure Apache with Let’s Encrypt on Ubuntu 16.04.
Of course, it wasn’t as easy as that. I got stuck when I came to step 2, setting up the SSL certificate because of this error:
Failed authorization procedure. pandammonium.org (tls-sni-00): urn:acme:error:tls :: The server experienced a TLS error during domain verification :: remote error: tls: handshake failure
I had no idea what this meant. I was frustrated again. Colin asked me about my DNS settings. They all pointed to the right place. Cloudflare had some TTL settings for each DNS record.
The relevant TTL setting was set to automatic. Other options were various lengths of time, so I picked one of them and reran the failing command.
Instead of failing, it asked me if I wanted to always redirect HTTP requests to HTTPS requests (and to only do this if I was sure my site worked over HTTPS. I decided that it would because it was WordPress).
Then it gave me this message:
Congratulations! You have successfully enabled https://pandammonium.org
I tried opening the HTTP version in Chrome; it redirected to HTTPS, as expected, but it also told me there were insecure items on the page. What was the problem? Colin came to the rescue using Safari’s Web Developer tools: the background image wasn’t secure.
I got the same result in Firefox and Opera, but not in Firefox Developer Edition (FDE), where it wouldn’t load at all because it reckoned there were too many redirects.
I went into my WordPress settings and discovered that the background image’s URL was indeed HTTP, but that I couldn’t change it. Colin asked was there not somewhere where you told WordPress the URL or some such. Oh yeah, there is! I changed it to use the updated URL:
The background image still reckoned it wasn’t secure, despite now having an HTTPS URL. I had to reupload the image and set it again for each time it was used as a background in my theme, and then, I hoped, it would be fully secure.
Testing: almost successful
I opened my website in the various browsers, and they all showed my site to be fully secure. I was very happy till I opened it in FDE: still too many redirects. At that point, I remembered about Cloudflare’s SSL settings.
The SSL settings in Cloudflare were still set to Flexible:
Visitors will be able to access your site over HTTPS, but connections to your origin will be made over HTTP. Note: You may encounter a redirect loop with some origin configurations.
A redirect loop, eh? Cloudflare provide more information about why Flexible SSL can cause a redirect loop. I needed a different SSL setting.
The most relevant setting seemed to be Full SSL (strict):
Your origin has a valid certificate (not expired and signed by a trusted CA or Cloudflare Origin CA) installed. Cloudflare will connect over HTTPS and verify the cert on each request.
I chose this one and tested my site in FDE.
The redirects in FDE ceased and desisted, allowing the page to load, all happily secure. I tested the other browsers: success!
You can use Let’s Encrypt to secure your website relatively easily, depending on your choice of hosting provider, and for free, but if you use Cloudflare, you’ll need to change the TTL setting of the appropariate DNS setting from automatic to a given length of time. You should also set your SSL encryption to Full SSL or Full SSL (strict). (I didn’t test what happens if you have this set to Off.)
Comparison with DreamHost
To compare the above palaver with DreamHost’s system, I picked a website hosted by DreamHost and clicked a couple of things to tell it to set up encryption with Let’s Encrypt. They sent me an automatic email to tell me it was all in hand, with no problems. So much easier! But I suppose I’ve learnt something.
What I’ve learnt
Always remember exactly what services you use to host your website and bear in mind how any changes you make in one service affect another.
Always use a development environment to test stuff like this so that problems like redirect loops are found.