Hosting WordPress on Raspberry Pi Part 6 – Implement SSL

2017 is just a week around the corner and it is time to implement SSL for my WordPress server on Raspberry Pi.

WordPress announced on 1 December 2016 that coming in early in 2017, it will moving toward SSL. WordPress will only promote hosting partners that provide a SSL certificate by default in their accounts. Google has advocated the use of HTTPS and started to add HPPTS as a ranking signal since August, 2014. Data from the HTTP Archive show that the number of HTTPS sites rising by 2.3x, from 5.5% to 12.4% in July 2016 compare with a year ago. It’s important to note that the it took less than a year to secure the same number of sites it previously took 20 years to protect.

httparchive-https-adoption-jul-2015-16
HTTP Archive shows impressive HTTPS adoption between July 2015 – July 2016

Despite HTTPS offers many benefits to both server owners and web users, historically HTTPS was always an expensive initiative. You had to buy certificates, pay extra for hosting, pay extra for your CDN, etc.. Today, you can get a free certificate from Let’s Encrypt. SSL/TLS delivery is included in many CDNs, Cloudflare offer a free shared SSL certificate if you sign up to use their CDN, including the free plan. Many domain registrar resells various SSL certificates. I’m using Namecheap.com as my domain registrar and I’d like to keep everything under one dashboard for easy management, so after some careful evaluation, I’ve decided to purchase Comodo PossitiveSSL certificate via Namecheap.com.

Setting up SSL involved three steps:

  1. Certificate Signing Request Generation
  2. Purchase and Activate SSL certificate
  3. SSL Server configuration

Step 1 – CSR Generation using OpenSSL

Login into the Raspberry Pi, and select the directory where we’d want to keep our certificates and using openssl to generate a Certificate Signing Request:

cd /etc/ssl
openssl req -nodes -newkey rsa:2048 -keyout mydomain.key -out mydomain.csr

Both the key file mydomain.key and csr file can be any name we want, it is a good practise to name it based on the domain name so that it will be easy to remember which domain the files belonging to. The process creates two files. The file mydomain.key contains a private key; The private key is then used as input in the command to generate a Certificate Signing Request (CSR).

Important Note: Do not disclose the private key file to anyone. Carefully protect the private key. Backup the private key and store it in a secure storage, as there is no means to recover it should it be lost.

The openssl program will require some information for generating the csr. For some fields it provides a default setting in []. Enter ‘.’, the field will be left blank.

Country Name (2 letter code) [AU]:
State or Province Name (full name) [Some-State]:
Locality Name (eg, city) []:
Organization Name (eg, company) [Internet Widgits Pty Ltd]:
Organizational Unit Name (eg, section) []:
Common Name (e.g. server FQDN or YOUR name) []:mydomain.com
Email Address []:                         	

Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:

Use the Full Qualified Domain Name (FQDN) of the web-server as Common Name (CN). For example, if the domain name is www.example.com, enter example.com as the Common Name. The fields email address, optional company name and challenge password can be left blank for a web server certificate.

Output the content of mydomain.csr file to the screen with cat command:

cat mydomain.csr

Select the entire outputted data and copy to the clipboard, we will need it for filling up the CSR form later.

Purchase and Activate SSL certificate

Since I’m using Namecheap, so the example here is based on Namecheap. Login into Namecheap Dashboard to make the purchase of Comodo PositiveSSL certificate. Once you made the purchase of the SSL certificate, you will need to activate the certificate. Go to your Domain List on Namecheap Dashboard, and click on Manage button, and the SSL certificate can be found by clicking on Product tab, then click on Activate

Activate SSL certificate on Namecheap Dashboard
Activate SSL certificate

Paste the CSR you generated into Enter CSR text box and press tab, Primary Domain will be automatically populated with your FQDN, select the Apache, Nginx, cPanel or other as the Server Type, and press Submit button to proceed.

CSR Validation
CSR Validation

When asking for DCV Method, select Email from the dropdown list.

Comodo Security Service will send an email with an Domain Control Validation code, copy the code and click on the link provided in the email to complete the validation process.

The certificate signing request and validation process by now is completed and your SSL certificate is activated, and now it is time to configure the web server for using the SSL communication.

SSL server configuration

There are several steps involved in configure the server.

Port Forward for port 443

As I’m hosting Raspberry Pi myself, we will need to setup port forwarding for HTTPS port 443 on the router. As I’ve explained the setup of port forward on previous article so I won’t repeat it again here. Once it is done, we are ready to make some changes on Nginx configuration for SSL access.

Generate SSL bundle certificate

You will receive another email from Comodo Security Services will send another email after the completion of CSR process, the email contains a zip file attachment, download the file. Upload it to Raspberry Pi and up zip it to /etc/ssl/ directory.

Attached to the email you should find a .zip file containing:
• Your PositiveSSL Certificate – mydomain.crt
• Your “CA-bundle” file – mydomain.ca-bundle

We will need to concatenate the the PositiveSSL Certificate and CA-bundle file into a single ssl-bundle.crt file. The order matter, the Certificate should be the first, follow by the CA-bundle. We could use editor to copy and paste it together or use the following cat command to concatenate it together.

sudo su
cat mydomain.crt mydomain.ca-bundle > mydomain-ssl-bundle.crt
exit

Harden SSL security

