Securing Your WordPress Website with SSL

We wrote about the importance of using SSL before. And we have been pushing for all our clients to get on board and get an SSL certificate. Not only is it good for SEO, but it also makes sure that browsers this year will not consider forms on your site that take user payment details or password details as insecure if they are not using https / SSL. So let’s talk about securing your website with SSL

Why do you need SSL?

So why do you need it? Well, one, it gives you more authority on the web and better SEO. But also, it is becoming more a more urgent to get an SSL certificate as more and more browsers will flag your sites / pages on your site as insecure when you ask for payment or Credit Card data in forms – think ecommerce – or password and do not use SSL. And that will look really bad on your site. Again, see earlier article on Chrome and SSL push.

What is SSL

SSL or TLS are basically two technologies to encrypt the connection from the visitor of your website to your website. So every time he enters data on your site in forms that data will be sent securely. Once a site is https secure you will see either a green lock in your browser or the lock and the word Secure.

How to get SSL

SSL can be gotten by either paying for an SSL certificate with a company that deals with it, by asking your host to arrange it or by taking care of itself. Normally your webhoster should have options available. Not all hosters have the free Let’s Encrypt option though so you may need to pay around €15-30 a year for it.

User Case

One of our long term clients Het Wapen van Enkhuizen, a hotel in the picturesque Enkhuizen, Holland has just had a lovely upgrade to a Comodo SSL certificate as well and is now completely secure. Giving it more authority on the web, better SEO and better preparation for an SSL only web in the future. Let’s Encrypt was not possible with their Dutch hoster Hostnet. So we went for a Comodo Positive SSL Certificate instead.

Now some technical details

Settings > General URL Change

Here you need to replace http by https. This will not cover all your bases but it is a good and quick start. You can do this in the database as well of course and you could even do this and all replacement in one turn, but that is a bit tougher for most.

Redirects

After adding modified WordPress rewrite

<IfModule mod_rewrite.c>
# BEGIN Force http to https
RewriteEngine On
RewriteCond %{HTTPS} !=on
RewriteRule ^.*$ https://%{SERVER_NAME}%{REQUEST_URI} [R=301,L]
# END Force http to https
</IfModule>

and adding

define('FORCE_SSL_ADMIN', true);

to wp-config.php all traffic got redirected to https.

Hard coded Urls

Then we only needed to replace some hard coded urls inside header.php, style.css and replace image paths. You can do this with Search and Replace Database by Interconnectit or yourself in the database. Just be careful with serialized data.

Image Paths replacement

For replacement of image paths in the database we used the search and replace script of the awesome company Interconnectit. And then we had a great secure Wapen van Enkhuizen!

Interested?

If you are interested in help with Securing Your Website with SSL we can take care of this for a very affordable fee.

Trellis Let’s Encrypt Expired SSL / TLS certificate – Cause and Solution

Though Trellis VPS setups should auto renew the Let’s Encrypt certificate automatically I had a certificate expire for one of my Trellis sites the other day. Here is how I found out about the Trellis Let’s Encrypt Expired SSL / TLS certificate and how I worked out solving it.

Google Search Console Warning

The reason I found out about it was on time and not by visiting the site itself. I got a warning from the Google Search Console:

Expired SSL/TLS certificate on https://domain.com

To: Webmaster of https://domain.com

Google has noticed that the SSL/TLS certificate for https://imagewize.nl/ has expired. This means that your website is not perceived as secure by some browsers. As a result, many web browsers will block users by displaying a security warning message when your site is accessed. This is done to protect users’ browsing behavior from being intercepted by a third party, which can happen on sites that are not secure.

Recommended Action:

Get a new certificate
To correct this problem, renew or get a new SSL/TLS certificate. This should be from a Certificate Authority (CA) that is trusted by web browsers.

And because Trellis uses HSTS I could not even continue to the site despite the warning I should not normally having an option to continue anyways..

Renew Certificate Manually

I checked Roots Discourse and found out I could use the following command to renew the certificate manually:

ansible-playbook server.yml -e env=production -K --tags letsencrypt

That was not enough though. I had to restart NGINX as well. And when I logged in I was told a reboot was needed as well:

dhc-user@domain.com:~$ sudo service nginx restart
dhc-user@domain.com:~$ sudo reboot

Cause Failed Auto Renew

Perhaps the during an auto renew request the server was not accessible. Did not see errors it was down though. I could also not find errors like:

2016/07/08 02:41:31 [error] 7259#7259: ocsp.int-x3.letsencrypt.org could not be resolved (110: Operation timed out) while requesting certificate status, responder: ocsp.int-x3.letsencrypt.org

as mentioned in a thread at Roots Discourse here. So I did not have issues accessing Let’s Encrypt for the renewal either.

Trellis Cron jobs

I checked for cron jobs next using:

for user in $(cut -f1 -d: /etc/passwd); do crontab -u $user -l; done

as root, but no cron jobs were shown for any users . And we do need one to run the Let’s Encrypt auto renew of course. Then I mentioned this on Roots Discourse and got this comment by  CFX:

Please ensure your cron job (normally at /etc/cron.d/letsencrypt-certificate-renewal) has the full path to service in its reload command (original PR2). That was apparently my issue too—renewal was just fine but nginx never reloaded after renewal.

This way I learned the location of the cronjobs. And also that the path to reload NGINX could sometimes be the issue and a full path is needed in those cases. So I adjusted the path. And it was confirmed a little later that this was the main cause.

Cron.d

So through the comment by CFX I found out the cron jobs for Trellis are stored at:

/etc/cron.d/

and the Let’s Encrypt one is therefore at:

/etc/cron.d/letsencrypt-certificate-renewal

And this is the location for cron jobs I did not check. Now that file contains:

30 4 1,11,21 * * root cd /var/lib/letsencrypt && ./renew-certs.py && /usr/sbin/service nginx reload

This is a perfectly normal cron job. Now it also has the full path to reload NGINX properly. This being the issue I will now have the auto renewal work again like it should be.

NB Reading up on cron jobs here at Ubuntu Wiki it is mentioned too so I found out. It is a place where often one liners for particular users are stored instead of using a crontab.