By the end of this tutorial your WordPress – site/blog will have an SLL certificate, so that it can be served over the secure HTTPS protocol.
For which stack does this tutorial apply?
- WordPress site/blog
- Hosted on AWS (Amazon Web Services) EC2 instance
- Bitnami stack (Ubuntu Linux + Bitnami specific software)
NOTE: The Bitnami WordPress setup (which I also use myself), is an “out-of-the-box” package, available on the AWS marketplace.
What this preconfigured stack doesn’t provide from the get go, is an SLL certificate. So your site will be http only in the beginning and cannot be served via HTTPS. For some blogs that’s probably fine. But users will certainly feel much more comfortable when their browser isn’t shouting at them, for accessing an unsecure site.
This tutorial will mostly follow the Bitnami-tutorial, extended by some explanations or “gotchas” I encountered myself.
Let’s get ourself a certificate!
We will use SSH (secure shell) to connect to our server (EC2 instance). If you don’t know anything about “how to connect to a remote server”, you might want to look at the slightly less alianated/scary way (through an FTP-client) first. I already wrote a tutorial on “Access Your WordPress EC2 Instance via SFTP”, if your interested.
First we need to connect to our server via SSH (If your on Mac, SSH is already available in your terminal/command line). You will need a keyFile to successfully connect to your server. It ends on .pem (e.g. myKeyPair.pem). You should have gotten that keyFile when you first launched your WordPress instance on AWS.
NOTE: If you don’t know where you put your keyPair-file that’s very unfortunate. You might not get SSH access to that EC2 instance anymore. A work around is, to copy your instance as an AMI (Amazon Machine Image). Initialize a new EC2 instance, using that image. Disable the old instance. Here is a discussion on how to do that.
1. Activate Inbound Traffic for SSH
We need to make sure that SSH is enabled for inbound traffic, on our WordPress instance:
- Log in to your AWS dashboard
- Navigate to: Services > EC2 > running instances
- Click on your running WordPress instance
You should see the main Menu of your instance now. Somewhere at the bottom you also see which keyPair is associated with your site.
Check or activate SSH traffic. You can find the corresponding settings under:
NETWORK & SECURITY > Security Groups….
…click on the Inbound-tab.
SSH should be activated with a Port Range of 22.
And as Source it should show your IP-Adress.
NOTE: If SSH is not there yet, you can add SSH by clicking on Edit -> Add Rule -> and choose SSH from the dropdown. The port defaults to 22 automatically.
For the Source you could use anywhere (0.0.0.0/0). But this means every computer that has your KeyPair could access your server/instance remotely. This is not ideal. BETTER: choose My IP (some-ip-address). You don’t have to know your IP address. It gets filled out automatically. Now only your computer has access to the instance.
FANTASTIC! That was already quite essential.
2. Access your Instance through the Secure Shell
Open a terminal window.
Navigate to the place where your KeyPair-file resides.
It needs a certain set of permissions. Therefore run the following command:
This command defines that the file can be read and being written to, only by the owner of the file (e.g. root-user).
Now connect to your server by executing the following ssh command in your terminal:
Your SSH client will most likely ask you to confirm the server’s host key and add it to the cache before connecting. Accept this request by typing “Yes”.
You should be logged in to your server and see something like this in the terminal:
NOTE: If this doesn’t work, try resetting your “MyIp-Adress” in your SSH inbound traffic settings in the AWS dashboard (as described above). This has thrown me a couple of times, because it seems I have a dynamic IP-address. And if it has changed, the server thinks someone else is trying to connect and will deny the access.
3. Get your SSL Certificate
We assume you are logged in to your server now, via your terminal.
If your site/blog is based on the Bitnami-stack you should be on an Ubuntu Linux distribution. But if you like, you can double check that by typing:
This shows some details about your operating system.
Bitnami uses a tool called Lego to automate some of the SSL-certificate juggling. The program might be already installed under /opt/bitnami/letsencrypt/. In my case it wasn’t. You can find out whether it is by typing:
sudo ls /opt/bitnami/letsencrypt
If you see lego listed you’re golden and you can jump forward to #4. If not – you guessed it – install Lego first.
>> Installing Lego
Change into the temp folder of your server by typing:
Download Lego with this command:
curl -Ls https://api.github.com/repos/xenolf/lego/releases/latest | grep browser_download_url | grep linux_amd64 | cut -d '"' -f 4 | wget -i -
This will download the latest Lego-version from the repository. Type ls (you should still be in the /tmp directory) to see the exact name (version) of the file you downloaded.
Unpack the tar file with the following command:
Create a directory for where lego will be put in:
sudo mkdir -p /opt/bitnami/letsencrypt
Move the unpacked lego binary into the just created folder by typing:
sudo mv lego /opt/bitnami/letsencrypt/lego
If you like, check whether lego gets listed now:
sudo ls /opt/bitnami/letsencrypt
The next thing sounds scary. But we are going to shut down the server.
BITNAMI-NOTE: Before proceeding with this step, ensure that your domain name points to the public IP address of the Bitnami application host.
To shut down all Bitnami services run the following command:
sudo /opt/bitnami/ctlscript.sh stop
Now FINALLY get your certificate!!! You do so by running the following command. But for EMAIL-ADDRESS you enter your email-address and for DOMAIN you enter your domain (e.g. www.myblog.com).
sudo lego --tls --email="EMAIL-ADDRESS" --domains="DOMAIN.com" --domains="www.DOMAIN.com" --path="/opt/bitnami/letsencrypt" run
NOTE: With the –domains flag you can specify several domains in one go as you can see in the example command above (–domains=”myblog.com” AND –domains=”www.myblog.com”).
You will have to agree to the terms of service.
After that, certificates will be generated in the /etc/lego/certificates directory. This set includes the server certificate file DOMAIN.crt and the server certificate key file DOMAIN.key.
To really see how they’re named, check for the files by running the following command:
sudo ls /opt/bitnami/letsencrypt/certificates
4. Configure your Server
Figure out what server is used on your instance by running:
sudo /opt/bitnami/ctlscript.sh status
sudo mv /opt/bitnami/apache2/conf/server.crt /opt/bitnami/apache2/conf/server.crt.old sudo mv /opt/bitnami/apache2/conf/server.key /opt/bitnami/apache2/conf/server.key.old sudo mv /opt/bitnami/apache2/conf/server.csr /opt/bitnami/apache2/conf/server.csr.old
The next two commands will create symbolic links to your new SSL certificates. Make sure that for DOMAIN you enter your domain-name with the top-level domain part. So that the key for example becomes myblog.com.key.
sudo ln -sf /opt/bitnami/letsencrypt/certificates/DOMAIN.key /opt/bitnami/apache2/conf/server.key sudo ln -sf /opt/bitnami/letsencrypt/certificates/DOMAIN.crt /opt/bitnami/apache2/conf/server.crt
And the last two of those seven commands change the owner of the certificate-files. Which is the root user. And we modify the rights. So that only the root user can read from or write to those files.
sudo chown root:root /opt/bitnami/apache2/conf/server* sudo chmod 600 /opt/bitnami/apache2/conf/server*
If your server turned out to be Nginx, the principle is the same. But the commands from above will look like this:
sudo mv /opt/bitnami/nginx/conf/server.crt /opt/bitnami/nginx/conf/server.crt.old sudo mv /opt/bitnami/nginx/conf/server.key /opt/bitnami/nginx/conf/server.key.old sudo mv /opt/bitnami/nginx/conf/server.csr /opt/bitnami/nginx/conf/server.csr.old sudo ln -sf /etc/lego/certificates/DOMAIN.key /opt/bitnami/nginx/conf/server.key sudo ln -sf /etc/lego/certificates/DOMAIN.crt /opt/bitnami/nginx/conf/server.crt sudo chown root:root /opt/bitnami/nginx/conf/server* sudo chmod 600 /opt/bitnami/nginx/conf/server*
DONE! Restart your Engine
Here is the very last command which will restart the Bitnami services (server, database, etc.), with your new SSL certificates in place:
sudo /opt/bitnami/ctlscript.sh start
Your WordPress Site should now be servable via HTTPS. Try it out by going to your browser and enter your domain. Don’t forget to put https:// in front of your domain (e.g. https://www.myblog.com).
That was really quite an effort, but you made it. CONGRATULATIONS!!!
There is one last thing you should know. Your certificates do not last forever. To be more specific. They expire after 90 days…
NOTE: If you would like to check when your certificate expires, you can run the following OpenSSL command (while you’re on your server):
This will spit out a lot of data, including the validity period:
sudo openssl x509 -text -noout -in server.crt
Not Before: Apr 19 08:38:40 2019 GMT
Not After : Jul 18 08:38:40 2019 GMT
This will spit out a lot of data, including the validity period:
There is a way to renew them of course. And even a way to do this automatically by setting up a cron-job. Since I don’t have a tutorial on that topic, I point you to the original Bitnami tutorial (renewal starts at #5).
NOTE: If you want to redirect your HTTP version of your site/blog (without SSL) to your HTTPS version now: Follow the instructions on the Bitnami docs.
That’s it for today. I really hope that by reading this you had less trouble setting up SLL/HTTPS for your WordPress site than I did.
If you liked this post or if you would like to comment on it, please feel free to share it on social media or send me an email.