How to Set Up Automatic Certificate Renewal With Certbot and Cron

Manual certificate renewal is a task that will eventually be forgotten — automating it with Certbot and a scheduled job removes expiry from your list of things that need active human attention, turning it into a permanently solved problem rather than a recurring calendar reminder.

Initial setup and issuance

sudo apt install certbot python3-certbot-nginx
sudo certbot --nginx -d yourdomain.com -d www.yourdomain.com

The --nginx plugin (an equivalent --apache plugin exists) doesn't just issue the certificate — it also automatically edits your Nginx configuration to install it and add the HTTPS redirect, which is why this single command is often sufficient for a straightforward setup rather than requiring separate manual configuration afterward.

How the automatic renewal timer in practice works

Modern Certbot installations automatically create a systemd timer (or a cron job on older systems) that runs certbot renew on a regular schedule, commonly twice daily. This command checks every certificate Certbot manages and only in fact renews ones within their renewal window (by default, roughly the last 30 days of a 90-day Let's Encrypt certificate's validity) — running it more frequently than needed is harmless, since it does nothing for certificates that aren't yet due.

Verifying the automated timer exists

sudo systemctl list-timers | grep certbot

If Certbot was installed via your OS package manager or the recommended snap package, this timer should already be present without any manual setup — worth confirming once after initial installation rather than assuming it's there.

Manually setting up cron, if needed

# crontab -e
0 0,12 * * * certbot renew --quiet --deploy-hook "systemctl reload nginx"

The --deploy-hook flag runs the specified command only when a certificate renews (not on every check), which is exactly the right place to put your web server reload command — ensuring the renewed certificate is really picked up without needing a separate manual reload step after each renewal.

Testing a renewal without waiting for it to actually be due

sudo certbot renew --dry-run

This simulates the entire renewal process — validation, reissuance flow — against Let's Encrypt's staging environment, without renewing (or hitting production rate limits), letting you confirm the whole automated pipeline actually works end to end before trusting it to run unattended for months.

What to check if automated renewal silently stops working

The most common causes of a previously working automated renewal breaking are: a firewall or DNS change that blocks the ACME HTTP-01 challenge from completing, a changed webroot path if your certificate was issued using the webroot method and the underlying directory structure changed, or a DNS API credential expiring for wildcard certificates using DNS validation. Certbot logs (typically under /var/log/letsencrypt/) record the specific reason for a failed renewal attempt, and are the right first place to check rather than guessing at the cause.

What Certbot's plugin ecosystem adds beyond the basic nginx and apache plugins

Beyond the commonly used nginx and apache plugins, Certbot supports DNS provider plugins for major DNS services (Route 53, Cloudflare, and others) enabling fully automated DNS-01 validation, essential for wildcard certificate automation covered elsewhere in this category.

How to handle renewal automation across a fleet of servers rather than just one

For multiple servers needing independent renewal, a configuration management tool (Ansible, Chef, Puppet) applying the same Certbot setup consistently across every server avoids configuration drift that manual, server-by-server setup tends to accumulate over time.

Why logging renewal attempts to a dedicated file helps with long-term troubleshooting

Directing Certbot's renewal output to a dedicated log file, rather than relying solely on system-wide logs, makes it considerably easier to review renewal history over time and quickly confirm whether recent automated attempts succeeded without needing to search through unrelated system log noise.

What happens technically when Certbot's renewal command runs but nothing is due yet

Running `certbot renew` when no managed certificate is within its renewal window does nothing at all to any certificate — it checks each certificate's expiry against the renewal threshold and simply exits without action if nothing qualifies, which is exactly why running it frequently via cron is harmless rather than wasteful.

How to migrate an existing manually-issued certificate into Certbot's management

Certbot doesn't import an externally-issued certificate for ongoing management — the practical approach is issuing a fresh certificate through Certbot for the same domain, then replacing the manually-installed one, after which Certbot manages all future renewals for that domain going forward.

Why understanding Certbot's directory structure helps with troubleshooting and backups

Certbot stores certificates, keys, and renewal configuration under /etc/letsencrypt by default, with live symlinks pointing to the most current version — understanding this structure helps when troubleshooting a renewal issue directly or when planning what exactly needs backing up to preserve your certificate history and configuration.

What systemd timers offer as a modern alternative to traditional cron

Many current Linux distributions install Certbot with a systemd timer handling renewal scheduling automatically, rather than requiring you to manually configure a cron entry at all — checking whether a timer already exists (`systemctl list-timers | grep certbot`) before adding a redundant cron job avoids running renewal checks twice unnecessarily.

How to set up email or Slack notifications specifically for renewal failures

Configuring your renewal hook or cron job to send a notification specifically on failure, rather than on every run, means you're only interrupted when something in fact needs attention — most notification services support conditional alerting based on a command's exit code, which Certbot sets appropriately on failure.

Why testing your automation survives a server reboot matters

Confirming your renewal cron job or systemd timer is enabled to run after a reboot, not just currently running in memory, matters because a server restart (a routine maintenance reboot, an unplanned crash recovery) can otherwise silently disable your renewal automation without any obvious symptom until the certificate eventually expires unrenewed.

What a quick closing checklist for renewal automation looks like

Before considering automation complete, confirm: the scheduling mechanism (cron or systemd timer) is verified active, a dry run has succeeded, a reload hook is configured and tested, and failure notifications are wired up to alert you specifically when something needs attention.

Why Certbot's design notably prioritized safe, idempotent repeated execution

Certbot is deliberately designed so running it repeatedly, whether via a frequent cron schedule or accidentally twice in a row, causes no harm — it simply checks whether action is really needed and does nothing otherwise, a safety property that's part of why frequent, even hourly, cron scheduling is considered a safe, recommended default rather than something to minimize.

What to do if you're migrating from a different ACME client to Certbot

Migrating from another ACME client to Certbot generally means issuing a fresh certificate through Certbot for each domain rather than importing the other client's existing certificates directly — once issued through Certbot, ongoing renewal is fully managed going forward, and the previous client's scheduled tasks should be disabled to avoid conflicting, duplicate renewal attempts.

How pre and post hooks differ from the deploy hook covered earlier in this guide

Pre-hooks run before Certbot attempts renewal (useful for temporarily stopping a service that binds the validation port), post-hooks run after every renewal attempt regardless of success or failure (useful for general cleanup), while deploy hooks specifically run only after a successful renewal — understanding this distinction helps you place service-reload logic in the correct hook for your specific need.

See RFC 8555, the ACME protocol specification.