How Let's Encrypt Works with Nginx
Let's Encrypt is a free, automated certificate authority that issues short-lived TLS certificates (90 days) validated through the ACME protocol. The Certbot client proves domain ownership using either the HTTP-01 challenge, where it temporarily serves a token file at a well-known path that Nginx must be reachable to serve, or the DNS-01 challenge, where it creates a TXT record - useful for wildcard certificates or servers without public HTTP access.
Cricket analogy: It's like the ICC issuing a match referee accreditation only after verifying the candidate passed an on-field assessment - the proof of competence (domain control) must be demonstrated before the credential (certificate) is granted.
Issuing and Auto-Renewing Certificates
The certbot --nginx plugin can both obtain the certificate and automatically edit your Nginx server blocks to add the listen 443 ssl directive and redirect HTTP to HTTPS. Because certificates expire every 90 days, Certbot installs a systemd timer or cron job that attempts renewal twice daily, only actually renewing when a certificate is within 30 days of expiry, and reloading Nginx afterward so the new certificate takes effect without downtime.
Cricket analogy: It's like a fast bowler's fitness re-assessment scheduled every few months rather than once at debut - the system doesn't wait for an injury to force a check, it proactively re-validates well before the old clearance would lapse.
# Install certbot with the Nginx plugin (Debian/Ubuntu)
sudo apt install certbot python3-certbot-nginx
# Obtain and auto-configure a certificate for two domains
sudo certbot --nginx -d example.com -d www.example.com
# Dry-run the renewal process to confirm the timer works
sudo certbot renew --dry-run
# View the systemd timer handling automatic renewal
systemctl list-timers | grep certbotCertbot's HTTP-01 challenge requires port 80 to be reachable from the public internet at the moment of issuance/renewal - firewalls or Cloudflare proxying that block port 80 will cause renewal failures until DNS-01 or an alternate validation path is configured.
Manual Nginx SSL Configuration
When you prefer explicit control instead of letting Certbot rewrite your config, you reference the certificate and key Certbot already saved under /etc/letsencrypt/live/<domain>/ directly in your server block, alongside ssl_protocols restricting to TLSv1.2 and TLSv1.3, and ssl_session_cache to speed up repeat handshakes for returning visitors.
Cricket analogy: It's like a captain who insists on personally setting the field for every over rather than letting the bowler self-arrange it - more manual work, but full control over exactly where each fielder stands.
server {
listen 443 ssl;
server_name example.com www.example.com;
ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
ssl_protocols TLSv1.2 TLSv1.3;
ssl_session_cache shared:SSL:10m;
ssl_session_timeout 1d;
location / {
proxy_pass http://127.0.0.1:3000;
}
}
server {
listen 80;
server_name example.com www.example.com;
return 301 https://$host$request_uri;
}- Let's Encrypt issues free 90-day certificates through the automated ACME protocol, validated via HTTP-01 or DNS-01 challenges.
- certbot --nginx both obtains a certificate and edits Nginx's server blocks automatically, adding HTTPS and an HTTP-to-HTTPS redirect.
- Certbot installs a systemd timer that checks twice daily and renews only when a certificate is within 30 days of expiry.
- HTTP-01 validation requires port 80 to be publicly reachable at issuance/renewal time; DNS-01 is required for wildcard certificates.
- After manual renewal or reconfiguration, Nginx must be reloaded (not just restarted) so the new certificate is picked up without dropping connections.
- ssl_protocols should be restricted to TLSv1.2 and TLSv1.3, excluding older insecure versions like TLSv1.0/1.1.
- certbot renew --dry-run is the safe way to verify the renewal pipeline works before relying on it in production.
Practice what you learned
1. How long is a standard Let's Encrypt certificate valid for?
2. Which ACME challenge type is required to issue a wildcard certificate like *.example.com?
3. What must remain true for the HTTP-01 challenge to succeed?
4. How often does Certbot's renewal timer typically check whether certificates need renewal?
5. What must happen after a certificate is renewed for Nginx to start using it?
Was this page helpful?
You May Also Like
Nginx Security Headers
Learn how to configure HTTP response headers in Nginx to protect users from clickjacking, MIME-sniffing, XSS, and insecure transport.
Nginx Hardening Checklist
A practical, prioritized checklist for locking down a production Nginx deployment, from TLS configuration to information disclosure and module minimization.
Restricting Access with Nginx
Control who can reach specific routes and resources using Nginx's IP allow/deny rules, HTTP basic auth, and satisfy directives.
Related Reading
Related Study Notes in DevOps
Browse all study notesAnsible Study Notes
DevOps · 30 topics
DevOpsAdvanced Kubernetes Study Notes
Kubernetes · 30 topics
DevOpsAdvanced Bash Scripting Study Notes
Bash · 30 topics
DevOpsApache Kafka Study Notes
Kafka · 30 topics
DevOpsDocker & Kubernetes Study Notes
YAML · 40 topics
DevOpsCI/CD Tools & Pipelines Study Notes
YAML · 37 topics