Certbot with Nginx: Let’s Encrypt Install and Renewal Guide

admin

2 hours ago

Certbot Nginx Let's Encrypt tutorial showing certificate issuance renewal timer and HTTPS verification

Certbot is the practical path for Let’s Encrypt certificates on self-managed Nginx servers. It can request the certificate, install it into Nginx, and set up renewal so the site does not fall over because a certificate quietly expired.

This guide is for VPS, dedicated, agency, SaaS, and homelab servers where you control Nginx. If the site is inside cPanel, Plesk, Cloudways, a managed WordPress host, or another panel that already manages AutoSSL, use the panel’s certificate system unless you have a specific reason to run Certbot outside it.

Before you begin

DNS must point the hostname to this server.
Port 80 must be reachable from the public Internet for the normal HTTP validation path.
Nginx must already serve the domain or be ready to serve it.
You need root or sudo access.
Back up the Nginx site config before letting any tool edit it.

sudo nginx -t
sudo cp -a /etc/nginx /root/nginx-before-certbot-$(date +%F)

Install Certbot

The Certbot project recommends following the official instructions for your OS and web server. For many Linux systems, the current standard path is the snap package:

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

If Certbot was already installed from apt, dnf, or yum, check the official instructions before mixing package sources. Two different Certbot installations can make troubleshooting renewals harder than it needs to be.

Option A: Let Certbot update Nginx

Use this when you are comfortable with Certbot editing the Nginx server block and you already have a clean config.

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

After the certificate is issued, test and reload Nginx if needed:

sudo nginx -t
sudo systemctl reload nginx

Option B: Get the certificate only

Use certonly when you want to edit Nginx by hand, keep a strict template system, or avoid automated changes on a production reverse proxy.

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

Then reference the certificate paths in your TLS server block:

ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

Renewal test

Certbot normally installs a cron job or systemd timer. Do not assume renewal works. Test it right after setup:

sudo certbot renew --dry-run
systemctl list-timers | grep -i certbot || true

If renewal succeeds but Nginx keeps serving the old certificate, add or verify a deploy hook that reloads Nginx after a renewed certificate is saved.

sudo mkdir -p /etc/letsencrypt/renewal-hooks/deploy
sudo tee /etc/letsencrypt/renewal-hooks/deploy/reload-nginx.sh >/dev/null <<'EOF'
#!/bin/sh
nginx -t && systemctl reload nginx
EOF
sudo chmod 755 /etc/letsencrypt/renewal-hooks/deploy/reload-nginx.sh

Wildcard certificates

Wildcard certificates require DNS validation. That means you need a supported DNS plugin or a deliberate manual process. For business sites, use a DNS plugin with tightly scoped API credentials when possible, store that credential file with restrictive permissions, and document who can rotate it.

Hosting-panel warning

cPanel AutoSSL, Plesk Let’s Encrypt, and managed hosting certificate tools can overwrite or compete with manual Certbot work. If the panel owns the Nginx or Apache vhost, stay inside the panel workflow. If you are building a separate Nginx reverse proxy in front of the panel, document which layer terminates TLS and where renewal happens.

Verification checklist

Visit the HTTPS URL in a browser and check the certificate subject and expiration date.
Run curl -I https://example.com/ and confirm a normal response.
Run sudo certbot certificates and confirm the expected domains.
Confirm sudo certbot renew --dry-run succeeds.
Check Nginx error logs after reload.