Many months ago I noticed that I logged into my blog over plain HTTP and thought to myself that I really must do something about that one day. And that day is… well… a couple of days ago! I honestly was never really too concerned about logging in insecurely as the chances of anyone actually wanting to gain access to this blog and being in a position to exploit the insecure login is minimal. My guess would be that the majority of self-managed WordPress installs are administered over plain HTTP.

So apart from general apathy, what kept me from fixing this? Cost was probably the main issue… Any cost for a SSL certificate would not be particularly justified in my case. I also did not want to use a self-signed certificate as I find the security warnings that all web browsers give about untrusted certificates annoying enough to not want them on my site. That also rules out the free SSL certificates from CAcert, as the CAcert root certificate is not included by most browsers by default.

Then I saw a post somewhere about the free certificates given out by StartSSL. The price is right and the root certificate is commonly included so all seems good. There is not much actual validation that goes on to get one of these – my email and domain name were “verified” by sending emails… – so they would not be good for any site where trust is actually needed (such as anything where any personal and financial data are being collected).

Once validated, all I had to do was provide a CSR and they provided me the certificate. My webhost then uploaded that certificate and broke everything! The HTTPS version of my site was giving the error “ssl_error_rx_record_too_long”, which is actually quite uninformative as it covers a wide range of actual issues, and the HTTP version for some reason lost all access to files even thought they were clearly still there when I checked. This took me a few hours to notice as I had to wait for the DNS entries to propagate, so the issue was reported at 5pm on Friday the 30th of December… I really thought my website would be down until the 3nd of January when the support desk reopened, but everything was fixed a few hours later. So good service given what I pay, but the whole issue could have been avoided with a simple check at their end once the SSL certificate was installed.

Once you have your SSL certificate installed and ready to go, making WordPress enforce SSL usage for all administration tasks is simple. Simply add the following to your wp-config.php file:

define('FORCE_SSL_ADMIN', true);

Now all your blog administration is secure(ish). The final thing to do was to check whether browsing my website using HTTPS worked… No, it did not! I was getting messages about the site only being partially encrypted. A quick search showed I serve all my images using the full URL rather than a relative one. I did this because a certain Linux distribution’s Planet feed did not show images otherwise (or at least that was the case a long time ago – I have not tested lately). I could go through and adjust all my image links to use HTTPS, or just disable HTTPS access to my website. I chose the latter as nothing on my site is that important that it needs to be encrypted and I thought it would be the quicker option… Several hours later and this is the rule you need to add to your .htaccess file to achieve this:

RewriteCond %{ENV:HTTPS} on [NC]
RewriteRule !^wp-(admin/|login.php|includes/|content/)(.*)$ http://allanmcrae.com%{REQUEST_URI} [R,L]

The only real trick there is that the WordPress login and administration interface uses files from the wp-includes and wp-contents directories so they need to be excluded from the RewriteRule.

So… remember how I said self-signed certificates were annoying as all visitors to the site would get a warning. Well, now I force HTTP usage, that whole argument is irrelevant as only I would see the SSL certificate when I access the administration interface. But I at least have the option of serving parts of the site over HTTPS using a recognized certificate if I ever feel the need.