Interactive Troubleshooter

Published: Sep 17, 2026

Let's Encrypt Rate Limit Hit: Bypass and Wait Strategy

Time: 15 mins Level: Beginner

By StepDiag Engineering Team

Reviewed by Ibraheem Taofeeq Opeyemi

Exhaustive diagnostic and mitigation guide for resolving Let's Encrypt ACME API rate limits. Learn the root causes behind certificate issuance throttling and step-by-step technical strategies to bypass limits or optimize renewal pipelines.

Full Diagnostic Tree & Step-by-Step Overview

Which specific Let's Encrypt ACME rate limit error message or HTTP 429 response are you encountering?

too many certificates already issued for exact set of domains
too many certificates already issued for exact registered domain
too many failed authorizations recently
too many pending authorizations / new orders per account

Select your deployment architecture for duplicate certificate issuance mitigation:

Single server deployment requiring immediate valid SSL certificate
Multi-server / load-balanced cluster where certs were re-requested per node
Automated deployment pipeline continuously requesting identical certs in CI/CD

Bypass Duplicate Certificate Limit via Subject Alternative Name (SAN) Expansion

Solution:

Root Cause: Duplicate Certificate Limit (5 per week)

You hit the Duplicate Certificate limit, which caps identical sets of hostnames (Subject Alternative Names) to 5 certificates per 7-day rolling window. This typically occurs when deployment scripts trigger repeated requests without storing or re-using existing keys/certificates stored in /etc/letsencrypt/live/.

# Diagnostic Verification:

Review the ACME response headers or Certbot output for HTTP status 429 Too Many Requests containing:

