An older Nginx and Certbot certificate setup

Certificate automation starts with an intentional hostname and an HTTP virtual host. The original Ubuntu setup installed Nginx, configured its default server, and added a site before invoking Certbot.

Historical installation. Package repositories, plugin names, paths, and certificate behavior belong to the earlier host. These commands have not been run for this revision.

Prepare the HTTP host

sudo apt install nginx

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

    root /var/www/html;
    index index.html index.htm index.nginx-debian.html;

    server_name _;

    location / {
        # First attempt to serve request as file, then
        # as directory, then fall back to displaying a 404.
        try_files $uri $uri/ =404;
    }
}

The site-specific example was:

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

    root /var/www/example.com;
    index index.html index.htm;

    server_name nhancv.com www.nhancv.com;

    location / {
        try_files $uri $uri/ /index.html?$query_string;
    }
}

Its enable/reload sequence was:

sudo ln -s /etc/nginx/sites-available/nhancv.com /etc/nginx/sites-enabled/

sudo service nginx reload

The recorded certificate commands

sudo apt update
sudo apt install software-properties-common
sudo add-apt-repository universe
sudo add-apt-repository ppa:certbot/certbot
sudo apt update

sudo apt install certbot python-certbot-nginx
sudo certbot --nginx

Review domain selection and configuration changes at each prompt. The original advice to answer yes indiscriminately is not retained. The current Certbot instructions are the reference for selecting an installation method appropriate to the actual host.

A certificate file alone does not prove that the intended public hostname is serving it, or that renewals and redirects work.

← Back to the garden