Domainvane

Why Let's Encrypt and registrar auto-renew fail quietly

Corrections: support@domainvane.com

Auto-renew is a job that can exit without an audience

"It auto-renews" describes a schedule, not a result. The certificate on the wire changes only if a client runs, the CA agrees, the new files land where the server reads them, and the server loads them. The domain registration continues only if the registrar's charge succeeds and the registry's date moves. Any step can fail while the homepage still loads, because the old certificate and the old registration remain valid until their dates.

Public certificates are getting shorter, so the gap between a failed renewal and an untrusted site is shrinking. The safety mails people remember have been turned off, or they go to an inbox the agency does not read.

Let's Encrypt will not email you that it failed

From the start of the service until 4 June 2025, Let's Encrypt sent expiration mail to addresses subscribers had put on the ACME account. That service ended on 4 June 2025. The 26 June 2025 announcement says the addresses tied to issuance were deleted from the CA database. The reasons they give are straightforward: most subscribers have automation, keeping millions of addresses is a privacy cost, the mail had a real dollar cost, and the system added operational complexity.

Their December 2025 post tells subscribers to monitor, and it shortens the default profile to 64-day certificates on 10 February 2027 and 45-day certificates on 16 February 2028. An opt-in profile has issued 45-day certificates since 13 May 2026. A client on a fixed 60-day timer will miss that window. They describe renewing at about two thirds of the lifetime, or using ACME Renewal Information (ARI).

If your runbook still says "Let's Encrypt emails us a week before," that line has been false since June 2025.

The renewal job is supposed to be quiet

Certbot's user guide says most installations come with a scheduled certbot renew. renew only does work when a certificate is near expiry, so the timer is meant to run often and usually exit without issuing anything. The packaging guidance tells distributors to run certbot renew -q. Quiet mode, in the Certbot manual, silences everything except errors.

That design is right for a timer. It is also how a failure becomes invisible. The error is printed, and if the timer's output is not delivered anywhere a person looks, the print might as well not have happened. The guide tells you to confirm the command runs without a human before you put it on a schedule, and to test with --dry-run. Those are the checks worth doing on the day you set the timer up, and again after you change web servers, move the site behind a new proxy, or rotate DNS credentials.

A few failures show up in that output often enough that they are worth knowing by name. They are configuration facts from Certbot and from Let's Encrypt's published limits, not a ranking of how often each one happens.

The certificate is not installed where the server reads. certbot certonly obtains a certificate and does not install it for you. A later renew can refresh /etc/letsencrypt/live/<name>/ while nginx still serves a copy under /etc/nginx/ssl/. The CA issued a new certificate. The handshake still serves the old one. --deploy-hook runs after a successful issuance and sets RENEWED_LINEAGE to the live directory. Use it to copy fullchain.pem and reload. Installer plugins reload for you when they configured the server.

The challenge cannot be completed. HTTP-01 needs the CA to reach port 80 on the name in the certificate. A firewall change, a redirect that drops the challenge path, or a new CDN in front of the origin breaks it. DNS-01 needs credentials that can write a TXT record. Those credentials expire, get rotated, or belong to a staff account that was closed. The manual plugin does not renew on a timer unless you also give it an authentication hook. A certificate you issued with --manual and then forgot is not an auto-renewing certificate.

Rate limits are narrower than the folklore. Let's Encrypt's rate-limit page says renewals coordinated through ARI are exempt from all of their rate limits. Older renewal detection, based on the same set of names, can still be subject to some limits. New hostnames are what the new-order limits cover. A separate brake also exists: consecutive authorization failures for one account and one name can pause issuance. Let's Encrypt described that limit in June 2025. A paused name does not recover because the timer runs again tomorrow. Someone has to unpause it.

None of these send mail to your client. The timer's log is the record, if anything is.

The registrar's auto-renew fails on a different calendar

Registrar auto-renew can fail because payment did not complete, auto-renew was disabled, the registrar or account was locked, contact or account state changed, or registry/registrar processing failed. These are possible causes, not a ranking. What the outside world sees is governed by ICANN for gTLDs, and by the registry otherwise.

ICANN's registrant explainer says a registrar that does not delete the name at once may offer an auto-renew grace period of 1 to 45 days. The length is the registrar's. There is no single "you always have 30 days after expiry" for this stage. The 30-day figure in the same policy is the redemption grace period after the registrar deletes the name, for gTLD registries other than sponsored TLDs. During redemption, DNS is off and the name has to be restored through the same registrar, often at a higher fee. After redemption, pending delete lasts 5 days, and then the name can be registered by someone else.

