Guides
Certbot and Let's Encrypt: Issuing and Auto-Renewing Certificates
Issuing the certificate is the easy part. What separates a working setup from a future outage is whether renewal reloads the server — and whether anyone would notice if it stopped.
Lancez un audit DomainLens frais et utilisez le rapport comme liste de priorités.
Choosing a validation method
Let's Encrypt must confirm you control the domain. How it does that determines what you can issue and what has to be reachable.
- HTTP-01 is the default and simplest — but port 80 must be reachable and the challenge path must not redirect.
- DNS-01 is required for wildcard certificates and works for hosts not publicly reachable, at the cost of API access to your DNS provider.
- TLS-ALPN-01 suits environments where port 80 is closed entirely.
| Challenge | Proves control by | Wildcards? |
|---|---|---|
| HTTP-01 | Serving a file under /.well-known/acme-challenge/ | No |
| DNS-01 | Publishing a TXT record at _acme-challenge | Yes |
| TLS-ALPN-01 | A special TLS handshake on port 443 | No |
Issuing a certificate
Prefer webroot over standalone on a live site: standalone needs port 80 free, which means stopping the web server and taking an outage every renewal.
The --nginx and --apache plugins go further and edit the server configuration for you, adding the certificate paths and a redirect from HTTP. That is convenient on a simple host and unwelcome on one whose configuration is managed elsewhere, because the next configuration deployment will overwrite what certbot wrote. On any server whose config comes from version control or a configuration manager, use certonly and reference the files yourself.
Certificates issued this way live under /etc/letsencrypt/live, and those paths are symlinks that always point at the current version. Reference the symlink rather than the dated directory behind it, or the server will keep serving the certificate that was current on the day you wrote the config.
# nginx, with automatic config editing
sudo certbot --nginx -d example.com -d www.example.com
# Apache
sudo certbot --apache -d example.com
# Webroot: server keeps running, certbot writes the challenge
sudo certbot certonly --webroot -w /var/www/html \
-d example.com -d www.example.com
# Standalone: certbot binds port 80 itself (server must stop)
sudo certbot certonly --standalone -d example.com
# Wildcard — requires DNS-01
sudo certbot certonly --dns-cloudflare \
--dns-cloudflare-credentials ~/.secrets/cloudflare.ini \
-d example.com -d '*.example.com'Making renewal actually automatic
Certbot installs a systemd timer or cron entry that runs twice daily and renews anything within 30 days of expiry. That part usually works. What fails is the reload: a renewed certificate sits on disk while the running server keeps serving the old one.
The deploy hook exists for exactly this. Set it once and the reload can never be forgotten.
# Test the whole renewal path without issuing anything
sudo certbot renew --dry-run
# Reload after any successful renewal
sudo certbot renew --deploy-hook "systemctl reload nginx"
# Persist it for every certificate
# /etc/letsencrypt/renewal-hooks/deploy/reload-nginx.sh
#!/bin/sh
systemctl reload nginx
# Confirm the timer is active
systemctl list-timers | grep certbotRate limits and the mistakes that hit them
Almost every rate-limit incident comes from re-running a failing command repeatedly rather than reading the error. When issuance fails, fix the validation before trying again.
- Fifty certificates per registered domain per week — reachable when a script loops on failure.
- Five duplicate certificates per week for the identical set of hostnames.
- Five failed validations per account per hostname per hour.
- Use --dry-run while debugging; it exercises the full path against the staging environment and counts against nothing.
How DomainLens contributes
Certbot reports what it wrote to disk; DomainLens reports what the server presents to the internet. Those disagree precisely when the reload was missed, which is the failure this setup exists to prevent. Check with the SSL checker , and see SSL certificate expired for when it has already happened.
- How often do Let's Encrypt certificates renew?
- They are valid for 90 days and certbot attempts renewal at 30 days remaining. That leaves several weeks of retries before anything expires.
- Can I get a wildcard certificate from Let's Encrypt?
- Yes, but only through DNS-01 validation, which needs API access to your DNS provider. HTTP validation cannot issue wildcards.
- Is a Let's Encrypt certificate as good as a paid one?
- For encryption and browser trust, identical. Paid certificates differ in warranty, organisation validation and support — none of which affects how a browser or Google treats the connection.
- Why does renewal fail with a challenge error?
- Usually the /.well-known/acme-challenge path is redirected, blocked by a firewall, or handled by an application route instead of being served as a file.