Part 4 - Deploying a simple, modern web app with monitoring and analytics without Docker or containers for beginners
September 18, 2019
This post is part of a tutorial for deploying a basic website with monitoring and analytics without using Docker or containers. The introductory post gives an overview of the tutorial.
In the previous post, we configured Nginx and deployed our website. We’re now live! However, it’s a good idea to add support for accessing our website via
HTTPS. In this post, we’ll configure an SSL certificate for our website and setup automatic renewal of the certificate using
Certbot and Let’s Encrypt. After that, we’ll adjust some more settings in our general Nginx configuration to make things a bit more secure. At the end we’ll submit our website to an SSL test at SSL Labs and see how it performs.
Using Let’s Encrypt and Certbot
We will need to add the Ubuntu software repository for
sudo add-apt-repository ppa:certbot/certbot
After that, we can install it:
sudo apt install python-certbot-nginx
More details about install can be found on the certbot site;
Certbot uses the
server_name in all the loaded
server blocks in your Nginx configuration files to find the domain you’ve specified when generating a certificate. This is because
Certbot will actually automatically insert the necessary lines into our
server block once it finds our domain. To create a certificate for our website:
sudo certbot --nginx -d yourdomain
The domain you use must match the
server_name you put in the Nginx
conf file we created earlier. When running
certbot it might prompt you to enter an email address and agree to Terms of Service. Adding your email address can be handy as it enables
certbot to send you emails when your certificate is coming up for renewal. More information can be found on the Let’s Encrypt Expiration Emails page.
Finally, you should see
certbot ask you if you want to redirect
HTTP traffic to
HTTPS. We want this feature, so option number 2 can be selected.
certbot will go ahead and add the necessary configuration lines to our Nginx
conf file for our website.
certbot will now show you information about where your certificate and chain exist on our Droplet as well as their expiry date. Our certificate should be loaded in our website configuration so go ahead and hit your website from your local machine again, this time using
https://. You should see the same website as before, this time with
https! Additionally, you can try hitting your site with
http and verify you are redirected to
If you open up your Nginx
conf file you’ll see several lines have been added regarding our choices to redirect
ssl_certificate entries, a listen directive for port 443 among other entries.
You’ll also notice a line
include /etc/letsencrypt/options-ssl-nginx.conf. We’ll take a look at that in just a moment.
Testing out certificate renewal
It’s very important our certificate not expire and
certbot has configured automatic renewal for us. We can test renewal out with the following command:
sudo certbot renew --dry-run
This will run the process for renewing a certificate, but not actually renew our current production certificate. If any failures happen during the renewal process they will be listed in the output of this command.
If want to see more information about the automated renewal you can run a command to print out info about it:
sudo systemctl status certbot.timer
Will show details about the
sudo systemctl list-timers
Will show information about scheduled services. You should see
certbot.timer listed under the
UNIT column on the far right of the printed output.
Analyzing our setup via SSL Labs
SSL Labs is a useful site for getting an over-arching grade on the security of your site. Here, you can enter your site url (e.g., https://yourdomain) and it will give you a grade. Running your domain against our site now should produce a
A. There are a few small tweaks we can make to our Nginx configuration to get that up to an
First, in our Droplet terminal open up the file
/etc/letsencrypt/options-ssl-nginx.conf that I mentioned earlier. You should see the following line around line 10:
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
TLSv1 section means our Nginx config supports
TLSv1. If you take a look at your SSL Labs report you can see several of the yellow-orange lines are due to supporting TLSv1. Let’s remove that setting. So this line should like this now:
ssl_protocols TLSv1.1 TLSv1.2;
Next, we’re going to add a line right below the
ssl_prefer_server_ciphers line. Add the following line:
add_header Strict-Transport-Security "max-age=63072000; includeSubDomains; preload" always;
This enables HSTS which, according to the MDN docs “lets a web site tell browsers that it should only be accessed using HTTPS, instead of using HTTP.” More info can be found in the link.
Now that we’ve adjusted these two settings, save this file.
Test your Nginx configuration to ensure there are not any errors:
sudo nginx -t
sudo systemctl nginx restart
Once reloaded, go back to your SSL Labs report. Scroll to the top of the page and click the
Clear cache link. This will cause SSL Labs to restart testing your site fresh. Otherwise it’ll return the previous results since we just had our site analyzed a moment ago.
After it’s done testing, you should see an
A+. Notice the
TLSv1 warnings are gone and
TLSv1 is now marked
No in the
Protocols section of the report. Also, near the bottom you can see that
Strict Transport Security (HSTS) is green and marked as enabled. Hooray!
There is definitely more you can do regarding securing your site configuration, which I’ll touch on at the end of this tutorial.
Our site is now accessible via
HTTPS and our SSL certificate is automatically renewed for us!
Next, we’ll see how we can access and view server logs for our site on our Droplet using
GoAccess in Part 5.
Thanks for reading so far and hope you’re enjoying the tutorial!
Written by Jordan Polaniec, who loves software. You can follow him on Twitter