Automate Let's Encrypt renewal with cron

Run certbot renew regularly and let Certbot decide which certificates are due. Many installations already include a systemd timer or cron entry, so check for that before creating another schedule.

Do not hard-code “90-day certificates renew at 30 days” as a universal rule. Renewal eligibility depends on Certbot's version, certificate lifetime, configuration, and ACME Renewal Information (ARI) when available. Current Certbot can honor the CA's suggested renewal window; its lifetime-based fallback also supports short-lived certificates.

1. Install Certbot

For distributions offering these packages:

# Ubuntu/Debian
sudo apt install certbot python3-certbot-nginx

# Supported RHEL-family systems with the required repositories enabled
sudo dnf install certbot python3-certbot-nginx

Package availability and supported installation methods vary by distribution. Use the installation method appropriate to the deployed OS and avoid mixing package managers for one Certbot installation.

2. Check for an existing renewal job

systemctl list-timers | grep certbot
ls /etc/cron.d/ | grep certbot
sudo certbot renew --dry-run

These are useful checks, not an exhaustive inventory of every installer or custom unit name. A working timer usually makes an additional cron entry unnecessary.

Inspect the dry-run result and Certbot logs. If you collect those logs with DataKit, retain the domain and execution time. After a real renewal, check the certificate presented by the service from a client: an updated file does not prove that the web server loaded it.

3. Add a cron entry if none exists

For /etc/cron.d/certbot, where the username field is required:

# Check at 03:17 and 15:17 daily. Verify executable paths on this host.
17 3,15 * * * root /usr/bin/certbot renew --quiet --deploy-hook "/usr/bin/systemctl reload nginx"

Twice-daily checks provide repeated opportunities to renew without forcing issuance each time. Stagger execution times across hosts; use an appropriate randomized delay or timer configuration for a fleet.

--quiet suppresses routine output. A deploy hook runs after a successful renewal, making it a better place for a necessary reload than an unconditional command after every invocation. Check whether the selected installer already reloads the service and avoid redundant hooks.

4. Account for the authenticator

• Nginx/Apache plugins: validate with the saved plugin configuration. The plugin and installer choices determine validation and installation behavior.
• Webroot: renewal reuses the saved webroot configuration. The challenge path must remain publicly reachable; the web server can stay running.
• Standalone: the HTTP-01 listener needs port 80 available. If another service owns it, pre/post hooks such as --pre-hook "systemctl stop nginx" --post-hook "systemctl start nginx" may be necessary. This introduces downtime and must fit the deployment. Do not blindly combine it with a reload hook that runs while Nginx is stopped.

FAQ

What happens if the certificate still has 60 days left?

It is usually skipped unless the configured or CA-provided renewal window says it is due. Older Certbot releases used a fixed 30-day threshold. Certbot 4.0 and later use a lifetime-based fallback, with special handling for certificates valid for no more than ten days. --force-renewal overrides normal eligibility and should not be used for routine scheduling; issuance limits still matter.

Why does a browser still see the old certificate?

Check the served endpoint, proxy/load balancer, certificate paths, and reload result. Confirm which component terminates TLS before assuming the local Nginx process is responsible.

Does each name on a multi-domain certificate renew separately?

No. Names on one certificate renew together as that certificate's lineage. certbot renew checks the saved renewal configurations and attempts the lineages that are due.

The Certbot user guide documents eligibility and hooks.