GoDaddy SSL Certificate Installation on Apache (Ubuntu 18.04) for WordPress Single Site

GoDaddy makes it easy to purchase a SSL certificate, but their instructions for installing it on Apache (Ubuntu) are nearly impossible to follow. We’ll walk through the steps of purchasing and installing a GoDaddy SSL certificate on an Apache (Ubuntu 18.04) server with WordPress Single Site installed.

To purchase a GoDaddy SSL, please click here and return once you’ve made your purchase. Please note that these instructions require you to have SSH access to your Ubuntu server. Please contact your server administrator if you are unsure about access.

As a prerequisite, please download, install and activate the Really Simple SSL WordPress plugin. You can download it with the link or install it from within WordPress by going to Add New Plugin and searching for Really Simple SSL. You’ll need this in Step 7 to help activate your SSL in WordPress.

Step 1 – Generate a CSR and Private Key in AWS

Connect to your AWS ec2 instance.

$ ssh -i "yourAWSpemKeyHere.pem" ubuntu@ec2-XXX-XXX-XXX-XXX.us-[your-region].compute.amazonaws.com

You’ll need to use your specific PEM key file for the ec2 server and replace the address and region with your specific settings. Those settings can be found in your AWS console by checking the box next to the server and going to grey Actions button and selecting “Connect”.

Once connected to your AWS ec2 instance, you’ll install openssl to generate your csr. First, we’ll ensure you have all the necessary updates.  

$ sudo apt-get update 

Next, we’ll install openssl.

$ sudo apt-get install openssl

If it installed successfully, you should see a message like this:

We are now ready to generate a CSR and Private Key. First, navigate to the correct directory so that you don’t have to move both files later. You should have a directory similar to /etc/ssl/certs. 

$ cd /etc/ssl/certs/

Now we will generate the CSR and Key files.

$ sudo openssl req -new -newkey rsa:2048 -nodes -keyout yourdomain.key -out yourdomain.csr

Please replace ‘yourdomain’ with something like launchpaddigital, omitting the .com extension. This will generate a private key and CSR named domain.key and domain.csr respectively and put it in your current directory. It will ask you to enter few details like Country name; State, Organization name, email address, etc. and make sure to enter right information as it will be later checked by a certificate authority. Note that the extra attributes are not required. Your Common Name or FQDN is your domain name (e.g. launchpaddigital.io).

Step 2 – View and Copy Contents of CSR and Key files

You can view and keep the private keys on your server that you may need later. However, do not share it with anyone. To view the contents of the private key file, navigate to the directory where the key file is stored then view the file with:

$ sudo cat yourdomain.key

Remember to use the name of the key you generated in Step 1. You can select and copy the key file contents, including the the BEGIN PRIVATE KEY and END PRIVATE KEY tags, and paste into a txt document locally for you to keep in a safe place. If you didn’t navigate to the /etc/ssl/private directory when you created your key pair, you’ll need to do that now. If you did, skip this piece. Next, we’ll move the key file to the private directory by navigating to the directory that it is in and moving the file with:

$ sudo mv yourdomain.key /etc/ssl/private/yourdomain.key

To view the contents of the csr file, navigate to the directory where the csr file is stored (you should still be in it) and view it with:

$ sudo cat yourdomain.csr

Remember to use the name of the key you generated in Step 1. You must select and copy the csr file contents, including the the BEGIN CERTIFICATE REQUEST and END CERTIFICATE REQUEST tags. That was all you need to know about generating a certificate signing request (CSR). Now you can get an SSL certificate from GoDaddy by pasting the content of CSR file on the order form when enrolling for an SSL certificate.

Step 3 – Request SSL Certificate

