This article convinced me of the benefit of SSL enabling everything. And Let's Encrypt made it seem so easy.

And it was easy for the URLs: two-drifters.co.uk and www.two-drifters.co.uk. Following the standard Let's Encrypt instructions to use Certbot and then following Certbot's instructions to install and run Certbot in certificate-only mode soon had the requisite certificates and it was simple to reroute HTTP requests on port 80 via a 301 return, to HTTPS on 443 which has the appropriate certificates set up.

server {
    listen 80;
    server_name two-drifters.co.uk www.two-drifters.co.uk;
    return 301 https://$host$request_uri;
}
server {
        listen 443 ssl;
        server_name two-drifters.co.uk www.two-drifters.co.uk;
        ssl_certificate /etc/letsencrypt/live/two-drifters.co.uk/fullchain.pem;
        ssl_certificate_key /etc/letsencrypt/live/two-drifters.co.uk/privkey.pem;
...
...

Problem was, every attempt to use Certbot to create certificates for the subdomains hosting Ghost blogs just failed. Node.js was not playing ball when it came to the validation to allow generating the certificates.

A chance find on this website lead me to installing the old pre-Cerbot software letsencrypt directly from Github and run letsencrypt-auto:
./letsencrypt-auto --agree-dev-preview --server https://acme-v01.api.letsencrypt.org/directory auth

This all worked OK but the secret was to stop nginx first and to select the authentication option of spinning up a temporary webserver (standalone) as opposed to placing the files in a webroot directory(webroot). But letsencrypt is back-level software so checking Certbot out by simply trying:

./certbot-auto certonly

I discovered the same option standalone is available in Certbot - sorted!

The resultant virtual-host files for the Ghost blogs are (currently) simply:

server {
    listen 80;
    server_name technicals.two-drifters.co.uk;
    return 301 https://$host$request_uri;
}

server {
    listen 443 ssl;
    server_name technicals.two-drifters.co.uk;
    ssl_certificate /etc/letsencrypt/live/technicals.two-drifters.co.uk/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/technicals.two-drifters.co.uk/privkey.pem;      
    location / {
        proxy_set_header   X-Real-IP $remote_addr;
        proxy_set_header  X-Forwarded-For    $proxy_add_x_forwarded_for;
        proxy_set_header  X-Forwarded-Proto  $scheme;
        proxy_set_header   Host      $http_host;
        proxy_pass         http://127.0.0.1:2369;
    }
}

Right - the basics are working! To keep them working I set up a cron job to run once a week to renew the certificates. Just sudo crontab -e and add the line:

30 2 * * 1 /home/pi/certbot-auto renew >> /var/log/certbot-renew.log && /etc/init.d/nginx reload

To get an A+ security rating from https://www.ssllabs.com then I needed to generate a 2048bit Diffie-Hellman key - simple enough: ``` sudo openssl dhparam -out /etc/ssl/certs/dhparam.pem 2048 ``` It does immediately generate the warning *This is going to take a long time* but it wasn't too long at all.

Now I have no real idea what I'm doing but various websites suggested the following was required (in addition to the existing ssl_certificate and ssl_certificate_key definitions)

ssl_protocols              TLSv1 TLSv1.1 TLSv1.2;
    ssl_prefer_server_ciphers  on;
    ssl_ciphers                "EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH";
    ssl_ecdh_curve             secp384r1;
    ssl_session_cache          shared:SSL:10m;
    ssl_stapling               on;
    ssl_stapling_verify        on;
    add_header                 Strict-Transport-Security max-age=63072000;
    ssl_dhparam                /etc/ssl/certs/dhparam.pem;

Duly added into the /etc/nginx/sites-available virtual host files and now the moment of truth - head over to https://www.ssllabs.com/ssltest and test the set-up.

Result

Result indeed!