Renewal fails before the certificate expires

Let’s Encrypt certificates last about 90 days. Tools such as Certbot try to renew them automatically, often when roughly 30 days or fewer remain. When that job fails, the site can still load for weeks. The first sign visitors see is often the browser security warning, not a panel alert.

Automatic renewal is not a promise. It is a scheduled task that must reach your server, prove you control the domain, and install a new certificate where the web server or CDN actually serves it. Any break in that chain fails quietly until someone reads the log.

If you only need the end date while HTTPS still works, see how to check when an SSL certificate expires. This article is about renewal jobs that stop working on their own.

Confirm whether renewal actually ran

Start with evidence, not guesses.

On many Linux servers with Certbot:

systemctl list-timers | grep certbot

If no timer or cron job is active, nothing will renew after a reinstall or image migration. That alone explains a later expiry.

List what Certbot thinks it manages:

certbot certificates

Read the last real error:

sudo tail -n 100 /var/log/letsencrypt/letsencrypt.log

For a safe test that does not burn production rate limits, use a dry run when your setup supports it (for example certbot renew --dry-run). The log names the challenge type, the hostname, and what Let’s Encrypt fetched.

Managed hosts often hide these commands. Use the host’s SSL or security panel, support tickets, or renewal emails if the provider sends them. The question is the same: did a renewal attempt run, and what error did it return?

The failures that show up most often

What you see What it usually means First fix
DNS problem or NXDOMAIN The name no longer points at the machine that runs renewal Fix A/AAAA records; wait for DNS; retry
Connection refused on port 80 Firewall, security group, or HTTPS-only vhost blocks HTTP-01 Open port 80 for the challenge, or switch to DNS-01
404 on /.well-known/acme-challenge/ Redirects, auth, or wrong webroot swallow the challenge path Exempt that path; fix webroot in renewal config
Unauthorized / wrong content Traffic goes to another host, CDN, or parked page Point DNS at the renewing server, or renew where traffic terminates
Too many certificates / rate limit Repeated failed or duplicate orders in one week Fix root cause; wait out the limit; avoid hammering the API
Renewal succeeded, site still warns New cert on disk but nginx, Apache, or CDN not reloaded Reload the service or publish the new cert at the edge

HTTP-01 validation needs plain HTTP on port 80 from the public internet, even when visitors only use HTTPS. A blanket redirect or a CDN that answers without the challenge file is a common reason renewal “worked last year” and then stopped after a DNS or CDN change.

After you fix the cause

Retry renewal through the same tool or panel you used originally. Then verify what the public site presents, not only what is on disk:

echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | openssl x509 -noout -dates

Replace example.com with the hostname visitors use. Check in a private browser window if you recently saw a warning, so cached errors do not fool you.

If the certificate is already past its end date, browsers block the page until a valid certificate is served. What happens when an SSL certificate expires describes that visitor experience. Uptime checks that only accept HTTPS without validating the certificate date can still look green; uptime monitoring vs SSL monitoring explains why you want both signals.

Watching renewal is not the same as fixing it

Logs tell you why a job failed yesterday. They do not tell you next month that DNS drifted again or that a new redirect rule blocked the challenge path.

A monitor that reads the live certificate expiry date on a schedule catches the calendar problem while the page still loads: the date moved farther out after a good renewal, or it is approaching fast after a silent failure. That is separate from website down email alerts, which answer whether the URL responds.

SiteOK checks each public HTTPS URL every 30 minutes from outside your server. The mobile dashboard shows up, down, and SSL warning beside the expiry date. The weekly email includes SSL expiry per URL. When a renewal is detected, SiteOK sends the new expiration date and keeps watching.

To watch a public URL while you fix renewal on the host, start a free trial. No signup is required.