Mozilla wiki provides many recommendations on how to harden the TSL (SSL) security and is a great resource to understand the subject and even use it to generate the configuration file. Nginx HTTP SSL Module is another resource for getting deeper understanding of each directive setting.

The default nginx distribution shipped with 1024-bit Diffie-Hellman (DH) group, which is most of modern browsers, including Google Chrome, Mozilla Firefox, and Microsoft Internet Explorer currently supported as the the minimum group size. Mozilla wiki however suggests to use a stronger, at least 2048-bit Diffie Hellman group.

First we need to generate a new Diffie-Hellman group using openssl command:

sudo openssl dhparam -out dhparams.pem 2048

This will generated a new dhparams.pem file with 2048-bit dhparam.

Please noted that generating 2048-bit dhparem may take as long as 20 to 30 mins on a Raspberry Pi 3.

Nginx SSL directives configuration

Now let’s configure the nginx configuration file for SSL.

First, We’d want to apply certain directives at the http context of the Nginx configuration, so open /etc/nginx/nginx.conf:

sudo nano /etc/nginx/nginx.conf

Find the section related to SSL directives within the http context and add the following directives:

# Based on recommendation from https://wiki.mozilla.org/Security/Server_Side_TLS
ssl_dhparam /etc/ssl/dhparams.pem;      # 2048-bit DH params
add_header Strict-Transport-Security "max-age=15768000; 
includeSubdomains";     # 15768000s = 6 months
# intermediate configuration that supports some legacy browsers
ssl_ciphers ‘ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES256-SHA:ECDHE-ECDSA-DES-CBC3-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:DES-CBC3-SHA:!DSS’;
ssl_session_cache shared:SSL:10m;	#SSL session cache
ssl_session_timeout 1h;

For site-specific settings, we will need to add to the sites-available/default configuration file:

sudo nano /etc/nginx/sites-available/default

Scroll down to the server section and DELETE the two lines related to port 80:

        
listen 80 default_server;
listen [::]:80 default_server;

Scroll further down a few lines and uncomment out (delete the # in front of each line) the two directives related to port 443:

listen 443 ssl default_server;
listen [::]:443 ssl default_server;

Add the following directives right after the port 443 directives:

ssl on;
ssl_certificate /etc/ssl/mydomain-ssl-bundle.crt;
ssl_certificate_key /etc/ssl/mydomain.key;

# OCSP Stapling
ssl_stapling on;
ssl_stapling_verify on;
resolver 8.8.4.4 8.8.8.8;

Redirect all HTTP traffic to HTTPS

As we just took out the directives related to HTTP (port 80), all the traffic using HTTP will be dropped. This means in case someone visits our site using HTTP request (which uses port 80), we’d want to redirect it to use the HTTPS resource (which uses port 443). We need to create another server context block to handle the HTTP redirect, and place it before our existing server context which we just modified for port 443:

server {
	listen 80 default_server;
	listen [::]:80 default_server;
	server_name mydomain.com;
	return 301 https://$host$request_uri;
}

Now all traffic for http://mydomain.com/* will be redirected to https://mydomain.com/*. The redirect response is sent with the HTTP status code 301, which tells the browser and search engines that this a permanent redirect. This makes the browser remember the redirect, so that next time they visit, the browser will do the redirect internally.

Save and quit the editor once it is done. Check the configuration before reload the Nginx configuration with those commands:

sudo nginx -t
sudo service nginx reload

Now if we access our website, we should see a HTTPS padlock sign in front of the URL. The website should now be serving over HTTPS.

Forcing all WordPress pages to HTTPS

After installing a valid SSL certificate onto the server, we need to ensure that WordPress will serve the pages using HTTPS.

Login into WordPress Admin Dashboard, and go to WordPress Settings and change the WordPress Address (URL) and the Site Address (URL) from HTTP to HTTPS, and flush the cache if necessary.

Resolve WordPress HTTPS/HTTP Mixed Content

However, for some of the content created prior the implementation of WordPress HTTPS, we might noticed that the HTTPS padlock icon would be missing, even though the page is served with HTTPS. This is because the page contains some mix content that is served as HTTP, very often related to the images that we added to the page that have hard-coded url. We can leave it as is if there are too many pages to be fixed, or change it one by one.
First, use a testing site called Why No Padlock to do a check the website, it provides a report of all the insecurely-loaded items.

Use the report as a reference, go to Posts Screen and open the post that has mixed HTTPS/HTTP content for editing, use the browser “Find” function (Command-F on Mac) to look for “http://”, and replace it with “https://”, pay attention to the url, we should only change those links for internal content, such as image links on our server. Click on Update to save the changes once is done.

If this still can’t fix all the pages, it likely caused by theme or plugins that using an insured url, this could be javascript file, google fonts, etc. For example, a theme using an insured url like http://fonts.googleapis.com/css?family=Lato:100,400,700 instead of https://fonts.googleapis.com/css?family=Lato:100,400,700. To fixing those, it could be quite technical and more time consuming which is beyond the subject of this article, we should also consider to phase out those theme or plugins that caused the problems. Those are the vendors or partners that WordPress will not promote from 2017 after all.

Test SSL site

To test our site on SSL compliance, run the site through Qualy’s SSL Labs.

SSL test result shows A+ rating
SSL test result shows A+ rating

Leave a Reply

Your email address will not be published. Required fields are marked *