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/certbotIf 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.comAfter the certificate is issued, test and reload Nginx if needed:
sudo nginx -t
sudo systemctl reload nginxOption 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.comThen 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 || trueIf 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.shWildcard 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 certificatesand confirm the expected domains. - Confirm
sudo certbot renew --dry-runsucceeds. - Check Nginx error logs after reload.
Related Fix I.T. Phill guides
- Nginx HTTP/2 Modern Config Guide
- Nginx HLS Playback Guide
- How to Install WordPress on Nginx LEMP Hosting
- Nginx WordPress Optimization: Best Configurations
