Secure Your WordPress With a Free SSL Certificate in Apache on CentOS 7

July 3, 2015

It is simple enough to use a self-signed certificate to encrypt traffic to your site with SSL, but if you have a WordPress blog or any site that might see lots of visitors, then a self-signed certificate is not an option: How many average users are going to proceed to your site with a warning from their Web browser about an untrusted connection? This guide will show you start to finish how to get a free SSL certificate from StartSSL, install it on your server, configure apache, and set up WordPress to use https.

All of the information I’m using is from these guides:

If you get stuck, it might help to reference one of these guides. My set up is a CentOS 7 Digital Ocean droplet with apache and WordPress, but a lot of these steps should work for other distributions. Also, keep in mind that the free certificate offered by StartSSL is for non-commercial use only.

What you’ll need

StartSSL

Open up Chrome and head to startssl.com. Click on “Express Signup,” fill out the forms and hit continue. Check your email for the verification code. Click the link in the e-mail and you will be asked to generate a private key. Choose “High” for the grade. Once it’s done, click “Install” and Chrome will present you with a pop-up that says it has been successfully installed.

This is not your SSL certificate, it’s just a key that you will use to log in to the StartSSL Web site. Click on “Control Panel” and then “Authenticate.” Chrome will give you a pop-up to authenticate with the site.

Validate your domain

Once you’re in the Control Panel, click on the Validations Wizard tab and select “Domain Name Validation” from the drop-down menu. Choose whichever e-mail you have access to (like postmaster@yourdomain.com).

If you’re using Google Apps for your e-mail provider, you can just create a group called webmaster and give it public access permissions to post to the group. Add yourself to the group and you will get any messages sent to webmaster@yourdomain.com. This is any easy way to get extra addresses forwarding to your main Google Apps account without creating another user.

Check that whatever account you’re using for the validation e-mail and paste in the code.

Create the Certificate

In the Control Panel, click on the “Certificates Wizard” tab. Select “Web Server SSL/TLS Certificate” from the drop-down menu. Hit continue and enter a strong password. You’ll get a text box that contains your key. Copy its contents into your text editor of choice and save the file as ssl.key.

Hit continue and select your recently verified domain. Choose a sub-domain on the next screen. You probably want to pick ‘www’, but it’s up to you. Hit continue and you’ll get another text box, this time containing your certificate. Copy it to your text editor and save it as ssl.crt.

Download the CAs

Click on “Toolbox,” and download the StartCom Root CA and the StartSSL’s Class 1 Intermediate Server CA. Just right-click on the links with those names and hit save as.

Now we need to unencrypt your your private key so that your sever can use it. Do so with:

openssl rsa -in ssl.key -out private.key

You should now have 5 files:

ca.pem
private.key
sub.class1.server.ca.pem
ssl.crt
ssl.key

Note: the private.key file is the unencrypted version of your private key. Make certain that no one has access to it and that you delete it from your local machine once you upload it to the server. It isn’t necessary to upload the ssl.key file to your server. Let’s upload the ones we do need though, using scp:

scp -p 2222 {ca.pem,private.key,sub.class1.server.ca.pem,ssl.crt} user@yourserver.com:/home/user/

In this example, the ssh listening port is 2222, change it to whatever your port is. You can also specify a different destination directory by changing /home/user to whatever you want.

Apache

SSH into your server and let’s get it set up.

$ sudo yum install -y mod_ssl
$ sudo mkdir /etc/httpd/ssl
$ sudo mv {ca.pem,private.key,sub.class1.server.ca.pem,ssl.crt} /etc/httpd/ssl
$ sudo nano /etc/httpd/conf.d/ssl.conf

The first command will install the ssl module for apache, the second creates a directory for your certificate to live in. The third command will move all of your certificate files to your newly created ssl directory. The last will open up the ssl configuration file for apache. Look for this line:

<VirtualHost _default_:443>

Uncomment (delete the # at the beginning of the line) the DocumentRoot and ServerName lines and change example.com:443 to whatever your domain is. It is important that this match what you entered when you created the certificate.

Uncomment these lines as well and change the location of the files to match what’s shown here:

SSLCertificateFile /etc/apache2/ssl/ssl.crt                           
SSLCertificateKeyFile /etc/apache2/ssl/private.key                        
SSLCertificateChainFile /etc/apache2/ssl/sub.class1.server.ca.pem

Once you’re done, save and close the ssl.conf file and open up your site’s configuration file:

$ sudo vim /etc/httpd/sites-enabled/yoursitesname.com.conf

And add these lines before the closing :

RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI}

This will force https for the whole site, so that even if users don’t type out https:// before your address, they will still be protected.

Restart the apache server:

$ sudo systemctl restart httpd

Test that it works by going to https://yourdomain.com. You should see a little lock in the address bar. If you get an Untrusted Connection error, then you probably forgot to change the location of the certificate files from the defaults in the ssl.conf file. If you get a lock symbol, but with a triangular alert symbol, then you’ve got yourself a mixed content warning. No big deal, we’ll fix that in the next step.

WordPress

Log in to your WordPress admin portal and click on “Settings,” and change the “WordPress Address (URL)” from http://yourdomain.com to https://yourdomain.com. Make the same change to the “Site Address (URL)” field as well.

If you’ve got the Mixed Content warning, then you’ve got some work to do. This warning basically means that your Web browser has detected some content on the page that is being fetched with plain old http, meaning it’s not encrypted and secure. This could mean anything, but images you’ve added to posts is a great place to start. Take a look at one of your posts with images and view it in text mode. Scroll down to where your image is and check the html, if it looks like this:<img src="http://yourdomain.com/cat.jpg" ... then that’s probably the problem.

There are a number of ways to fix this. If you have a new site, then you can just click through your posts and add an ‘s’ after http to all of your image tags. If you have hundreds or more images, this could get tedious. This guide: Moving to HTTPS on WordPress has some SQL kung fu that might be able to automate the process for you. <iframe> or <link> tags could also be causing the problem if they are calling http. This stackoverflow post has some more info as well.

Keep an eye out for mixed content warnings on other pages, but otherwise you should be done!