Secure the web with TLS 1.3
Mihalis Tsoukalos reveals how to convert an unsecure HTTP WordPress, Drupal 7 or static Monit page into a safe-as-houses HTTPS site.
Mihalis Tsoukalos explains what you need to do in order to convert an HTTP WordPress, Drupal 7 and static Monit site into HTTPS.
So, you want to convert HTTP sites into HTTPS ones? Then you’ve come to the right place! For this tutorial, an existing WordPress site will be used as the main example, but most of the presented information is generic. The process of switching an HTTP WordPress site to use HTTPS is relatively long, but it’s not difficult to follow – you just have to be precise and patient. Additionally, you’ll see how to instruct a Drupal 7 site to use HTTPS as well as a static web site, which in this case will be the web site of the Monit monitoring tool that runs its own web server.
The https://www.whynopadlock.com web service will come handy in helping you find out whether your HTTPS site has any issues or not. Finally, starting from
Google Chrome version 68, each site that doesn’t use HTTPS will be signified as “Not Secure” by Chrome – this can be seen in the screenshot (right). Additionally,
Google Chrome 69 doesn’t display the word “Secure” any more in HTTPS web sites, and this can also be seen in the screenshot.
What is HTTPS?
HTTP stands for HyperText Transfer (or Transport) Protocol whereas HTTPS stands for Hypertext Transfer Protocol Secure. That last word makes all the difference in the manner that web sites operate. This is because the main problem with plain old HTTP is that it doesn’t encrypt the data (plain text) that’s transferred, which makes it possible for someone to steal it.
Although older HTTPS versions used the Secure Sockets Layer (SSL) protocol for encryption, the latest HTTPS implementations use Transport Layer Security (TLS). This means HTTPS can also be referred to as either HTTP over SSL or HTTP over TLS, respectively.
In practice, what HTTPS does and HTTP doesn’t do is authenticating the accessed web site along with its content. This, in turn, protects the privacy and the integrity of the data that’s being exchanged between the HTTPS client and the HTTPS server. This might not look important, but imagine how serious this can be if you want to connect to the web server of your bank to obtain information about your accounts or to transfer money. Put simply, you’ll want to be certain that you’re connected to the real web site of your bank and that nobody else can see the exchanged data.
SEO stands for Search Engine Optimisation and has to do with getting as much traffic from search engines as possible. Google states that if your web site doesn’t use HTTPS it will lose rankings, which is a bad thing! Therefore, if your company depends on SEO, using HTTPS is mandatory!
About certificates
A certificate is a small digital file that, among other things, contains information about an organisation. What’s important is that the certificate also includes the public key which is required for commencing a secure HTTP session.
Some companies provide certificates at a cost; others provide certificates for free. This tutorial will make use of certificates that are free of charge from Let’s Encrypt. You can obtain your certificates from anywhere you want – the general process will be pretty much identical. So, you’ll need to get a public key certificate for the domain of the web server that should be signed by a trusted certificate authority, which in this case will also be Let’s Encrypt. Additionally, as you’ll learn later on, in this tutorial that certificates expire and need to be renewed. This is like changing your password on a regular basis.
Let’s Encrypt!
You’ll need to have git installed on your Linux machine before being able to follow the rest of this section, because we’re going to download the Let’s Encrypt
utilities. Downloading the command line tools of Let’s Encrypt requires the execution of the following command with root privileges: # git clone https://github.com/letsencrypt/letsencrypt /opt/letsencrypt
The previous command puts the entire Let’s Encrypt installation along with the required utilities inside /opt/ letsencrypt. You’re now ready to create the certificates for your site. Note that this command has nothing to with WordPress or Drupal, or the manner in which you’re creating your web sites.
Get yourself a certificate
Getting a certificate from Let’s Encrypt for a given web site with its own domain name (www.truthtarget.gr) is the first step of making it use HTTPS. It requires the execution of the letsencrypt-auto command as root: # cd /opt/letsencrypt # ./letsencrypt-auto certonly --standalone -d truthtarget.gr -d www.truthtarget.gr ... Problem binding to port 80: Could not bind to IPv4 or IPv6.
Note that if your web site has multiple names (aliases) but a single Apache 2 configuration file, you’ll need to put each one of these names as the value to the
-d option. In this case www.truthtarget.gr can also be accessed as truthtarget.gr , hence the double use of -d .
The last error message says that there’s a UNIX process that occupies TCP port 80, which in most cases is the web server application (Apache or Nginx). In order for the last command to be executed successfully, you’ll need to stop Apache ( /etc/init.d/apache2 stop or service apache2 stop ), execute the command and start
Apache again ( /etc/init.d/apache2 start or service apache2 start ). The screenshot (above right) shows the output of the entire process where you can also see the location where Let’s Encrypt saves the certificates as well as the expiration date of the certificates (“Your cert will expire on 2018-10-07”). The generated certificates for the www.truthtarget.gr site are kept inside /etc/ letsencrypt/archive/truthtarget.gr/ or as UNIX symbolic links in /etc/letsencrypt/live/truthtarget.gr.
At this point you’ll need to go to the directory where Apache keeps its configuration files, to make the necessary changes to the Apache 2 configuration file of your web site. If you have multiple web sites, you’ll need to execute the aforementioned commands multiple times, one for each domain. Put simply, you need a different certificate for each web site that you want to convert to HTTPS.
Configuring Apache
The next step has to do with configuring Apache to use the certificates you created in the previous section. The configuration file of www.truthtarget.gr is called by its administrator as /etc/apache2/sites-available/
truthtarget.gr and is a web site that’s built using WordPress. The screenshot at the bottom of page 90 shows the final version of the Apache configuration file for the WordPress site.
There’s one tricky point here. Although the web site will only work with HTTPS, the Apache configuration file has two sections: one for the good old HTTP and another for the more secure HTTPS. The latter will serve the requests whereas the former will redirect requests to the latter because you still need to have support for HTTP.
Finally, note that HTTP usually uses TCP port number 80, whereas HTTPS uses TCP port number 443.
What about WordPress?
Let’s learn how to configure WordPress, because www.truthtarget.gr is using WordPress to support HTTPS and stop serving pages using HTTP. This is an easy two-step process. The first thing you should do is add the following line in the wp-config.php file of the WordPress site: define( ‘FORCE_SSL_LOGIN’, true );
This change will enable you to connect to the administration Dashboard of your WordPress web site using HTTPS – this is required for making the rest of the changes. If you’re able to connect to the WordPress administration Dashboard using HTTPS, it’s a good indication that your certificates as well as the Apache configuration are both working.
The next thing to do is go to Settings>General in the WordPress dashboard and change the values of both “WordPress Address (URL)” and “Site Address (URL)” to use HTTPS. The screenshot (right) shows the before and after values.
Depending on your web site and the kind of resources it uses, there’s a chance that you might need to install an additional WordPress module to rewrite existing HTTP URLs into their HTTPS equivalent. The plugin that will be used in this tutorial will be SSL Insecure Content Fixer. You can find more information about it at https://ssl.webaware.net.au. Note that if you’re building a WordPress site from scratch that uses HTTPS, it’s likely that you won’t need such a plugin because all links will use HTTPS. However, for existing sites this can save you lots of time!
The screenshot at the top of page 91 shows the settings of the SSL Insecure Content Fixer plugin. Generally speaking, use the simplest level that does your job – this means that you shouldn’t activate the “Capture All” level when the “Content” level is enough. Play with the setting to see what works for you.
Changing .htaccess
The current Apache configuration requires that you make no changes to the .htaccess file that can be found in the root directory of the WordPress installation. However, if you prefer to change .htaccess instead of dealing with the Apache configuration files, you can put the following text in .htaccess:
Bear in mind that making changes to .htaccess has one advantage and one disadvantage. The advantage is that changes take effect immediately without the need for restarting any processes. However, a typo or a misconfiguration in .htaccess can result in your site becoming unaccessible, so test any changes that you make to .htaccess.
If after changing .htaccess you experience any problems connecting to your web site, the first thing to do is temporarily disable all WordPress plugins. This is because WordPress plugins might confuse Apache and perform their own rewriting of the dynamic pages of your web site. The more complex a WordPress plugin is, the more likely it is that it’ll interfere with the rewriting rules of Apache and the .htaccess file!
Renewing certificates
Most of the times certificates need to be renewed on a regular basis. The process of renewing existing Let’s Encrypt Certificates requires executing the following command with root privileges: # cd /opt/letsencrypt # ./letsencrypt-auto certonly --standalone --renew-bydefault -d truthtarget.gr -d www.truthtarget.gr ... Problem binding to port 443: Could not bind to IPv4 or IPv6.
Again, you should stop Apache 2 ( service apache2
stop ) prior to executing the command for renewing your certificates, because if Apache 2 is already running the renew process will fail. So, after stopping your web server, the renew command will succeed and generate a different kind of output. The interesting part of that output is as follows: Your cert will expire on 2018-12-05. To obtain a new or tweaked version of this certificate in the future, simply run letsencrypt-auto again. To non-interactively renew *all* of your certificates, run “letsencrypt-auto renew”
The previous output reveals that the new certificate will expire at the beginning of December 2018 because Let’s Encrypt renews its certificates for three months and this command was executed on September 2018. Using the new certificates requires no extra action from your part.
Finally, you can automate the process and execute the commands for renewing Let’s Encrypt Certificates as cron jobs. However, it would be a good idea to perform the process manually the first time, just to make sure that everything works as expected before using cron. Back in lxF242 tutorials we talked about Munin and Monit. In this section you’ll learn how to convert the Monit site from HTTP, which is what we created in the tutorial, into HTTPS.
Because Monit uses its own web server, the process will be a little different than before. You’ll need to instruct Monit that you want to connect to its web interface using HTTPS and you’ll need to create certificates to support that functionality.
First, you’ll have to make changes to the configuration file of Monit to indicate that you want to use HTTPS instead of HTTP. It’s a good idea to create a back-up copy of /etc/monit/monitrc at this point. So, you’ll need to use the following lines in the set httpd section of /etc/monit/monitrc : set httpd port 2812 and ssl enable pemfile /etc/monit/certs/monit.pem use address 127.0.0.1 allow admin:monit
The critical lines here are ssl enable and the line that establishes the path for the pemfile variable, which is the certificate. Then you’ll need to create that certificate using OpenSSL – please install OpenSSL on your Linux system if it’s not already there. After that you’ll need to execute the following commands with root privileges:
Examine the source code that comes with this tutorial in order to find out the contents of /etc/monit/
certs/monit.cnf, which is the configuration file used by OpenSSL to create the Monit certificate. If the process goes well, you’ll be able to connect to
https://localhost:1234/ without any problems However, there’s a tricky point here. Because the certificate that we used isn’t certified by any organisation, Firefox will complain about that and you’ll have to add an exception to Firefox in order to trust the 127.0.0.1 IP address.
The key takeaway point from this section is that if a web site uses its own web server, the process of converting that site to HTTPS might be a little different. Additionally, making web sites with static files to use HTTPS is much easier than when you have to deal with dynamic web sites.
Good luck with securing your websites. And finally, the author of this tutorial will like to thank Kalliopi (www.popelix.gr) for her help and expertise.