text
urn:ietf:params:acme:error:rateLimited :: too many certificates already issued for exact set of domains: example.com, [www.example.com](https://www.example.com)

Check your certificate history via crt.sh Domain Search by searching for your registered domain (example.com).

# Step-by-Step Fix:

1. Expand Subject Alternative Names (SAN) to Break Exact Match:

Adding a new, dummy, or unused subdomain creates a unique hostname set, immediately bypassing the duplicate set limit.

Execute via Certbot:

bash
certbot certonly --standalone -d example.com -d [www.example.com](https://www.example.com) -d bypass.example.com

2. Recover Existing Certificates from Local Storage:

Check if previously issued certs exist locally before requesting new ones:

bash
certbot certificates
ls -la /etc/letsencrypt/archive/[example.com/](https://example.com/)

Point your web server (Nginx/Apache) directly to existing active keys instead of requesting new ones.

3. Use ZeroSSL or Buypass ACME Endpoints as Immediate Failover:

If domain expansion is not feasible, switch your ACME client endpoint to an alternative free CA:

bash
certbot certonly --server [https://acme.zerossl.com/v2/DV90](https://acme.zerossl.com/v2/DV90) -d example.com -d [www.example.com](https://www.example.com)

# Prevention & Long-Term Monitoring:

Implement central certificate storage or sync certs across environments using toolings like HashiCorp Vault or cert-manager.

Ensure renewal cron scripts execute certbot renew instead of certbot certonly, as renew checks expiration before issuing requests.

Cluster Certificate Distribution & Duplicate Limit Recovery

Solution:

Root Cause: Independent Node Certificate Requests in Load-Balanced Clusters

Each node in your high-availability cluster independently ran an ACME client challenge for example.com. Because each node generated a new private key and requested an identical certificate, the cluster quickly consumed the limit of 5 duplicate certificates per week.

# Diagnostic Verification:

Inspect syslog/journalctl across cluster nodes for simultaneous ACME issuance requests:

bash
journalctl -u certbot.service -u nginx.service --since "24 hours ago" | grep -i "rateLimited"

# Step-by-Step Fix:

1. Centralize Certificate Issuance (Primary Node Architecture):

Designate a single primary node or bastion to execute ACME renewals.

Deploy certs to edge nodes via rsync or automated deployment hooks:

bash
# /etc/letsencrypt/renewal-hooks/deploy/cluster-sync.sh
#!/bin/bash
rsync -avz /etc/letsencrypt/live/[example.com/](https://example.com/) worker-node1:/etc/ssl/letsencrypt/
rsync -avz /etc/letsencrypt/live/[example.com/](https://example.com/) worker-node2:/etc/ssl/letsencrypt/
ssh worker-node1 "systemctl reload nginx"
ssh worker-node2 "systemctl reload nginx"

2. Temporary Mitigation via Shared Domain Alias:

Temporarily add an additional node-specific subdomain to break the duplicate matching constraint:

bash
certbot certonly --webroot -w /var/www/html -d example.com -d node1.example.com

# Prevention & Long-Term Monitoring:

Use cloud-native ingress controllers (e.g., Kubernetes cert-manager with ClusterIssuer) to handle single-point ACME validation and secret propagation.

CI/CD Pipeline Ephemeral Container Rate Limit Prevention

Solution:

Root Cause: Ephemeral Container Environments Requesting Production Certificates

CI/CD pipelines or staging builds spinning up temporary environments (Docker/Kubernetes) requested production Let's Encrypt certificates on every build step without persisting state, hitting the 5-certificate duplicate threshold within hours.

# Diagnostic Verification:

Examine CI build logs for repeated ACME challenge calls to https://acme-v02.api.letsencrypt.org/directory during pipeline runs.

# Step-by-Step Fix:

1. Switch CI/CD Environments to Let's Encrypt Staging Server:

Update ACME client flags in build scripts to use the Staging ACME endpoint:

bash
certbot certonly --dry-run --server [https://acme-staging-v02.api.letsencrypt.org/directory](https://acme-staging-v02.api.letsencrypt.org/directory) -d test.example.com

2. Inject Self-Signed Certificates for Internal Integration Tests:

Replace ACME issuance in non-production pipeline runs with OpenSSL ephemerals:

bash
openssl req -x509 -nodes -days 1 -newkey rsa:2048 -keyout /tmp/tls.key -out /tmp/tls.crt -subj "/CN=example.com"

# Prevention & Long-Term Monitoring:

Restrict production Let's Encrypt API keys and production ACME issuance targets exclusively to main branch deployment stages.

Select your domain architecture for Registered Domain (50 per week) limit resolution:

SaaS / Multi-Tenant Platform issuing individual certificates per customer subdomain
Single enterprise infrastructure reaching 50 individual subdomains limit
Public dynamic DNS provider or shared domain space (e.g., github.io, cloudflare worker)

Multi-Tenant & SaaS Subdomain Consolidation via Wildcard Certificates

Solution:

Root Cause: Certificates Per Registered Domain Limit (50 per week)

Your application issues separate SSL certificates for every tenant (tenant1.example.com, tenant2.example.com). Let's Encrypt caps total certificates per Registered Domain (e.g., example.com) to 50 per 7-day period.

# Diagnostic Verification:

Error payload returns:

text
urn:ietf:params:acme:error:rateLimited :: too many certificates already issued for exact registered domain: example.com

# Step-by-Step Fix:

1. Consolidate Subdomains into a Wildcard Certificate (*.example.com):

A single wildcard certificate supports unlimited first-level subdomains while consuming only 1 slot against the 50-cert limit.

Wildcard certificates require DNS-01 challenge validation:

bash
certbot certonly --manual --preferred-challenges dns -d "*.example.com" -d "example.com"

2. Automate DNS-01 via DNS Provider Plugins:

Use native Cloudflare, Route53, or DigitalOcean plugins to automatically update TXT records (_acme-challenge.example.com):

bash
certbot certonly --dns-cloudflare --dns-cloudflare-credentials /etc/letsencrypt/cloudflare.ini -d "*.example.com"

3. Apply for Rate Limit Exemption (For Large SaaS Platforms):

If multi-tenancy requires custom subdomains across thousands of clients, submit an official Let's Encrypt Rate Limit Exemption Request.

# Prevention & Long-Term Monitoring:

Group multiple subdomains (up to 100 per cert) into single SAN certificates rather than requesting 1 cert per subdomain.

Enterprise Subdomain Grouping & SAN Combination

Solution:

Root Cause: Fragmented Certificate Issuance Across Subdomains

Your organization requests separate certificates for every internal microservice (api.example.com, app.example.com, auth.example.com), exhausting the 50-cert limit for example.com.

# Diagnostic Verification:

Verify the total count of certificates issued in the last 7 days using the Let's Encrypt Public Logs via terminal:

bash
curl -s "[https://crt.sh/?q=%.example.com&output=json](https://crt.sh/?q=%.example.com&output=json)" | jq -r '.[].name_value' | sort -u | wc -l

# Step-by-Step Fix:

1. Combine Subdomains into Multi-Domain SAN Certificates:

Bundle up to 100 subdomains onto a single SSL certificate:

bash
certbot certonly --webroot -w /var/www/html -d api.example.com -d app.example.com -d auth.example.com -d mail.example.com

2. Migrate Non-Production Subdomains to Secondary Domain:

Move dev/staging environments to a separate registered TLD (e.g., example-dev.com) to preserve production allocation limits on example.com.

# Prevention & Long-Term Monitoring:

Audit domain provisioning scripts to prevent automated microservice bootstrap routines from creating independent certificate instances.

Public Suffix List (PSL) Registration for Shared Domains

Solution:

Root Cause: Shared Registered Domain Throttling

If you provide hosting under a shared top-level domain (e.g., myplatform.com where users get user.myplatform.com), all user requests aggregate against your single root domain limit of 50 certs/week.

# Diagnostic Verification:

Review ACME error messages confirming rate exhaustion on shared domain sub-allocations.

# Step-by-Step Fix:

1. Submit Domain to Public Suffix List (PSL):

Submitting myplatform.com to the Public Suffix List causes ACME CAs (and browsers) to treat user.myplatform.com as an independent eTLD+1 domain.

Submit a Pull Request to the official Public Suffix List GitHub repository.

Once merged, Let's Encrypt treats each user subdomain as a separate registered domain, unlocking 50 certificates per user subdomain per week.

2. Immediate Workaround:

Switch affected subdomains to alternative free certificate providers (e.g., ZeroSSL, Google Trust Services) via ACME clients like acme.sh:

bash
acme.sh --issue --server zerossl -d user1.myplatform.com -w /var/www/html

# Prevention & Long-Term Monitoring:

Monitor PSL pull request status and update ACME deployment nodes upon propagation.

Select the primary failure mechanism triggering authorization limits:

HTTP-01 challenge fails due to firewall, CAA, or web server misconfiguration
DNS-01 challenge fails due to propagation delay or missing API credentials

HTTP-01 Authorization Failure Cleanup & Validation Fix

Solution:

Root Cause: Failed Authorizations Limit (5 failures per account per hour)

You received HTTP 429 after 5 failed ACME challenge validations within 1 hour. This occurs when the Let's Encrypt validation server cannot reach http://<your-domain>/.well-known/acme-challenge/<TOKEN> due to closed port 80, misconfigured web server routing, or aggressive WAF rules.

# Diagnostic Verification:

Check Certbot validation logs (/var/log/letsencrypt/letsencrypt.log) for:

text
urn:ietf:params:acme:error:rateLimited :: Too many failed authorizations recently

Test external accessibility of the challenge path manually:

bash
curl -I [http://example.com/.well-known/acme-challenge/test-file](http://example.com/.well-known/acme-challenge/test-file)

# Step-by-Step Fix:

1. Clear Pending ACME Account Failures by Switching to Dry-Run Staging:

Do NOT continue testing against production while locked out. Test validation using the staging flag:

bash
certbot renew --dry-run

2. Fix Port 80 Routing and Firewall Settings:

Ensure firewall permits inbound TCP on Port 80:

bash
ufw allow 80/tcp
iptables -A INPUT -p tcp --dport 80 -j ACCEPT

3. Configure Direct Nginx Webroot Pass-through:

Add an explicit location block in your Nginx configuration to serve challenges directly:

nginx
location /.well-known/acme-challenge/ {
    root /var/www/html;
    allow all;
}

4. Wait Out the 1-Hour Rolling Window:

The Failed Authorizations limit expires automatically 1 hour after the first failure. Once --dry-run succeeds, wait for the window to expire and run the production request.

# Prevention & Long-Term Monitoring:

Always test setup changes using --dry-run or staging endpoints before running production issuance commands.

DNS-01 Propagation Delay & Challenge Timeout Mitigation

Solution:

Root Cause: DNS TXT Record Propagation Timeouts

When attempting DNS-01 challenges, the ACME server queried your authoritative nameservers before the _acme-challenge TXT record propagated fully across public DNS, resulting in 5 consecutive validation failures.

# Diagnostic Verification:

Verify DNS propagation timing using dig prior to letting ACME validate:

bash
dig +short TXT _acme-challenge.example.com @8.8.8.8

# Step-by-Step Fix:

1. Increase Propagation Wait Time in ACME Client:

Instruct Certbot to pause and wait for DNS synchronization before notifying ACME server:

bash
certbot certonly --dns-cloudflare --dns-cloudflare-credentials /etc/letsencrypt/cloudflare.ini --dns-cloudflare-propagation-seconds 60 -d example.com

2. Verify Correct DNS API Credentials:

Ensure API tokens have permission to write and purge TXT records in target zone files.

# Prevention & Long-Term Monitoring:

Use native DNS plugin extensions rather than manual hook scripts to guarantee automated propagation checks.

Select your pending authorization error scenario:

Account reached 300 pending authorizations limit
Overall New Orders rate limit hit across account (300 per 3 hours)

ACME Account Pending Authorizations Deactivation

Solution:

Root Cause: Accumulation of 300 Unfulfilled Pending Authorizations

An ACME client created hundreds of domain validation orders without completing or deactivating them. Let's Encrypt caps open pending authorizations to 300 per account.

# Diagnostic Verification:

Error payload displays:

text
urn:ietf:params:acme:error:rateLimited :: too many currently pending authorizations

# Step-by-Step Fix:

1. Deactivate Pending Orders via ACME Scripting or ACME Client Cleanup:

Using acme.sh, clear account state and pending authorizations:

bash
acme.sh --deactivate-account

2. Force ACME Account Registration Reset in Certbot:

bash
certbot register --update-registration --email newadmin@example.com

# Prevention & Long-Term Monitoring:

Fix underlying script loops to ensure failed authorization attempts call explicit order cancellation routines.

Account New Orders Throttling and Backoff Setup

Solution:

Root Cause: Exceeded New Orders Account Threshold (300 orders per 3 hours)

Automated provisioning scripts submitted excessive new certificate order requests within a 3-hour window, triggering account-level API throttling.

# Diagnostic Verification:

Review HTTP 429 response body indicating too many new orders for account URL.

# Step-by-Step Fix:

1. Implement Exponential Backoff in Custom ACME Integrations:

Pause all automated certificate generation scripts for a minimum of 3 hours.

2. Batch Multiple Domain Names Into Single Orders:

Modify order architecture to group multiple hostnames into single multi-SAN orders, reducing total order count.

# Prevention & Long-Term Monitoring:

Implement rate-limiting middleware in internal automation queues to limit outbound ACME order creation to under 100 requests per hour.

Related Diagnostic Guides

Proxmox VM 100% IO Delay: ZFS and Disk Diagnostic

Node.js ERR_MODULE_NOT_FOUND After Move to ESM

Python Virtual Environment Broken After Python Upgrade

Docker Build Context Too Large: .dockerignore Diagnostic

VS Code Remote SSH Keeps Disconnecting: KeepAlive Fix

Subscribe to StepDiag

Embed Guide on Your Website