Let's Encrypt rate limits blocking renewal

Let's Encrypt rate limits block repeated failures—parse the error, stop retry loops, fix challenges on staging first.

When this happens

Logs say too many certificates already issued or too many failed authorizations. Chaos tests hammering certbot in staging pointed at production Boulder by typo burned the whole company's weekly quota.

CI retried certbot fifty times after misconfigured nginx. Pen-tests sometimes trigger validation failures mistaken for attacks on origin.

First response

Let's Encrypt rate limits blocked renewal—parse error types, pause retries, and use staging to fix challenges.

Searches for let's encrypt rate limit usually mean automated renewal failed, succeeded locally but never reached the TLS listener, or hit Let's Encrypt rate limits. The fix is almost always permissions, challenge reachability, or a missing reload—not buying a longer-lived commercial cert as the first move.

For Let's Encrypt rate limits blocking renewal, read the ACME or panel error verbatim, run a dry-run renewal if your stack supports it, then confirm what certificate strangers receive on port 443 after you deploy. Certificate files on disk lie; only live handshakes matter for users.

Rate limit errors panic teams mid-incident because Boulder returns a hard stop with retry-after semantics. Duplicate certificates, failed validation attempts, and too many exact sets per week all count. Stop hammering renewals; read the error JSON type and wait or rename architecture. Triage should capture timestamps, account URLs, and the last Boulder error type before infrastructure changes widen blast radius.

See also ACME DNS-01 challenge propagation delays and ACME HTTP-01 challenge failed 403.

Why renewal failed

Limits cover failed validations, duplicate certs per week, and certs per registered domain. Embed staging server URLs in CI defaults and guard production URL with an explicit environment flag requiring human approval. Rate limits are incident signals for broken automation, not CA malice.

Staging endpoint avoids burning production limits while debugging. When waiting out duplicate certificate limits, avoid deleting lineages unless you will shrink SAN sets—re-creating identical certs resets the counter slowly but does not help mid-window. Staging endpoints exist to burn debugging cycles without touching production quotas.

Waiting out a limit window is faster than opening duplicate tickets. Post-incident reviews should count how many failed validations preceded the hard stop.

Let's Encrypt enforces failed validations per hostname, certificates per registered domain per week, and duplicate cert limit for identical SAN sets. Staging environment exists precisely to debug automation without production limits. Clarify in tickets whether failure is validation, issuance, deploy, or listener presentment—teams too often mix these phases when reading logs.

Rate limits are not negotiable with support for default DV. Buying certs elsewhere does not reset LE counters immediately for same names. Continuing retries during rate limits extends outages and lengthens ban windows; status pages should announce automation pause when Boulder returns rateLimited.

Common causes

These patterns drive most let's encrypt rate limit tickets. They explain why automation logs look green while browsers or APIs still break.

CI loop retried certbot fifty times after nginx 403.

Deleted and recreated identical SAN set six times in one week.

Wildcard plus apex split into redundant orders. Blue/green certbot lineages alternating identical SAN sets during experiments burn duplicate limits.

Diagnose

Read Boulder detail URL and error type in certbot output. Pause marketing of imminent fix until staging reproduces success; announcing quick recovery during rate limits damages trust twice.

Log Boulder detail URL from certbot; map to LE docs table for which limit fired. Save Boulder error detail link in wiki runbooks so future shifts recognize rate limit JSON instantly.

Fix step-by-step

Follow this sequence for let's encrypt rate limits blocking renewal. Capture command output after each step so the next responder can pick up without rerunning destructive changes.

1. Stop automated renew scripts immediately.
2. Identify which limit triggered from error JSON.
3. Fix root challenge or SAN issue using staging.
4. Wait required window before production retry.
5. Reduce duplicate issuance attempts during CI.
6. Success once with corrected configuration.
7. Verify openssl on all affected names.
8. Add retry backoff in automation.
9. Archive redacted ACME logs and openssl transcripts in the ticket before closing.
10. Schedule a follow-up dry-run before the next natural renewal window.

Verify the live certificate

OpenSSL

echo | openssl s_client -connect HOST:443 -servername HOST 2>/dev/null | openssl x509 -noout -dates -subject -issuer

Replace HOST with the public hostname on the certificate.

How to read the output

While blocked, old cert may still serve—openssl shows days left to plan migration.

curl

curl -vI --connect-timeout 10 https://HOST/ 2>&1 | grep -Ei 'expire|SSL certificate|subject:|issuer:'

Replace HOST with the public hostname users request.

Roll out and verify

Parse rate limit error; pause automation; fix root challenge issue on staging.

Wait window out; issue once with corrected config. Document incident timelines with limit type and UTC reset to prevent second waves of manual retries.

Cache staging successes in CI; alert before duplicate cert limit.

What to automate

Detect rate limit strings in logs and halt CI cert jobs automatically. Detect Boulder rate limit strings in logs and auto-pause retry jobs.

ssldays tracks notAfter so you have runway while limits cool down. ssldays ensures you still know real expiry during mandatory waiting periods.