Part 4 - Deploying a simple, modern web app with monitoring and analytics without Docker or containers for beginners
Tags: webdev, nginx, certbot
Published: 2019-10-10 21:00:08

---
title: Part 4 - Deploying a simple, modern web app with monitoring and analytics without Docker or containers for beginners
published: true
description: 
tags: webdev,nginx,certbot
series: Deploying a simple web app with monitoring and analytics without Containers for beginners
---


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](https://www.ssllabs.com/ssltest/index.html) and see how it performs.

### Using Let's Encrypt and Certbot
We will need to add the Ubuntu software repository for `Certbot`.

`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](https://certbot.eff.org/lets-encrypt/ubuntuxenial-nginx.html);

`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](https://letsencrypt.org/docs/expiration-emails/).

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.

Upon success, `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 `https`.

If you open up your Nginx `conf` file you'll see several lines have been added regarding our choices to redirect `http` to `https`, our `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 `certbot.timer` service.

`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](https://www.ssllabs.com/ssltest/) 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 `A+`.

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;`

The `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](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Strict-Transport-Security) 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`

Reload Nginx:

`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 `Configuration` -> `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!