Tuesday, 5 May 2015

Setting up SSL is still way too painful

SSL Everywhere is well meaning enough (although there are still some reasons that I have read about why it is not such a good idea for everything).

Anyway, I thought I would have a go today on our marketing web server, the one that serves the business web site. It is running Wordpress on Apache and it already has SSL setup since it used to be used to redirect to a forum site over ssl.

The ssl cert that was already on there was out of date so the first thing was to update it with the new certificate, a wildcard one which was on my local machine. MMC.exe on Windows doesn't seem to offer PEM as an output format so the first thing was to output the pfx as a pem format and this required OpenSSL. For some reason, the instructions I read didn't work directly out of open ssl so I had to run the console first by entering openssl.exe and then putting the following command into the console:

pkcs12 -in \path\toinput.pfx -out \path\to\output.pem -nodes

I realised that nodes isn't the plural of "node" but is "no des" meaning that the private key is not password protected, which is obviously required by the web server to use on a web site.

I then uploaded this, copied it into /etc/ssl/certs on the Linux box, changed its ownership to root using sudo chown root:root /etc/ssl/certs/mycert.pem and then set the permissions to 644 using sudo chmod 644 /etc/ssl/certs/mycert.pem

I then modified one of my existing configs which was a redirect that took anything from port 443 and redirected it to the main website on http instead. This was already setup for SSL so I changed the SSLCertificateFile to point to the new PEM file and then commented out the now invalid SSLCertificateChainFile, which ideally would contain the trust chain of the certificate and which avoids the browser from having to do extra work itself.

All good now? Nope, it didn't work, one of Chrome's famous ambiguous errors that make it sound like SSL is not enabled. Fortunately, I knew it was working previously (if not, I would have been really confused since I wouldn't have known what else was wrong). Because I did know that it used to work, I knew that something was wrong either with the config or with the certificate (or chain) that I had just uploaded.

I went to the Mozilla site and copied their "secure" config settings just to make sure that when it did work, it would work securely. Obviously that didn't make it work!

Eventually, only when I did a side-by-side with another known-working config did I spot the simple mistake. My virtual host entry was using domainname.co.uk:443, which didn't trouble me initially because I expected it to use SNI. Well even though apache does support SNI, you still can't specify the host name in the virtual host, it is only specified in the ServerName attribute and will use SNI if required.

At last!

But....

..Wordpress. So great in many ways and so poor in others. Most of the existing links were all http so I got a mixed warning on the browser bar. This is not strictly Wordpress's fault but it would take a lot of work to either find-and-replace all links in the database and modify them to use https or find them manually on each page and fix them. In my case, as with many others, there are loads of redundant pages and it would take too long to examine them all. It is also risky to do any kind of find and replace in the database since you cannot prove that what you have done has a) Not changed things it shouldn't have by accident or b) Left things unchanged that should have been changed. It would leave you with a site that you might have broken somewhere.

Also, Wordpress uses the site url and adds that to the start of every link so presumably, you cannot run ssl and non-ssl side-by-side as I would have liked while the updating work takes place but would need to redirect everyone to the ssl site automatically which means everyone's greeted with a nice warning triangle on their browser bar.

Nice idea "SSL Everywhere" but still more work to do!
Post a Comment