Let’s Encrypt certificates are valid for only 90 days, so production sites should always enable automatic renewal to avoid HTTPS downtime.
If you already issued the certificate with Certbot, there are usually two things left:
- Configure a scheduled renewal task
- Verify the renewal workflow actually works
First, Check Whether Certbot Already Created a Scheduler
Depending on your distro, Certbot may already install a scheduler (for example, a systemd timer or /etc/cron.d/certbot).
You can check with:
|
|
If a valid timer already exists, you usually do not need an extra crontab entry.
Add a Crontab Job Manually (Recommended Example)
If you prefer managing renewal explicitly, edit root crontab:
|
|
Add this line (runs daily at 03:00):
|
|
What it means:
0 3 * * *: run at 03:00 every daycertbot renew: renew certificates that are close to expiration--pre-hook: stop Nginx before renewal (common for standalone mode)--post-hook: start Nginx after renewal>> /tmp/certbot-renew.log 2>&1: append logs for troubleshooting
Run a Dry Test Before Relying on Cron
After adding the task, validate the full flow manually:
|
|
If dry-run succeeds, you can safely rely on the scheduled job.
Common Notes
- If you use the
webrootornginxplugin, you often do not need to stop Nginx. In many setups, reloading Nginx after renewal is enough:
|
|
-
certbot renewonly performs actual renewal near expiration, so running it daily is normal. -
For long-term maintenance, consider writing logs to a persistent path such as
/var/log/letsencrypt/.
Summary
Reliable certificate auto-renewal is not just about writing a command. The key is confirming the workflow can run end to end.
A stable setup is usually just these three steps:
- Check whether system-level scheduling already exists
- Add cron if needed and keep logs
- Validate once with
--dry-run