AWS WordPress 6: HTTPS Access

Overview

This post is the sixth of a 6-post series with step-by-step procedures that I followed recently to setup WordPress on AWS for this version of the website. In this post, the steps to convert the website access to https (i.e., padlock icon on browser’s address bar) are detailed. I am a fan of incremental testing so the success of each step is confirmed with a simple test prior to proceeding.

HTTPS

HTTPS (Hyper Text Transfer Protocol Secure) is an access protocol that allows a web browser to connect securely with a web server. HTTPS is one of the basic mechanisms to secure a web browsing session since data transfers are encrypted (i.e., data is not transferred as plain readable text). To implement HTTPS on an AWS EC2 Apache web server hosting a WordPress website requires creation of an TSL/SSL certificate for encryption. Certificates are used within web servers to encrypt the traffic between a web server and a web browser.

AWS EC2 Security Group Changes

Since HTTPS internet communications occur on port 443, we need to add this port for the in-bound traffic. On the AWS console, select the ‘Services’ pull-down menu (or click on EC2 if it is visible in ‘Recently visited sites’) and click on EC2. Click on ‘Security Groups’ and select the security group (e.g., ‘example-security-1’) associated with the instance created for this series. Selecting the ‘Inbound’ tab should display a list of listeners as shown below:

Click on ‘Edit’ and add the following two entries for type (‘HTTPS’, which will result in the ‘Custom TCP Rule’ type), port (443) and sources (0.0.0.0/0 and ::/0). For this example series, keeping the SSH port 22 accessible from all internet addresses is tolerable. For a real development or production EC2 instance, the SSH internet address source should be constrained to specific internet addresses associated with admin/developers to improve security.

Install Certbot repository

At this point, we need to fetch and deploy on our web server an authoritative SSL/TLS certificate for encrypted communication. Cerbot is a software client that, in our case, is installed on the EC2 Ubuntu instance. Cerbot fetches and deploys SSL/TLS certificates from Let’s Encrypt for web servers. To add the Cerbot repository to the EC2 instance, re-open SSH access to the EC2 instance via terminal (Mac OS) or PuTTY (Windows), as described in previous parts in this series, and use the following commands one at a time.

sudo apt-get update
sudo apt-get install software-properties-common
sudo add-apt-repository ppa:certbot/certbot
sudo apt-get update
sudo apt-get install python-certbot-apache

To confirm that the Cerbot repository was installed, we can check for its version.

certbot --version

Certificate installation

To install a single certificate that is valid for multiple domains or subdomains, the domains are passed as additional parameters to the certbot command. The first domain name in the list should be the base domain (e.g., example.com) used by Let’s Encrypt to create the certificates:

sudo certbot --apache -d example.com,www.example.com

During execution of this command, there are several prompts asking about the certificate configuration and information: Provide an email for lost key recovery and notices, choose between enabling https-only access or forcing http requests to redirect to https. It is usually pragmatic to select the option to redirect http to https. When the certificate installation has completed, the certificate files should be located in this folder ‘/etc/letsencrypt/live’.

