Issuance and renewal

Let's Encrypt rate limit errors: find the limit and recover

By · Last verified

Error messageurn:ietf:params:acme:error:rateLimited: too many certificates (5) already issued for this exact set of identifiers in the last 168h0m0s, retry after ...

A rateLimited error means Let's Encrypt refused a new account, order or certificate because you used up one of its issuance limits. The most common trigger is reissuing the same certificate again and again while debugging, which hits the "5 certificates per exact set of identifiers per 7 days" limit.

Quick fix

Read the error text: it names the limit and gives a retry after time in UTC. Then:

  1. Stop retrying. Every failed attempt may consume more capacity. Disable cron jobs, CI pipelines or container restarts that call your ACME client in a loop.
  2. Reuse what you have. Certbot keeps every issued certificate under /etc/letsencrypt/archive/<name>/; acme.sh keeps them under ~/.acme.sh/<name>/. Install the newest valid one.
  3. Debug against staging. Point your client at staging until issuance works, then switch back:
certbot certonly --staging -d example.com -d www.example.com
acme.sh --issue --staging -d example.com -w /var/www/html

Causes

Duplicate certificates cause most rate limit errors; the other three limits are hit less often. The numbers below are taken from the Let's Encrypt rate limits page (last updated 5 August 2026). Limits change from time to time, so treat the official page as authoritative.

Limit Allowance Refill Override
New certificates per exact set of identifiers 5 per 7 days 1 every 34 hours Not offered
New certificates per registered domain 50 per 7 days 1 every 202 minutes On request
New orders per account 300 per 3 hours 1 every 36 seconds On request
Authorization failures per identifier per account 5 per hour 1 every 12 minutes Not offered
Consecutive authorization failures per identifier per account 1,152 1 per day; resets on success Unpause via self-service portal
New registrations per IP address 10 per 3 hours 1 every 18 minutes Not offered
New registrations per IPv6 /48 500 per 3 hours 1 every 22 seconds Not offered

1. Duplicate certificates (most common)

  • Confirm: the message says "exact set" of identifiers or domains. Search CT logs for the name; you will see several certificates with identical names issued in the last week.
  • Typical causes: deleting the client's config directory on every deploy, rebuilding containers without a persistent volume for /etc/letsencrypt, or running --force-renewal while testing.
  • Fix: wait for the refill, reuse an existing certificate, and persist the client's state directory.

2. Too many certificates for one registered domain

  • Confirm: the message mentions the registered domain (for example example.com) rather than the exact list of names. This happens when you issue separate certificates for many subdomains.
  • Fix: combine names into fewer certificates (one certificate can hold up to 100 identifiers on the classic profile), use a wildcard certificate through DNS-01, or request an override if you are a hosting provider.

3. Repeated validation failures

  • Confirm: the error mentions failed authorizations. The real problem is validation: see certbot timeout during connect, certbot 403 unauthorized or NXDOMAIN.
  • Fix: fix validation on staging first. If issuance for a name is paused after long-running failures, the error contains a link to the self-service portal where you can unpause it.

4. Too many accounts from one IP

  • Confirm: "too many new registrations". Usually caused by scripts that register a fresh ACME account for each certificate.
  • Fix: register one account and reuse it for all certificates.

Fixes by environment

Every client avoids the limits the same way: keep its state on persistent storage, debug against staging, and never force renewal on a schedule.

Certbot: certbot certificates lists what you already have; certbot renew only renews certificates within the renewal window, so avoid --force-renewal in cron. Persist /etc/letsencrypt in Docker.

acme.sh: keep ~/.acme.sh on a persistent volume; use --staging (or --test) while debugging and remove --force from scheduled jobs.

Kubernetes cert-manager: a Certificate stuck in a failure loop can burn through limits. Use a staging ClusterIssuer until the Certificate becomes Ready; see cert-manager certificate not ready.

Hosting panels and CDNs: many panels request certificates for you. If you also run your own client for the same names, the two may compete and double the number of orders.

Don't do this

  • Revoke and reissue to "reset" the limit. Revocation does not restore capacity.
  • Create new ACME accounts to get around the limit. The domain and duplicate limits are global, and account creation has its own per-IP limit.
  • Switch to an untrusted workaround such as serving a self-signed certificate on production while you wait. Keep the old certificate running instead, or temporarily use another ACME CA your client supports.
  • Keep a broken renewal job running every few minutes. Fix it on staging and schedule renewals once or twice a day.

FAQ

Can Let's Encrypt reset my rate limit?

No. The rate limits page states that there is no way to reset a limit temporarily, and revoking certificates does not give capacity back. Capacity refills automatically over time; the error message tells you when you can retry.

Do renewals count against the limits?

Renewals coordinated through ACME Renewal Info (ARI) are exempt from all rate limits. Older-style renewals, recognised because they request the exact same set of identifiers, are exempt from the New Orders per Account and New Certificates per Registered Domain limits but still count toward the duplicate-certificate and authorization-failure limits.

I hit the 5-per-week duplicate limit and the site is down. What now?

Look for a valid certificate you already have, for example in /etc/letsencrypt/archive/ or a backup, and install it. Otherwise change the set of names, for example add www.example.com; that counts as a new order and is subject to the per-account and per-domain limits instead. Use CT search to see which certificates were issued.

Are the staging limits higher?

Yes. Let's Encrypt describes the staging environment as having significantly higher limits and recommends it for development and troubleshooting. Staging certificates are not trusted by browsers, so switch back to production once everything works.

Sources

  1. Let's Encrypt: Rate Limits
  2. Let's Encrypt: Staging Environment
  3. Let's Encrypt: Integration Guide
  4. Certbot User Guide