Why Automatic SSL Renewal Fails, and How to Catch It

When automatic SSL renewal fails, it almost never tells you. The certificate keeps working right up to its last day, and then browsers start showing "Your connection is not private" and visitors leave. The renewal was automatic, until something around it changed and nobody checked again.

Here are the causes that come up most often, how to find yours, and how to hear about it with time to spare.

Why this matters more than it used to

Certificates keep getting shorter. Since March 15, 2026, the maximum lifetime is 200 days; it drops to 100 days in 2027 and 47 days in 2029, as we covered in 200-, 100-, and 47-day SSL certificates. Let's Encrypt certificates already last 90 days. More renewals per year means more chances for one to fail.

There's also one less safety net: Let's Encrypt stopped sending expiration reminder emails in June 2025. If you relied on that email, it's gone.

The most common causes

• Validation can't reach the server. To renew, the certificate authority checks that you control the domain, usually by requesting a file under /.well-known/acme-challenge/. A misconfigured redirect, a firewall rule, a security plugin, or your CDN can block that path.
• The domain no longer points to that server. If you moved DNS to a new host or a CDN, the old server is trying to renew a domain that no longer reaches it, and the new one may never have issued its own certificate.
• The DNS API credential expired. With DNS validation, the renewal tool uses an API key from your DNS provider. If that key was revoked or rotated, renewal fails.
• The renewal job isn't running. The systemd timer or certbot cron entry was lost in a migration or disabled.
• It renewed, but the server isn't using it. The new certificate is on disk, but the web server was never reloaded and still serves the old one.
• There's more than one server. Behind a load balancer, one node renewed and another didn't.
• A CAA record doesn't authorize the CA. If your DNS has a CAA record that only allows a different authority, the renewal is refused.
• The certificate doesn't cover every hostname. It renewed for yourdomain.com but not www.yourdomain.com, or vice versa.

How to diagnose it, step by step

1. Check the certificate actually being served. The SSL checker shows the expiration date, issuer, and covered names. If the date is old, the renewal never reached the server that's answering.
2. Check where the domain points with the DNS lookup. If it points somewhere else, that's the server that needs to renew.
3. Do a dry run. With certbot, certbot renew --dry-run simulates renewal without changing anything and shows the error.
4. Read the tool's log. For certbot it's usually under /var/log/letsencrypt/. In a hosting control panel, look for the SSL or AutoSSL section and its history.
5. Confirm the job is scheduled. systemctl list-timers shows whether the certbot timer exists and when it last ran.
6. Check the domain's CAA records, also with the DNS lookup.

Fixes by cause

• Validation path blocked: allow access to /.well-known/acme-challenge/ without redirects or blocks.
• DNS moved: renew on the server the domain now points to, and remove the job from the old one.
• Expired DNS credential: create a new API key and update it in the tool's configuration.
• Server never reloaded: add a web server reload after renewal (certbot can run a command after each successful renewal).
• Multiple servers: centralize issuance, or check the certificate on each node.

How to find out before it expires

Automatic renewal is fine. What's missing is something that confirms it worked. A monitor that reads the certificate your site actually serves and counts the days left will warn you when the date gets close and hasn't moved.

In MonitoraWeb, each monitor lets you choose how far ahead to be warned: 1, 2, 3, 7, 14, 30, or 60 days. Your email and WhatsApp alert lists get the certificate alert when 3 days are left or it has already expired. If renewal is working, the date moves on its own and you hear nothing.

One limit to keep in mind: we read the certificate from a single location, whichever one the responding server hands us. If several servers serve different certificates, we see one of them. The full details are on SSL expiration monitoring.

Frequently asked questions

My host renews certificates automatically. Do I still need to monitor them?

It's worth it. Automatic renewal breaks because of DNS changes, firewall rules, or lost jobs, and it rarely warns you. Watching the expiration date is how you know it worked.

How can I tell whether my certificate renewed?

Check the expiration date of the certificate your site serves, not the file on the server. If the date moved forward, it renewed and is in use.

The new certificate is on the server, but the site shows the old one. Why?

The web server wasn't reloaded after renewal, or another server or your CDN is still serving the previous certificate.

Does Let's Encrypt warn me before a certificate expires?

Not anymore. It stopped sending expiration emails in June 2025, so you need another way to keep track.

How much advance warning should I get?

Enough to fix a broken renewal calmly. With certificates of 90 days or less, 7 to 14 days is usually a good margin.

Sources

• CA/Browser Forum, Ballot SC-081 on certificate lifetimes: cabforum.org
• Let's Encrypt, ending expiration notification emails: letsencrypt.org
• Certbot documentation: eff-certbot.readthedocs.io