After you’ve purchased your SSL, use the SSL wizard to request your certificate. Log in to your GoDaddy account and open your product. On the Certificate Setup page, click Input a CSR. (This is where the steps deviate from the normal GoDaddy instructions. Paste the CSR text (remembering to including the BEGIN CERTIFICATE REQUEST and END CERTIFICATE REQUEST tags) into the box and click continue.

 

Step 4 – Verify Domain Ownership

After you request an SSL certificate, you need to verify that you control all domain names listed in your request. If your SSL cerificate is in the same GoDaddy account as the domains listed on the request, you don’t need to prove that you control the domain – they do that for you. If your SSL certificate is in a different account than the domain(s) on the request, choose one of these methods to prove you control the domain(s):

• GoDaddy will send a verification link to a list of email addresses on the domain(s). The email address must be one of the following: admin@, administrator@, hostmaster@, postmaster@, or webmaster@. If you don’t have one of these set up already, create one and they will send you that link within 24 hours. Clicking the link proves you have domain control.

• If your SSL certificate is not in the same account as your domain(s) and you cannot set up an email address on the domain(s), you need to verify you control the domain name(s) via DNS or HTML. For information on that process, see Verify domain ownership (HTML or DNS) for my SSL certificate.

After you complete one of the domain control proof options, your certificate will be issued within 1 business day (usually faster depending on the type of certificate that you requested). Keep in mind that manual verification processes are dependent on you completing the task, and the certificate will not be issued until you prove that you have control of the domain name(s).

 

Step 5 – Download and Copy Certificate Files to AWS

Once the SSL certificate is issued, log back into your GoDaddy account and navigate to the SSL product. Click the download button.

Select ‘Apache’ under the Server Type option and click Download Zip File. Extract those files from the zip folder, keeping in mind the location that you put them. You can skip the option for Installation Instructions as that’s why you’re already here. Now we’ll copy the files from your local machine to AWS. If you have FTP access, you can move the files into the folders with a tool like FileZilla or you can use a command line prompt on your local machine.

$ sudo scp -i "yourAWSpemKeyHere.pem" file/to/copy ubuntu@ec2-XXX-XXX-XXX-XXX.us-[your-region].compute.amazonaws.com:/etc/ssl/certs

Use your AWS Pem Key File and replace the file/to/copy with the .crt file you downloaded from GoDaddy that looks something like this a1234bc5d67e8f90.crt. It should be about 16 chars long and alphanumeric.

*If you are getting a permission denied error, you will need to temporarily change the folder permission settings on the server. Execute the following command on your ec2 instance to change the folder permissions.

$ sudo chmod 777 /etc/ssl/certs

Navigate to the certs directory and verify that the files you moved are there. Once in the directory, use the $ ls command to view all files in the directory, ensuring that you see the GoDaddy cert files you just moved. If you did change the permissions on the certs directory, you need to change those back after moving the files.

$ sudo chmod 755 /etc/ssl/certs

 

Step 6 – Configuring Apache to Use SSL

We have created our key and moved our certificate files under the /etc/ssl directory. Now we just need to modify our Apache configuration to take advantage of these. We will make a few adjustments to our configuration:

• We will create a configuration snippet to specify strong default SSL settings.

• We will modify the included SSL Apache Virtual Host file to point to our generated SSL certificates.

• (Recommended) We will modify the unencrypted Virtual Host file to automatically redirect requests to the encrypted Virtual Host.

When we are finished, we should have a secure SSL configuration.

Creating an Apache Configuration Snippet with Strong Encryption Settings

First, we will create an Apache configuration snippet to define some SSL settings. This will set Apache up with a strong SSL cipher suite and enable some advanced features that will help keep our server secure. The parameters we will set can be used by any Virtual Hosts enabling SSL. Create a new snippet in the /etc/apache2/conf-available directory. We will name the file ssl-params.conf to make its purpose clear:

$ sudo nano /etc/apache2/conf-available/ssl-params.conf

To set up Apache SSL securely, we will be using the recommendations by Remy van Elst on the Cipherli.st site. This site is designed to provide easy-to-consume encryption settings for popular software. For our purposes, we can copy the provided settings in their entirety. We will just make one small change. We will disable the Strict-Transport-Security header (HSTS). Preloading HSTS provides increased security, but can have far reaching consequences if accidentally enabled or enabled incorrectly. In this guide, we will not enable the settings, but you can modify that if you are sure you understand the implications. Before deciding, take a moment to read up on HTTP Strict Transport Security, or HSTS, and specifically about the “preload” functionality Paste the configuration into the ssl-params.conf file we opened:

SSLCipherSuite EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH
SSLProtocol All -SSLv2 -SSLv3 -TLSv1 -TLSv1.1
SSLHonorCipherOrder On
# Disable preloading HSTS for now.  You can use the commented out header line that includes
# the "preload" directive if you understand the implications.
# Header always set Strict-Transport-Security "max-age=63072000; includeSubDomains; preload"
Header always set X-Frame-Options DENY
Header always set X-Content-Type-Options nosniff
# Requires Apache >= 2.4
SSLCompression off
SSLUseStapling on
SSLStaplingCache "shmcb:logs/stapling-cache(150000)"
# Requires Apache >= 2.4.11
SSLSessionTickets Off

Save and close the file when you are finished.

Modifying the Default Apache SSL Virtual Host File

Next, let’s modify /etc/apache2/sites-available/default-ssl.conf, the default Apache SSL Virtual Host file.  You’ll need to edit both your config files related to http (:80) and https (:443) traffic. During installation those files may have different names so make sure you choose the correct files. If you are using a different server block file, substitute its name in the commands below. Before we go any further, let’s back up the original SSL Virtual Host file:

$ sudo cp /etc/apache2/sites-available/default-ssl.conf /etc/apache2/sites-available/default-ssl.conf.bak

Now, open the SSL Virtual Host file to make adjustments:

$ sudo nano /etc/apache2/sites-available/default-ssl.conf

Inside, with most of the comments removed, the Virtual Host file should look something like this by default:

<IfModule mod_ssl.c>
    <VirtualHost _default_:443>
        ServerAdmin webmaster@localhost

        DocumentRoot /var/www/html

        ErrorLog ${APACHE_LOG_DIR}/error.log
        CustomLog ${APACHE_LOG_DIR}/access.log combined

        SSLEngine on

        SSLCertificateFile      /etc/ssl/certs/ssl-cert-snakeoil.pem
        SSLCertificateKeyFile /etc/ssl/private/ssl-cert-snakeoil.key

        <FilesMatch "\.(cgi|shtml|phtml|php)$">
              SSLOptions +StdEnvVars
        </FilesMatch>
        <Directory /usr/lib/cgi-bin>
              SSLOptions +StdEnvVars
        </Directory>

    </VirtualHost>
</IfModule>

We will be making some minor adjustments to the file. We will set the normal things we’d want to adjust in a Virtual Host file (ServerAdmin email address, ServerName, etc., and adjust the SSL directives to point to our certificate and key files.

After making these changes, your server block should look similar to this:

<IfModule mod_ssl.c>
    <VirtualHost _default_:443>
        ServerAdmin your_email@yourdomain.com
        ServerName yourdomain.com

        DocumentRoot /var/www/html
        
        <Directory /var/www/html/> 
              AllowOverride All 
        </Directory>

        ErrorLog ${APACHE_LOG_DIR}/error.log
        CustomLog ${APACHE_LOG_DIR}/access.log combined

        SSLEngine on

        SSLCertificateFile /etc/ssl/certs/GoDaddy.crt
        SSLCertificateChainFile /etc/ssl/certs/gd_bundle-g2-g1.crt
        SSLCertificateKeyFile /etc/ssl/private/yourdomain.key

        <FilesMatch "\.(cgi|shtml|phtml|php)$">
              SSLOptions +StdEnvVars
        </FilesMatch>
        <Directory /usr/lib/cgi-bin>
              SSLOptions +StdEnvVars
        </Directory>

    </VirtualHost>
</IfModule>

Save and close the file when you are finished.

Step 6 – Enabling Changes in Apache

Now that we’ve made our changes  we can enable the SSL, re-write and headers modules in Apache, enable our SSL-ready Virtual Host, and restart Apache.

We can enable mod_ssl, the Apache SSL module, mod_rewrite, which allows us to redirect traffic from http to https, and mod_headers, needed by some of the settings in our SSL snippet, with the a2enmod command.

$ sudo a2enmod ssl
$ sudo a2enmod rewrite
$ sudo a2enmod headers

Next, we can enable our SSL Virtual Host with the a2ensite command:

$ sudo a2ensite default-ssl

We will also need to enable our ssl-params.conf file, to read in the values we set:

$ sudo a2enconf ssl-params

Modifying Apache to Allow URL Rewrites

Now, we need to modify the Apache virtual host file for WordPress to allow for .htaccess overrides. You can do this by editing the virtual host file.

By default, this is 000-default.conf, but your file might be different if you created another configuration file. Open this file to edit the settings.

sudo nano /etc/apache2/sites-available/000-default.conf

Inside of this file, we want to set up a few things. We should set the ServerName and create a directory section where we allow overrides. This should look something like this.

<VirtualHost *:80>
        ServerAdmin your_email@yourdomain.com
        ServerName yourdomain.com

        DocumentRoot /var/www/html

        <Directory /var/www/html/>
             AllowOverride All
        </Directory>

        .  .  .

When you are finished, save and close the file.

Now that Apache is configured to allow rewrites through .htaccess, we need to create an actual file. You need to place this file in your document root. If the file doesn’t already exist, we will create one.

$ sudo touch /var/www/html/.htaccess

This will be created with your username and user group. We need the web server to be the group owner though, so we need to adjust the ownership.

$ sudo chown :www-data /var/www/html/.htaccess

We now have the correct ownership of this file.

We may also need to adjust the permissions. This depends on how you prefer to work. WordPress will generate the necessary rewrite rules for you. If it has write permissions to this file, it can implement the rules automatically. If it does not, you will have to manually edit this file to add the correct rules.

Which configuration you choose depends on how much you value convenience over security. Allowing the web server write access to this file will definitely be more convenient, but some say that it is an unnecessary security risk.

If you want WordPress to automatically update this file with rewrite rules, you can ensure that it has the correct permissions to do so.

$ sudo chmod 664 /var/www/html/.htaccess

Now we’ll open the .htaccess file.

$ sudo nano /var/www/html/.htaccess

We will add the following code block to the bottom of the .htaccess file to redirect http traffic to https:

RewriteEngine On
RewriteCond %{SERVER_PORT} 80
RewriteRule ^(.*)$ https://yourdomain.com/$1 [R=301,L]

When you are finished, save and close the file.

Restart Apache to Enable Changes

At this point, our site and the necessary modules are enabled. We should check to make sure that there are no syntax errors in our files.

$ sudo apache2ctl configtest

If everything is successful, you will get a result that looks like this:

Output
AH00558: apache2: Could not reliably determine the server's fully qualified domain name, using 127.0.1.1. Set the 'ServerName' directive globally to suppress this message
Syntax OK

The first line is just a message telling you that the ServerName directive is not set globally. If you want to get rid of that message, you can set ServerName to your server’s domain name or IP address in /etc/apache2/apache2.conf. This is optional as the message will do no harm.

If your output has Syntax OK in it, your configuration file has no syntax errors. We can safely restart Apache to implement our changes.

$ sudo systemctl restart apache2

 

Step 7 – Activate SSL in WordPress

Now that the server settings are complete, return to the WordPress Admin Dashboard and refresh the page. The site should automatically adjust itself to https and the Really Simple SSL plugin warning message for no SSL detected should be gone. You can check your settings in WP Admin by going to Settings > General. Both website addresses should have https listed.

 

Hope this helped you get through your GoDaddy SSL Certificate install for a WordPress Website on an Apache (Ubuntu) server. If you still need help setting up your SSL, please contact our team for assistance.