To conduct an SSL/TSL server test of the certificate, go to SSL Labs and enter the website address (e.g., https://example.com). Although the goal is to get the successful result shown in the following diagram, I am truly amazed by the amount of information (not reproduced here) produced by SSL Labs during this SSL/TSL server test.

Certificate Renewals

SSL/TLS certificates expire (e.g., after 90 days). To renew the certificate, we can conduct a dry-run of the renewal with cerbot:

sudo certbot renew --dry-run

To automatically renew the Let’s Encrypt certificate, we will edit the root users crontab file:

sudo crontab -e

When the command prompts for selection of a CLI editor to use, select ‘nano’. Then, add the following line to the bottom of the file:

@daily certbot renew --quiet && systemctl reload apache2

Then, press ctrl-x, type y, and return to save.

Configure WordPress to use https

Although the web server is now using the SSL/TLS certificate and accepting https communication, we still need to update the configuration of WordPress to support https access. First we need to update a few files via SSH from either terminal (Mac OS) or PuTTY (Windows) using ‘nano’ as the CLI editor.

Add the following two lines to the ‘wp-config.php’ file (folder location: ‘/var/www/wordpress’) just above the /* That’s all, stop editing! Happy blogging. */ line:

define('WP_HOME','https://example.com');
define('WP_SITEURL','https://example.com');

Make the changes to the ‘wordpress.conf’ file (folder location: ‘/etc/apache2/sites-available/’) so that it contains the following content (assuming the domain is example.com):

<VirtualHost *:80>
  ServerName example.com
  DocumentRoot /var/www/wordpress
  DirectoryIndex index.php
  <Directory /var/www/wordpress/>
    AllowOverride All
    Order Deny,Allow
    Allow from all
  </Directory>
  RewriteEngine on
  RewriteCond %{SERVER_NAME} =www.example.com [OR]
  RewriteCond %{SERVER_NAME} =example.com
  RewriteRule ^ https://example.com%{REQUEST_URI} [END,NE,R=permanent]
</VirtualHost>

Make the changes to the ‘wordpress-le-ssl.conf’ file (folder location: ‘/etc/apache2/sites-available/’) so that it contains the following content (assuming the domain is example.com):

<IfModule mod_ssl.c>
  <VirtualHost *:443>
          ServerAdmin cary@example.com
          ServerName example.com
          ServerAlias www.example.com
          DocumentRoot /var/www/wordpress
    DirectoryIndex index.php
    <Directory /var/www/wordpress/>
      AllowOverride All
      Order Deny,Allow
      Allow from all
    </Directory>
    ErrorLog ${APACHE_LOG_DIR}/error.log
    CustomLog ${APACHE_LOG_DIR}/access.log combined
    Include /etc/letsencrypt/options-ssl-apache.conf
    Include /etc/letsencrypt/options-ssl-apache.conf
    Include /etc/letsencrypt/options-ssl-apache.conf
    SSLCertificateFile /etc/letsencrypt/live/example.com/fullchain.pem
    SSLCertificateKeyFile /etc/letsencrypt/live/example.com/privkey.pem
    Include /etc/letsencrypt/options-ssl-apache.conf
  </VirtualHost>
</IfModule>

<IfModule mod_ssl.c>
  <VirtualHost *:80>
    ServerName example.com
    DocumentRoot /var/www/wordpress
    DirectoryIndex index.php
    <Directory /var/www/wordpress/>
      AllowOverride All
      Order Deny,Allow
      Allow from all
    </Directory>
    RewriteEngine on
    RewriteCond %{SERVER_NAME} =www.example.com [or]
    RewriteCond %{SERVER_NAME} =example.com
    RewriteRule ^ https://example.com%{REQUEST_URI} [END,NE,R=permanent]
  </VirtualHost>
</IfModule>

Make the changes to the ‘.htaccess’ file (folder location: ‘/var/www/wordpress/’) so that it contains the following content:

## EXPIRES CACHING ##
<IfModule mod_expires.c>
  ExpiresActive On
  ExpiresByType image/jpg "access plus 1 year"
  ExpiresByType image/jpeg "access plus 1 year"
  ExpiresByType image/gif "access plus 1 year"
  ExpiresByType image/png "access plus 1 year"
  ExpiresByType text/css "access plus 1 month"
  ExpiresByType application/pdf "access plus 1 month"
  ExpiresByType text/x-javascript "access plus 1 month"
  ExpiresByType application/x-shockwave-flash "access plus 1 month"
  ExpiresByType image/x-icon "access plus 1 year"
  ExpiresDefault "access plus 1 month"
</IfModule>
## EXPIRES CACHING ##

# BEGIN WordPress
<IfModule mod_rewrite.c>
  RewriteEngine On
  RewriteBase /
  RewriteRule ^index\.php$ - [L]
  RewriteCond %{REQUEST_FILENAME} !-f
  RewriteCond %{REQUEST_FILENAME} !-d
  RewriteRule . /index.php [L]
</IfModule>

# END WordPress

With these changes in place, it is necessary to reboot the ECP instance for these changes to take effect. To reboot the ECP instance, enter the following command:

sudo /sbin/reboot

Exit from either terminal (Mac OS) or PuTTY (Windows), and wait a couple of minutes for the reboot to complete. At this point, access the website from any browser, as indicated below, and check for the following:

  • Access using ‘https://example.com‘ and verify website appears and address bar shows the ‘https://example.com‘ address.
  • Access using ‘http://example.com‘ and verify website appears and address bar shows the redirected ‘https://example.com‘ address.
  • Access using ‘https://www.example.com‘ and verify website appears and address bar shows the redirected ‘https://example.com‘ address.
  • Access using ‘http://www.example.com‘ and verify website appears and address bar shows the redirected ‘https://example.com‘ address.
If these tests for https access and redirection are successful, then access each page on the website and look for the padlock symbol in the address bar. The padlock symbol in the address bar indicates that the webpage is fully secured. It can take one nonsecure item on the webpage to disable the padlock symbol. If the padlock symbol appears in the address bar for each page on the website, we are done. If there are web pages that do not display the padlock symbol in the address bar, then use Why No Padlock? to identify the specific reasons (e.g., accessing an image using http instead of https). Fix the identified reasons on each webpage to get the padlock in the address bar.

Conduct Speed Tests for each Webpage

It is informative to run a speed test on webpage access, starting with the home page for the website. I especially like Pingdom because it breaks down access times for each item (e.g., css files, javascript files, fonts, images). The report and, especially, the detailed time plots provide an amazing amount of useful information regarding access times.

Summary

This six-part series on setting up a WordPress site on AWS using an EC2 instance (Ubuntu 16.04) with a LAMP stack results in a very cost-effective WordPress website hosting solution.

Reference Material

Certbot Installation Guide

Getting Started with Let’s Encrypt

SSL Labs

Why No Padlock?

Pingdom

2018-12-07T18:00:35+00:00By |Amazon Web Services, Wordpress|

Leave A Comment