Automatic renewal is a promise that you can stop thinking about certificates. It mostly keeps that promise, which is why the day it fails is a surprise. The site worked yesterday, and today browsers show a full-page warning.
The reason is that "auto-renewal" is not one thing. For a certificate issued through the common automated protocol (ACME), which Let's Encrypt and others use, several steps must all work every time. For how certificates work in general and how to read their dates, see How to Prevent SSL Certificate Expiration. This guide is about the case where automation was on and the certificate expired anyway.
The chain of steps
- A job starts. Something runs on a schedule: a timer, a cron entry, or a built-in task of your hosting.
- The renewal client asks for a new certificate. It contacts the certificate authority.
- The authority checks that you control the name. A challenge must be answered, over the web or in DNS.
- The new certificate is saved to a file or store.
- The server loads it. Many servers read the file only at start or on a reload.
- Visitors receive it. On every address, port, and layer that presents a certificate.
If step 1 never runs, nothing else matters. If step 5 never happens, the renewed file sits unused. Each failure looks the same from outside: an old certificate that expires.
Where it breaks
| Step | What goes wrong | A typical sign |
|---|---|---|
| 1 | The scheduled job was removed, disabled, or never moved after a server migration or an upgrade | Nothing in the renewal log for weeks |
| 2 | The client is too old, or its account or access is gone | Errors in the renewal log about the account or the request |
| 3 | The validation step stopped working: a changed firewall, a redirect that blocks the path the challenge uses, a DNS record or API access that was changed | A "challenge failed" or "unauthorized" error |
| 3 | Too many failed or repeated requests reached the authority's rate limit | A rate-limit message; renewals fail until the limit passes |
| 4 | The file could not be written, or a hook that copies it failed | The new file exists in one folder and not in another |
| 5 | The server was never reloaded, or it reads a different file than the one the client updates | The file shows a new date, the browser shows an old one |
| 6 | The certificate is presented by another layer: a load balancer, a CDN, a mail server, another port, another virtual host | One address is renewed, another is not |
Forum threads and hosting guides describe all of these. The most common stories are a job that disappeared after a change, and a certificate that was renewed but a server that kept serving the old copy.
Find the broken link
Work from the end, because that is what visitors see.
What is being served
echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | openssl x509 -noout -dates -subject
This prints the start and end dates of the certificate that the server presents on that address. If the end date is near or past, the certificate is not renewed where it matters. Run it for every name and port you use, not only the main one.
What is on disk
With Certbot, the list of certificates and their expiry dates is:
sudo certbot certificates
If the file has a new date and the server shows an old one, the problem is at step 5 or 6: the server did not reload, or it reads another file. If the file itself is old, the problem is at steps 1 to 4.
Is the job running
On a system that uses timers, systemctl list-timers lists the scheduled jobs. Look for the renewal one and when it last ran. A plain cron setup is in crontab -l and in the files under /etc/cron.d/.
Does renewal work now
sudo certbot renew --dry-run
A dry run goes through the steps without replacing anything. An error here is the same error that blocked the real renewal, and it names the step.
Note
These commands assume Certbot on a Linux server. Other clients and hosting panels have their own tools. The order stays the same: what is served, what is saved, whether the job runs, whether renewal works.
Fix and prevent
- Fix the cause, then renew once by hand so that you are not waiting for the next scheduled run.
- Reload the server after every renewal. Most clients can run a command after a successful renewal. Without it, a renewed file can sit unused.
- List every place a certificate lives. The website, the mail server, the API host, the staging host, the load balancer. Each one needs its own renewal and its own check.
- Do not trust the job's own silence. A job that fails quietly looks the same as a job that works. The only proof that renewal worked is the new date on the certificate that is actually served.
- Keep an independent alert. A warning that comes from outside, ahead of the end date, does not depend on any step in the chain working.
What a monitor adds
A monitor that connects to your address from the outside reads the certificate that visitors would receive. That is step 6, the only step you cannot fake from inside the server, and it catches every failure above, whichever step caused it.
UptimeWire checks the certificate of every https address about every six hours and warns you by email and Telegram, within the period you chose for that website, from 1 to 60 days before it expires. The warning is sent once. It is a reminder for you to act: UptimeWire does not renew, install, or fix certificates, and it does not find why a renewal failed. It checks the certificate for the address you add, so other names and ports need their own entries.
Because certificates are checked about every six hours, a warning arrives some hours after the threshold is crossed, not at that exact moment. For a certificate that is renewed automatically, a warning period of 14 or 30 days works as a safety net: if it fires, the automation has already missed its chance, and you still have time to fix it before visitors are affected. See SSL certificate expiration monitoring for the workflow after a warning arrives.
Checklist
- What certificate does each address and port serve, and when does it end?
- Is the renewal job scheduled, and when did it last run?
- Does a dry run succeed, or which step does it name?
- Is the server reloaded after renewal?
- Does every name, subdomain, and service that presents a certificate renew?
- Is there a warning from outside, set well ahead of the end date?