(Update 2020-04-24: About two years after the making of this article, some of the content has changed, specifically regarding software updates for the GCP Click-To-Deploy VM, as well as different prompts from LetsEncrypt. The post has been updated to reflect the changes.)
This is part 3 of a three-part guide to setting up and configuring WordPress hosted on Google Cloud Platform and registered with a Google Domain URL. Readers should make sure their WordPress instance is running and behaving properly using GCP, have WordPress admin access, and registered their custom domain (eg http://www.example.com) before attempting this section.
To prevent bulking of a single article, I separated this holistic guide into three separate parts. Feel free to jump to the previous articles when you need any past references. For your convenience, the guides are outlined below:
Table of Contents
Why Should You Do SSL Verification?
There are multiple reasons; without going into too much details, here are some important ones:
- Increased security via encryption – connections to your site will be encrypted and therefore safe from evildoers who may capture information without you noticing.
- Increased user trust – Internet users generally feel more safe browsing an HTTPS site rather than an unsecured HTTP site (see that “unsecured” warning beside your URL when you go to your current WordPress site? Sounds ominous… doesn’t it?)
- Increased SEO performance – Search engines favor HTTPS sites and will rank them higher in the search results in order to promote Internet safety for all users.
- Finally, by routing all of your HTTP traffic to HTTPS, it helps with your site traffic analysis in that you won’t have to aggregate both the HTTP and HTTPS pageviews – all traffic will be recorded as HTTPS which makes for easier viewing.
So, in a nutshell, unless you don’t want your site to do well, you MUST make sure your site is secured using HTTPS (via SSL verification) :).
General Steps To Add SSL Certificate to Your WordPress Server
- Log into your WordPress server via SSH.
- Using the default package manager (“apt-get” for Debian 8 for Google Cloud Platform WordPress Click-to-Deploy), install Certbot under administrator.
- Make backup of your Apache2 settings (for possible rollback purposes).
- Execute Certbox command to “semi-automatically” generate SSL Certificate and modify Apache configurations to allow HTTPS.
- On WordPress Admin Console, inside General Settings, change Hostname and SiteURL to reflect its HTTPS equivalent.
- Verify HTTPS connection to your WordPress Site.
- [If something went wrong or it doesn’t work] Rollback.
Pre-Requisites
Note that this is the last post from a three-part guide about how to set up WordPress using Google Cloud Platform (GCP) and Google Domains. That said, as of July 2018, the WordPress Single Instance Click-to-Deploy solution contain the following important and relevant configurations (versions have changed as of 2020-04-25):
- Debian 9.11 “Stretch” as Linux OS.
- Apache 2.4.25 as the webserver. Its configurations are located in /etc/apache2/ . The Click-to-Deploy solution comes with separated default-ssl.conf and wordpress.conf Apache config files.
- WordPress 5.2.3, which root hosting directory lies under /var/www/html/ .
This guide is not guaranteed to work for different versions of the Linux OS, nor if the server is not deployed using GCP’s Click-to-Deploy method. Proceed at your own risk.
Installing Certbot
Certbot is an easy way to enable HTTPS on your server using the free, open Let’s Encrypt certificate authority. In the Certbot homepage, if you input “Apache” under the Software field and “Debian 8 (Jessie)” in the System field then you will get this page which will guide you through a somewhat automated installation of your SSL certificate. Unfortunately, blindly following what is written on that page will get you into some errors when configuring Apache due to the way the WordPress Apache is set up. There are a few things to watch out for, but the next few sections will go into detail about exactly what you should do. Do not fret!
Certbot doesn’t exist on the server by default, so it will need to be installed via the following command (You may CTRL-V to paste any copied text into the SSH terminal)…
sudo apt-get install python-certbot-apache -t stretch-backports
… which will take around thirty seconds. A bunch of installation messages will come up but you may proceed if you don’t see any errors.
Make Backup of Apache2 Configurations
This guide will modify the Apache settings. In order to rollback in case anything goes wrong, it is strongly advised to backup some of the configuration files so that we can overwrite them with the originals easily to restore access to the HTTP WordPress site. To do so, execute the following commands which will essentially backup the entire folder and its contents into a backup directory:
cd /etc/apache2/ && sudo cp -R sites-available sites-available.backup
One of the steps in the rollback section of this guide includes removing the sites-available directory and renaming the sites-available.backup to sites-available, effectively restoring the original configurations.
Execute Certbot for Automatic SSL Certificate Generation and Apache Configuration
An additional preparation we need to do is to un-comment some parameters in the apache files (it appears that the default WordPress installation has these commented out by default). The automated SSL Certificate configuration will fail if we do not comment-in these fields. To do so, let’s do a full search-and-replace of #SSLCertificate and replace it with the non-# equivalent:
sudo sed -i 's/#SSLCertificate/SSLCertificate/g' /etc/apache2/sites-available/default-ssl.conf
And let’s add in an Apache service restart to update the changes:
sudo service apache2 restart
We are now ready! To execute the automatic SSL certificate generation and Apache configuration, run something similar to the following command:
sudo certbot --authenticator webroot -d ##DOMAIN_NAME## -d www.##DOMAIN_NAME## -w /var/www/html/ --installer apache
Where ##DOMAIN_NAME## should be replaced with the custom domain you have registered for the site.
If you deployed WordPress using GCP’s Click-to-Deploy method, your WordPress should be served from /var/www/html/ – you can leave it as-is.
Here is an example command I used for this site:
sudo certbot --authenticator webroot -d jiyuulife.net -d www.jiyuulife.net -w /var/www/html/ --installer apache
Once you execute, it should ask for your email address, so go ahead and fill it in:
Next it will ask you to agree to the Terms of Service. Once you have, proceed by typing ‘A’ and pressing return:
Next, since there are multiple configuration files inside Apache, the automated SSL certificate service is not sure which Apache settings to modify. When the prompt appears, choose the number corresponding to the “default-ssl.conf” file. If default-ssl.conf does not exist, then choose the one with your hostname in the middle column and HTTPS to the right of it (and example is below with filename “000-default-le-ssl.conf”):
Once you’re done with that, there is a prompt asking you if HTTPS is optional or mandatory. There’s really no reason to use HTTP at all, so choose the “Secure” option (“Redirect” for new version of LetsEncrypt as of 2020-04-25).
And that’s it! You should be brought to a congratulations prompt…
LetsEncrypt issue certificates with short life-spans, so it becomes imperative to renew certificates in a timely manner. As of 2020-05-13 certificates last for three months so we will need to schedule a job so that we won’t need to touch the server so often. For websites I maintain, I set a cron job to check and renew certificates on a weekly basis.
The below command will append a certbot cron job to run the certificate renewal command every Sunday at midnight. I did not use @weekly as it may not be compatible for some flavors of Linux OS. Also, the “-q” parameter silences normal output and will only log errors which are saved to a file for future reference:
crontab -l | { cat; echo "0 0 * * 0 sudo certbot renew -q"; } | crontab -
Make sure that the above command is added successfully and that your current cronjobs – if any – were not modified in any way:
crontab -l
(Update 2020-04-24: The below is no longer available UNLESS you upgrade LetsEncrypt to version 0.32.0 or higher. The stretch-backport version of LetsEncrypt is only version 0.28.0 which is bugged and cannot run dry tests. More information here.
You may attempt to upgrade LetsEncrypt but I give no guarantees that it will run smoothly.)
Your SSL is now set up and ready to go. An an optional procedure, it is recommended to perform a certificate renewal dry run to test that your certificate will be renewable then the time comes. You can try it using the following command:
sudo certbot renew --dry-run
Change Hostname and SiteURL in WordPress Admin Console
Go into your WordPress admin console’s General Settings area, and change the WordPress Address and Site Address to reflect the HTTPS equivalent. An example is below:
Making a change like this is known to cause issues with Permalinks, so we will need to press the update button on those settings as well. Go to Settings -> Permalinks, and just hit the “Save Changes” button without changing anything on the page.
Verify HTTPS Connection to Your WordPress Site
Everything should be all set and good to go! Check that the various combinations of URLs will direct to your HTTPS-enabled site. Some examples are below:
- example.com
- http://example.com
- www.example.com
- http://www.example.com
- etc…
IF Something is Wrong, Rollback!!!
If you come across any issues and need to revert to the original settings, you will have to perform the following:
- Restore sites-available directory
- Disable SSL
- Restart Apache
- Update General Settings on WordPress Admin Page
To restore the sites-available directory, use the following command in the terminal (assuming you followed the backup procedure above):
cd /etc/apache2/ && sudo mv sites-available sites-available.auto && sudo mv sites-available.backup sites-available
This will essentially exchange the current Apache configurations with the original – the copy before you attempted this guide. As you can see, it does not do any deletions, so you are free to review the changes and do some debugging later.
Just changing the Apache configuration files will not cause an update on the current Apache service, so we will need to do that manually. However, we must first run a command to disable SSL:
sudo a2dismod ssl
And then restart:
sudo service apache2 restart
Finally, go back to your WordPress Admin Console and change the WordPress Address and Site Address back to HTTP equivalent, and update permalinks again. This is basically the reverse of Figure 2-1 and Figure 2-2 above.
Feel free to comment if you spot any errors or if the guide is incomplete in any way, and I will update it ASAP. Thank you!