ACME Rate Limits Explained: Let's Encrypt & CA Throttling Policies

Understanding ACME rate limits. Per-domain, per-account, and per-IP limits for Let’s Encrypt and other CAs with strategies for high-volume certificate issuance. This overview explains how rate limits work, how to stay within them, and how to design automation that scales without hitting throttles.

Rate Limiting: Comprehensive Overview

TL;DR: Let’s Encrypt rate limiting uses token bucket algorithms to control certificate issuance—50 certs per registered domain per 7 days, 300 new orders per account per 3 hours—protecting infrastructure while enabling automated certificate management at scale.

Need help with ACME? Ask Axel Axelspire AI bot with own augmented memory for all ACME/certbot.

Overview

Rate limiting protects Let’s Encrypt infrastructure from overload while ensuring fair resource distribution across millions of users requesting automated certificate issuance. Understanding these limits prevents service disruptions during certificate operations and enables teams to design resilient automation workflows. Production environments must account for rate limiting constraints when implementing certificate lifecycle management at enterprise scale.

The token bucket algorithm provides flexibility for burst traffic patterns common in certificate automation. Organizations can make requests up to the full bucket capacity, with tokens refilling gradually over time. This approach accommodates legitimate use cases like batch renewals while preventing abuse. Rate limit configurations vary by endpoint and operation type, requiring careful planning for high-volume certificate operations.

Enterprise certificate management requires monitoring issuance rates, implementing retry logic with exponential backoff, and using staging environments for testing. ARI (ACME Renewal Info) renewals receive exemptions from all rate limits, making ARI support critical for large-scale deployments. Understanding the distinction between renewable and new certificate requests helps teams optimize their automation strategies.

Let’s Encrypt Rate Limits Quick Reference

Account Registration Limits

Limit	Threshold	Window	Refill Rate
New Registrations per IP Address	10 accounts	3 hours	1 account per 18 minutes
New Registrations per IPv6 Range	500 accounts per /48 subnet	3 hours	1 account per 22 seconds

Note: Overrides are not available for account registration limits.

Certificate Issuance Limits

Limit	Threshold	Window	Refill Rate	Override Available
New Orders per Account	300 orders	3 hours	1 order per 36 seconds	Yes
New Certificates per Registered Domain	50 certificates	7 days	1 certificate per 202 minutes	Yes
New Certificates per Exact Set of Identifiers	5 certificates	7 days	1 certificate per 34 hours	No
Authorization Failures per Identifier per Account	5 failures	1 hour	1 failure per 12 minutes	No
Consecutive Authorization Failures	1,152 failures	Cumulative	1 per day (resets on success)	No

Overall Request Limits (Per IP Per Second)

Endpoint	Requests/Second	Burst Capacity
/acme/new-nonce	20	10
/acme/new-account	5	15
/acme/new-order	300	200
/acme/revoke-cert	10	100
/acme/renewal-info	1000	100
/acme/* (other endpoints)	250	125
/directory	40	40

Architectural Overview

Core Components

Rate Limiting Algorithm

Token Bucket: Let’s Encrypt (Boulder CA) uses this algorithm, allowing burst traffic up to bucket capacity while refilling tokens at a steady rate

Key Concepts

Limits are calculated per request using the token bucket algorithm
Revoking certificates does NOT reset rate limits—the resources used to issue those certificates have already been consumed
Rate limit error messages include a Retry-After header indicating when to retry

Renewal Exemptions

ARI Renewals (ACME Renewal Info)

Renewals coordinated by ARI are exempt from all rate limits
Clients that support ARI periodically check with Let’s Encrypt servers to determine optimal renewal timing
The order must include at least one identifier matching the certificate being replaced

Non-ARI Renewals

Orders with the exact same set of identifiers as an existing certificate are considered renewals
Exempt from: New Orders per Account, New Certificates per Registered Domain
NOT exempt from: Authorization Failures, New Certificates per Exact Set of Identifiers

Quick Start

Development and Testing

Always use the staging environment for testing:

# Use staging server (significantly higher limits)
certbot certonly --staging \
    --webroot -w /var/www/html \
    -d test.example.com

# Only move to production after staging validation
certbot certonly \
    --webroot -w /var/www/html \
    -d example.com

Best Practices

Test with dry-run first to avoid consuming rate limits
Use staging environment during development and troubleshooting
Implement exponential backoff when hitting rate limits
Monitor certificate issuance via Certificate Transparency logs (crt.sh)
Request overrides early if you’re a large hosting provider (takes weeks to process)

Common Pitfalls

Critical Issues to Avoid

1. Consuming Exact Set of Identifiers Limit

Problem: Reinstalling your client or deleting configuration data repeatedly
Impact: Hitting the 5 certificates per exact set per 7 days limit
Prevention: Use staging environment; add/remove identifiers as a workaround

2. Authorization Failure Loops

Problem: Misconfigured DNS or firewall causing repeated validation failures
Impact: 5 failures per hour limit, or eventual pausing after 1,152 consecutive failures
Prevention: Test HTTP-01/TLS-ALPN-01 reachability; verify DNS-01 records carefully

3. Misunderstanding Renewal vs. New Certificate

Problem: Assuming all renewals are exempt from all limits
Impact: Non-ARI renewals still subject to some limits
Prevention: Implement ARI support; maintain exact identifier sets for renewals

4. Not Respecting Retry-After Headers

Problem: Immediately retrying after rate limit errors
Impact: Extended blocking, wasted resources
Prevention: Parse and respect Retry-After headers; implement proper backoff

5. Centralized Infrastructure IP Exhaustion

Problem: All requests from proxy/load balancer counted against single IP
Impact: Unexpected rate limiting in enterprise environments
Prevention: Distribute requests across multiple IPs; implement request queuing

Detailed Implementation Guides

Core Documentation

API Reference - Detailed API documentation including endpoint limits, token bucket implementation, and integration examples
Commands & Usage - Command-line interface reference with practical usage examples and monitoring scripts
Troubleshooting - Error diagnosis and resolution guide covering recovery procedures and workarounds

Requesting an Override

If you are a large hosting provider or organization:

Use the rate limiting form
Processing takes several weeks—not suitable for immediate resets
Overrides available for: New Orders per Account, New Certificates per Registered Domain
Overrides NOT available for: Account registration limits, Exact Set of Identifiers, Authorization Failures

Certificate Lifecycle Management - Automated renewal strategies and lifecycle planning
Certbot Installation - Installing and configuring the Certbot ACME client
HTTP-01 Challenge Overview - Domain validation methods and authorization
DNS-01 Challenge Validation - DNS-based validation for wildcard certificates
ACME Protocol Standards - RFC 8555 ACME protocol specification
Certificate Lifecycle Management - Enterprise deployment patterns