Meanwhile the registry date and the registrar date can diverge. ICANN's 30 September 2025 advisory says the registry may already have auto-renewed the name (and billed the registrar) while the registrar expiration still shows the old term, because the registrant has not paid. Quoting one of those dates as "the" expiry will start an argument that both sides can support with a screenshot.

The required renewal notices go to the registrant email on the domain. If the agency is not that contact, the auto-renew failure is quiet at the agency even when the registrar did everything the policy asks.

Country-code TLDs do not inherit this calendar. Check the registry you are actually using. If RDAP returns no date, the honest status is unknown, not a grace period you estimated.

How to catch it while the site still works

Watch the object the user will notice, from outside the machine that is supposed to renew it.

For the certificate, connect to the hostname on port 443 and read notAfter. Alert when the day count crosses 30, 14, 7, and 1 days, and alert when the handshake itself fails repeatedly. A renewal that wrote files the server does not load shows up as an old notAfter. A renewal that dropped the intermediate shows up as a chain error while the date still looks fine. Those are different alerts.

For the registration, read the RDAP expiry on a schedule and store whether it was the registry event or the registrar event. Alert on that date with the same kind of runway. If the TLD has no RDAP date, keep the row visible as unknown so nobody mistakes silence for safety.

Run that check from somewhere other than the certbot host. A monitor on the same box shares its outages.

Domainvane is built as that outside check. It connects to port 443, queries RDAP, and shows dashboard alert state at 30, 14, 7, and 1 days before whichever expiry it has. Email alerts are delivered to external inboxes, including Gmail. Inbox placement is not guaranteed for every provider (Outlook and Yahoo have not been tested). Failure state appears after three consecutive failures, so one blip is not treated as an incident; recovery state shows when the incident clears. It does not renew anything. Let's Encrypt's own post is the right instruction for the renewal itself: fix the client, prefer ARI, and do not depend on a 60-day hardcoded timer.

If you look after many client hostnames, add them to one account rather than trusting each server's local mail. Create a Domainvane account and put the names whose auto-renew you have never actually watched onto the free tier first. Three hostnames is enough to evaluate the live dashboard status before you move the rest.

Sources

Checked 2026-09-25.

  • Let's Encrypt, "Expiration Notification Service Has Ended," Josh Aas, 26 June 2025 (ended 4 June 2025). https://letsencrypt.org/2025/06/26/expiration-notification-service-has-ended
  • Let's Encrypt, "Decreasing Certificate Lifetimes to 45 Days," Matthew McPherrin, 2 December 2025 (64-day and 45-day dates; 60-day renew intervals; ARI; monitoring). https://letsencrypt.org/2025/12/02/from-90-to-45
  • Let's Encrypt, Upcoming Features, last updated 22 July 2026. https://letsencrypt.org/upcoming-features/
  • Let's Encrypt, Rate Limits (ARI renewals exempt from all rate limits; older renewal detection may still be limited). https://letsencrypt.org/docs/rate-limits
  • Let's Encrypt, "How We Reduced the Impact of Zombie Clients," 4 June 2025 (consecutive authorization failures can pause issuance). https://letsencrypt.org/2025/06/04/how-we-reduced-the-impact-of-zombie-clients
  • Certbot user guide, automated renewal and certbot renew (scheduled renew, --dry-run, hooks). https://eff-certbot.readthedocs.io/en/stable/using.html
  • Certbot manual (--quiet silences all output except errors; --deploy-hook runs after a successful issue). https://eff-certbot.readthedocs.io/en/stable/man/certbot.html
  • Certbot packaging guide (certbot renew -q on a timer, with a per-machine sleep). https://eff-certbot.readthedocs.io/en/stable/packaging.html
  • ICANN, registrant explainer for the Expired Registration Recovery Policy (auto-renew grace of 1–45 days if offered; 30-day redemption after deletion; notices to the registrant email). https://www.icann.org/resources/pages/registrant-about-errp-2018-12-07-en
  • ICANN, renewal and expiration FAQ (5-day pending delete, then release). https://www.icann.org/resources/pages/domain-name-renewal-expiration-faqs-2018-12-07-en
  • ICANN, registrar advisory on registry versus registrar expiration, 30 September 2025. https://itp.cdn.icann.org/en/files/contracted-parties-communications/registrar-registration-expiration-date-30-09-2025-en.pdf