Nginx SSL configuration: Automate Let's Encrypt with Certbot

Last month, I spent an entire Saturday morning manually fixing an expired SSL certificate on a legacy production box. It was a tedious reminder that manual certificate management is a ticking time bomb. If you're running a web server, you need a robust way to handle encryption that doesn't rely on your memory.

By combining Nginx with Certbot, you can implement a set-it-and-forget-it system for SSL termination. Here is how I set up my servers to stay secure without the manual overhead.

Initializing your Nginx SSL configuration

Before touching certificates, your Nginx site block needs to be ready to handle standard HTTP traffic. I usually start with a clean configuration that listens on port 80.

NGINX
server {
    listen 80;
    server_name example.com www.example.com;

    location / {
        root /var/www/html;
        index index.html;
    }
}

Once this is running, you're ready to request a certificate. If you are also setting up a backend, make sure you've already handled your Nginx Reverse Proxy Configuration: Optimizing Header Forwarding to ensure headers like X-Forwarded-Proto are passed correctly once you switch to HTTPS.

Running the Certbot Nginx setup

The certbot tool is the industry standard for automated certificate management. On an Ubuntu system, I typically install it via snap to ensure I'm getting the latest version:

Bash
sudo snap install --classic certbot
sudo ln -s /snap/bin/certbot /usr/bin/certbot

Once installed, run the Nginx plugin. This command automatically modifies your Nginx configuration files to point to the new certificates and sets up the challenge-response flow:

Bash
sudo certbot --nginx -d example.com -d www.example.com

Certbot will ask if you want to redirect HTTP traffic to HTTPS. I always select "Yes." This creates a permanent 301 redirect, ensuring your users never hit the insecure version of your site.

Automating SSL renewal

The beauty of this setup is that the renewal process is already handled for you. When you run the command above, Certbot creates a systemd timer that checks for certificate expiration twice a day.

You can verify that the auto-renewal is active by running:

Bash
sudo certbot renew --dry-run

If this command returns "Congratulations, all simulated renewals succeeded," you’re golden. You won't have to worry about expiring certificates for the next 90 days—or ever again.

Why this approach works

Hardening your server

Once you’ve successfully implemented your Nginx SSL configuration, don't stop there. Security is layered. After securing the transport layer, I recommend reviewing your application headers. If you're building a modern web app, check out Advanced Security Header Configuration: CSP and Secure Cookies in Laravel to ensure your browser-side security is just as tight as your server-side encryption.

FAQ

Does Certbot interfere with my existing Nginx configuration? It tries to be smart about it. It creates a new server block for port 443 and adds the necessary SSL directives. However, if your config is highly custom or uses complex includes, it’s always safer to back up your /etc/nginx/sites-available/ directory before running the tool.

What happens if the renewal fails? Certbot will log the error to /var/log/letsencrypt/letsencrypt.log. If a renewal fails, you usually have about 30 days of "grace period" before the certificate actually expires, which gives you plenty of time to debug the issue.

Can I use this for wildcard certificates? Yes, but you’ll need to use the dns-01 challenge instead of the --nginx plugin. That requires a bit more legwork involving DNS API keys, so I usually stick to standard domain certificates unless I have a specific reason to use wildcards.

Next time, I’d like to explore how to integrate these certificates with a containerized environment. For now, this approach has saved me roughly five hours of manual work per year per server. It’s a small investment that pays off every time a certificate hits that 60-day mark.