Get HTTPS for your WordPressSite Title image

Get HTTPS (SSL) for your WordPress Site

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.

aws EC2 instance overview

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 ( 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:

command: read/write permissions (for owner)

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:

ssh command to connect to remote server

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:

Bitnami server login-welcome page (photo from:

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:

cat /etc/os-release

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:

cd /tmp

Download Lego with this command:

curl -Ls | 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:

command to unpack lego tar file

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/ 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.

sudo lego --tls --email="EMAIL-ADDRESS" --domains="" --domains="" --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=”” AND –domains=””).

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/ status

If it is Apache the following lines will apply (Nginx below). Those first three commands rename the old server certificate files by adding .old onto the end.

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

sudo ln -sf /etc/lego/certificates/DOMAIN.key /opt/bitnami/apache2/conf/server.key
sudo ln -sf /etc/lego/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/ 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.

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): sudo openssl x509 -text -noout -in server.crt

This will spit out a lot of data, including the validity period: Certificate:
Not Before: Apr 19 08:38:40 2019 GMT
Not After : Jul 18 08:38:40 2019 GMT

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.



Help! How do I add a PATH?!…

(on MacOS)

If you’re here you probably have this issue:
You just downloaded this new program. But when you try to use it:
“Error: program “new_shiny_program” not found in PATH”…

One thing I wish I knew when I first started to code is:

“how the heck do I add this “PATH”?!

Let me start by briefly talk about the command line. If you know what it is, and how it’s basics work, feel free to skip ahead.

The command line, also called CLI (command line interface), terminal or shell is basicly a program where you can interact with your computer. You can:

  • change into different directories/folders
  • create files
  • download and install stuff
  • write scripts to automate tasks
  • a lot more…

Why do we even need the command line?

  • Sometime it’s just faster to simply type a little command into the command line, instead of opening an entire program.
  • Other programs do’t even have a GUI (graphical user interface) like a Microsoft’s word.

The latter are called “command line tools”. And if you’re starting out: it is most likely, that one of your first programs can only be run through the command line.

A little Example: Let’s say you have Python installed on your machine and you wrote a little Python-program that prints “hello, world!”. You will need to open the command line. (It shows a promt, probably showing two right angel brackets (>>). And behing them you can type:
And “magically” the text “hello, world!” appears below (also in the command line).

How does that work?

I won’t tell you what happens on the OS (operating system) level. But is really useful to know, that the command line (which is a program in itself) is running other programs for your (the the python interpreter in the example above).
Also when you type “ls” (to see what files and folders are in your current folder) the command line actually executes a program called ls.

How does the command line know what to do?
Let’s get a bit more specific. One of the available command lines (also most likely the one that opens when you open terminal on your mac) is called bash. And bash will look into a couple of directories on your computer to see, which programs are available for it to run.
But those folders are hidden folders. They can be seen though by adding the -a flag to the ls command (ls -a). Or if you’re in the Finder you can use this nifty shortcut cmd + shift + .  (<- the third key is a dot)  to make the hidden folders visible/invisible.

Where are those folders?

On your mac you will find them in your root directory:
In my case: Harddrive/some_hidden_folder
You can find folders like:

  • bin
  • usr/bin
  • usr/local/bin

Inside those folders are the programs your command line can use. Why? because those folders are specified in the PATH variable of your bash command line program.

How to actually add a PATH

Your are here because some program could not be run. And it complained that the “path is missing” and you should add it. Let’s do it than.
We need to know where the program is located, so we can that specific path that lead to the binary (program), to the command line environment variable PATH.
Just imagine we would have installed some_program into Users/your_user_name/programs/cool_program
So the program is not in one of the usr, usr/bin, something hidden directories. Therefore our command line cannot find it.
Here comes the rescue:
Type into your your command line PATH=”Users/your_user_name/programs/cool_program”:$PATH

Little aside, incase you don’t understand the slightly cryptic command.

The command line also has a syntax. You can even write entire scripts, with loops, conditions, variables and everything. (If you like to learn a bit more about that, I highly recommend the codecademy learn the command line tutorial.)
Here, the variable is calles PATH. We set it to a new value with the equal character (=). No spaces are allowed. The value (our path) is surrounded by quotes (” “). And at the end we add the old PATH to it, using the colon (:). The old path’s value is accessed by putting the dollar-sign in front of it’s variable name ($PATH).

This adds the path (including the folder cool_program where some_program resides) to the PATH variable. To be more specific: the path get’s added to the front of the already existing PATH. We could add it to the end with:
Your program should be found by the command line now and you can use it.

BUT! This only works temporarily. More specific, for as long as you keep the current command line window open. Once you close it, the recently added path is gone again. Sorry.

How to add a PATH permanently?

There are user specific folders like:

  • Harddrive/your_user_name/.bash_profile
  • Harddrive/your_user_name/.bashrc
  • Harddrive/your_user_name/.profile

Those hidden files are essentially text files. You can double click on them to open them (if made visible with cmd + shift + . ). You will find some very familiar looking lines of text, or more concrete instructions.
Your bash-command-line looks into the above mentioned folders, because of these files.
The files might contain something like this.

bash environment setting

The lines prefixed with the hashtag (#) are just comments. Below you can see export and a path declaration (like the one we discussed earlier). Export is a built-in-command of your bash-command-line. It simply puts the declared variable (here it is a PATH) into your command line environment, ready for you or the bash-command-line to use it.

Et voilà! You have added a PATH to your command line environment. I hope this was helpful for you and that you can understand the command line a little better now. If you would like to know more about the command line you might wanna have a look at the learn UNIX tutorial by tutorialspoint.

If you liked this post or if you have some comments, please feel free to send me an email. Or share and comment it on twitter.

Thanks for stopping by