Auto-renew SSL certificates with Certbot and cron on Linux

Let’s Encrypt certificates have a 90-day validity period — an intentional decision by the project to force automation and reduce the exposure window in case of compromise. Manual renewal every 60-80 days is unsustainable in production: a trip, an overloaded on-call rotation or a forgotten server is all it takes for TLS to expire and the site to start returning ERR_CERT_DATE_INVALID in customer browsers.

This tutorial is for sysadmins and developers who already have Certbot installed and at least one issued certificate, and want to ensure renewal runs without intervention, reloads the web server without downtime and alerts them if something breaks. We’ll cover both approaches — classic cron and systemd timer — when to pick each, configure deploy hooks for Nginx/Apache reload and set up basic monitoring.

Estimated execution time: 15 to 25 minutes, depending on how many domains you manage and whether you’ll configure custom alerts.

Prerequisites

Confirm the Certbot version and the presence of at least one certificate before proceeding:

certbot --version
sudo certbot certificates

The certbot certificates output should list each certificate with its name, covered domains and expiration date. If nothing appears, issue a first certificate before setting up automation — this documentation assumes the initial issuance step has already been done.

Checking if the systemd timer is already active

On modern distros the certbot package automatically installs a systemd unit that handles renewal — before touching cron, confirm whether it’s already running. Most Ubuntu 22.04+ installations don’t need any manual cron at all.

systemctl list-timers --all | grep -i certbot

systemctl cat certbot.timer

systemctl cat certbot.service

Configuring renewal via traditional cron

If you’re on an older distro, a server without systemd, or you simply prefer cron, use this approach. On modern distros, disable the timer first to avoid two concurrent executions.

sudo systemctl disable --now certbot.timer

sudo crontab -e

PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
0 3,15 * * * /usr/bin/certbot renew --quiet

sudo crontab -l

Configuring a deploy hook for reload without downtime

Renewing the certificate isn’t enough — Nginx or Apache keeps using the old cert loaded in memory until it receives a reload signal. Deploy hooks solve this elegantly.

sudo mkdir -p /etc/letsencrypt/renewal-hooks/deploy
sudo tee /etc/letsencrypt/renewal-hooks/deploy/reload-nginx.sh > /dev/null <<'EOF'
#!/bin/bash
systemctl reload nginx
EOF
sudo chmod +x /etc/letsencrypt/renewal-hooks/deploy/reload-nginx.sh

sudo tee /etc/letsencrypt/renewal-hooks/deploy/reload-apache.sh > /dev/null <<'EOF'
#!/bin/bash
systemctl reload apache2
EOF
sudo chmod +x /etc/letsencrypt/renewal-hooks/deploy/reload-apache.sh

sudo certbot renew --dry-run

Monitoring renewals

Automation without observability is a trap — finding out the cert expired through a browser error is the worst-case scenario. Set up an active check that warns you in advance.

sudo tee /usr/local/bin/check-ssl-expiry.sh > /dev/null <<'EOF'
#!/bin/bash
THRESHOLD_DAYS=20
ALERT_EMAIL="[email protected]"

for cert in /etc/letsencrypt/live/*/cert.pem; do
  domain=$(basename "$(dirname "$cert")")
  end_date=$(openssl x509 -enddate -noout -in "$cert" | cut -d= -f2)
  end_epoch=$(date -d "$end_date" +%s)
  now_epoch=$(date +%s)
  days_left=$(( (end_epoch - now_epoch) / 86400 ))

  if [ "$days_left" -lt "$THRESHOLD_DAYS" ]; then
    echo "ALERT: $domain expires in $days_left days" | \
      mail -s "SSL expiring: $domain" "$ALERT_EMAIL"
  fi
done
EOF
sudo chmod +x /usr/local/bin/check-ssl-expiry.sh

echo "30 8 * * * /usr/local/bin/check-ssl-expiry.sh" | sudo tee -a /etc/crontab

Final verification

Run the commands below to confirm the whole setup is active:

sudo certbot renew --dry-run
systemctl list-timers --all | grep certbot
ls -la /etc/letsencrypt/renewal-hooks/deploy/
sudo /usr/local/bin/check-ssl-expiry.sh

The dry-run should pass without errors. The timer (if you chose systemd) should be active. Hooks must be executable. The check script should not emit an alert — if it does, the cert is in a critical window and you need to investigate logs at /var/log/letsencrypt/letsencrypt.log.

Troubleshooting

”Failed authorization procedure” on renew

Common cause: port 80 blocked by firewall or redirected to 443 without an exception for the /.well-known/acme-challenge/ path. Certbot needs to serve the HTTP-01 challenge on that route. Confirm with curl http://your-domain/.well-known/acme-challenge/test — it should return a 404 from your server, not a connection error. If you force a global redirect to HTTPS, add an exception for that path in Nginx.

”Hook command exited with code 1”

The hook script returned an error. Run it manually to debug: sudo bash /etc/letsencrypt/renewal-hooks/deploy/reload-nginx.sh. Typical errors: invalid nginx config (nginx -t first), service not running, or wrong script permissions.

Timer appears active but never renews

Check the server clock with timedatectl — if it’s incorrect, the timer fires but certbot rejects the operation. Sync with sudo systemctl restart systemd-timesyncd. Another case: the cert isn’t yet in the 30-day pre-expiration window; certbot ignores it silently. Force with --force-renewal only if you’ve ruled out other causes.

Next steps

With renewal automated and monitored, consider these next steps to strengthen your TLS setup:

• Configure OCSP stapling in Nginx — reduces cert validation latency in the browser and lowers load on Let’s Encrypt OCSP servers.
• Evaluate wildcard certificates with the DNS-01 challenge — useful if you manage many subdomains; requires a DNS plugin for your specific provider.
• Implement HSTS preload after confirming renewal stability — hard to reverse, so only enable it once automation has run through at least 2 full cycles.
• Centralize renewal logs in an observability system — useful in server fleets where checking each machine individually doesn’t scale.

If you’re putting this into production, a Hostini VPS ships with up-to-date Ubuntu LTS, hardened SSH by default and traffic with DDoS protection — a solid base for TLS automation without kernel or network surprises.