Because this website is a Ghost publication hosted on a DigitalOcean droplet, I've had to spend quite some time over the last few days learning about SSL-certificates and how to actually install them on my web server manually. Here is what I learned.

Step 1: Know what an SSL is and how it works

An SSL certificate allows you to create a secure connection between the client and the server: so between you reading this page through your browser, and me providing you this page through my server. It encrypts the communication between us so that we can use the secure https protocol to communicate. The browser indicates this by the little green padlock icon next to the domain name.

The SSL certificate itself is a digital certificate issued by a third party that verifies the identity of the web server and its public key.

The way it works is pretty simple.

Your browser approaches my server, requesting a secure connection. My server sends you the public key with its SSL certificate, which is digitally signed by the third party certificate authority (CA). The browser checks with the CA to see if its digital signature is valid. Once the signature is verified, your browser now trusts the connection with and displays the padlock icon. From this moment on, we will have a secure connection and all the traffic between us will be encrypted.

Step 2: generate a CSR

The CA (certificate authority) that will end up issuing you the certificate will ask you to demonstrate that you have control over the web server that is going to host your SSL certificate. It does this by requesting a so-called CSR: certificate signing request. You generate this CSR on your server.

First, open the terminal and login on your website's ip address through ssh. In my case that looks like this:

ssh root@

After you login, you can generate a new key by using the following command:

openssl req -new -newkey rsa:2048 -nodes -keyout -out

Obviously, you need to replace with your own domain name here. The key generation process will request a couple of inputs:

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

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

Most of these are self-explanatory, but be sure to use your root domain name where it asks for your Common Name.

The output will be something like this:


Step 3: buy an SSL and verify ownership

Seeing that you need a third party to validate your website, you usually need to buy an SSL. There are free options out there, such as Let's Encrypt, but even the paid ones are not very expensive. I paid $8 for mine through NameCheap, where my domain name and DNS are hosted.

You give the CSR you generated in the previous step to the CA when prompted and they will proceed to send an email to the official owner of the domain, through the email address that is listed in the whois information.

If you are the owner, you will get an email in your inbox asking you to confirm the request for an SSL certificate by clicking a link and submitting the validation code. This confirms your ownership of the domain and the CA will proceed to send you your SSL certificate in another email.

Step 4: combine your certificates and upload to your web server

Now that you have your certificates, they need to actually be hosted on your web server. In the case of a ghost publication such as, the web server is NginX (say: engine-X), which requires for its setup that all the certificates are in one file.

You can simply do this by opening a text editor and copy pasting the certificates in that one file, making sure that the domain certificate is listed first.

After you've done that, you need to get that file from your local machine to the server. And in my case, this actually proved to be easier said than done. Because the only modes of transporting files to a server that I had any experience with are FTP through FileZilla; or deploying entire projects using git.

FTP was out of the question, however, because DigitalOcean considers that protocol insecure and therefore won't support it. The same goes for command line interfacing such as scp or rsync, apparently, because I couldn't get those to work either.

But I was not about to set up a whole git project and configure my droplet as a remote repository just to get a simple text file from my local machine to my server. So I decided to simply create a new file on the webserver using the command line like this:

 echo ‘thIs1swh3r3Ip0stedMYcertific@tes’ >cornevanstraten_com.crt 

Quick and dirty solution, but it worked.

Step 5: configure NginX to serve the SSL

The final and arguably most intimidating step for me was configuring my NginX web server to actually serve the SSL certificate. Luckily, there is a HowTo by DigitalOcean that explains this process for different web servers, among which NginX. So I could follow those instructions pretty closely, except that the configuration file I needed to edit was actually called, not default.

You find the configuration file by going to the following directory:

cd /etc/nginx/sites-enabled

Now this was the first time for me to actually edit any file directly on the server, not having access to any text editor. So I also had to learn how to use the vi text editor that works in the command line. I learned the basic vi commands from this site and went on to edit the file in the command line interface using:

sudo vi 

I followed the instructions to the letter, but when I restarted the web server, NginX threw an error.

SSL: error:02001002:system library:fopen:No such file

NginX couldn't find my certification file, despite the path to the certificate in the root directory being absolutely correct.

After some looking around on ServerFault, I found someone suggesting that the problem might be that NginX user doesn't have permission to access the root directory, so I ended up creating an SSL directory in the nginx folder with mkdir ssl and moving the certificate from root to there:

mv cornevanstraten_com.crt /etc/nginx/ssl

Then, I went back to the configuration file and edited it to look like this:

server {
    listen 443 ssl http2;
    listen [::]:443 ssl http2;

    root /var/www/ghost/system/nginx-root;

    ssl_certificate /etc/nginx/ssl/cornevanstraten_com.crt;
    ssl_certificate_key /etc/nginx/ssl/;
    include /etc/nginx/snippets/ssl-params.conf;

    location / {
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header Host $http_host;


    location ~ /.well-known {
        allow all;

    client_max_body_size 50m;

I tried the NginX restart again with

sudo service nginx restart

I don't get an error message this time, so I open my browser to go to and.... the glorious padlock icon appears!!


The end to a seemingly endless period of frustration.

So I hope that you, reader, thoroughly enjoy the secure connection through which this blog is coming to you. Hopefully it will make you feel safe to come back once more.

Until then!