Configure Nginx and HTTPS

Right now Nginx answers every request with its default welcome page. We’ll give it a site of its own for notes.example.com, prove it works over plain HTTP, and only then add HTTPS. Doing it in this order means every failure has one possible cause.

A tiny site to test with

Create a document root with one HTML file, then open a new site configuration:

sudo install -d -m 755 /var/www/notes
echo '<h1>Notes server</h1>' | sudo tee /var/www/notes/index.html
sudoedit /etc/nginx/sites-available/notes

Paste this server block, the Nginx unit that describes one website, with your own hostname:

server {
  listen 80;
  listen [::]:80;

  server_name notes.example.com;
  root /var/www/notes;
  index index.html;

  location / {
    try_files $uri $uri/ =404;
  }
}

server_name is how Nginx decides which block handles a request: it matches the Host header the browser sends. root says where the files live. try_files looks for the requested file, then a directory, and returns 404 otherwise.

Enable, validate, reload

Nginx only loads sites linked into sites-enabled. Link yours, test the whole configuration, reload, and make a request:

sudo ln -s /etc/nginx/sites-available/notes /etc/nginx/sites-enabled/notes
sudo nginx -t
sudo systemctl reload nginx
curl -I http://notes.example.com

nginx -t must say test is successful before you reload. Never skip it. A reload with a broken config leaves Nginx running the old one, and you won’t notice until the next restart fails.

The curl should return 200 OK, and curl http://notes.example.com should print <h1>Notes server</h1>. Getting the default welcome page instead means the request landed in the wrong block: check server_name, the symlink in sites-enabled, and the hostname you’re requesting.

Add HTTPS

Install Certbot following the official instructions linked in this lesson’s sources. Certbot talks to Let’s Encrypt, gets a certificate, and edits your server block to use it. One command does it all:

sudo certbot --nginx -d notes.example.com

Issuance works only if the hostname resolves publicly to this Droplet and port 80 is reachable, because Let’s Encrypt connects to your server to verify you control the name. Wrong DNS, closed port 80 or a proxy in the middle all make it fail. Fix that layer. Retrying won’t change the answer.

Then verify from your laptop and check the renewal path:

curl -I https://notes.example.com
sudo certbot renew --dry-run
systemctl list-timers | grep -i certbot

The HTTPS request returns 200 OK with no certificate warning. The dry run ends with Congratulations, all simulated renewals succeeded. The timer line shows Certbot will renew on its own. The dry run matters more than today’s certificate: certificates last 90 days, and you want to know now that renewal works.

When a change breaks the config

If nginx -t fails, don’t reload. Fix the file or remove the symlink in sites-enabled, run nginx -t again, and reload only a valid configuration. I keep a copy of the last working server block before I edit it.

Save the passing nginx -t, the HTTPS response, the certificate hostname and expiry, and the dry-run result in your notes. The Nginx course goes deeper on server blocks and TLS settings if you want more.