Let's Encrypt rate limits

How limits work

Limits are enforced with a token bucket per request: you can burst up to the full limit, or spread requests out. Hitting a limit never resets instantly — capacity refills gradually over time, and revoking a certificate does not refund it. Error responses include a Retry-After header telling you when to retry.

The limits at a glance

• 50 certificates per registered domain / 7 days — every subdomain of boqsc.eu counts against the same bucket. Global across all accounts. Refills at 1 certificate every 202 minutes.
• 5 certificates per exact set of identifiers / 7 days — issuing a certificate for exactly the same hostname list (including renewals that produce an identical certificate) is capped at 5 per week. Refills at 1 every 34 hours. This is the limit that bites naive renewals.
• 300 new orders per account / 3 hours — one order per requested certificate, regardless of how many names it holds. Refills at 1 order every 36 seconds.
• Up to 100 identifiers per certificate — a single order can cover up to 100 DNS names (fewer is better for performance).
• 5 authorization failures per identifier / hour — each failed HTTP-01 (or TLS-ALPN-01) validation burns this budget. Refills at 1 every 12 minutes.
• 1,152 consecutive failures per identifier — endless retry loops eventually pause issuance for that identifier until validation succeeds once.
• 10 new accounts per IP / 3 hours — only relevant when registering ACME accounts.

What this means for HTTP-01 here

Each subdomain is issued as its own certificate with a single name, validated with HTTP-01 over port 80. Renewing a certificate whose hostname set is byte-identical to the previous one is treated as a renewal: it is exempt from the 300-orders and 50-per-domain limits, but it still counts against the 5 identical-certificates-per-week limit unless the client uses ARI (see below).

In practice, the 50 / week cap is the ceiling for adding subdomains faster than the token bucket refills. Once the certificate is already issued and renewed on schedule, renewals normally stay far below the limits.

ARI renewals are exempt

Renewals coordinated through ACME Renewal Information (ARI) are exempt from all rate limits. ARI-capable clients poll Let's Encrypt, learn the optimal renewal window, and mark the order as replacing an existing certificate. Any new order that shares at least one identifier with the certificate it replaces is not counted. This is the recommended way for renewing a large fleet of subdomains.

When validations fail

HTTP-01 failures almost always come from network or firewall rules that stop the validation servers from reaching the server on port 80, not from the challenge content itself. A failed identifier costs one failure against the 5-per-hour budget. Consecutive failures pause the identifier for that account: roughly 2 failures → ~1,152 days, 5 failures → ~288 days, 20 failures → ~61 days. A single successful validation resets the counter.

If an order is rejected, the error message names the limit that resets furthest in the future and includes a Retry-After header.

Test on staging first

Active development or debugging should use the staging environment: it has far higher limits, so experiments never burn the small production budgets. This server supports --staging (separate staging certificate directory, no impact on live certificates).

Overrides

The 50-per-domain, 300-orders, and account-registration limits can be raised by requesting an override (takes a few weeks). The 5 identical-set and failure limits cannot be overridden — so identical-set renewals should be avoided or handled via ARI, and failures fixed rather than retried blindly.