Skip to content

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.

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

  1. Test with dry-run first to avoid consuming rate limits
  2. Use staging environment during development and troubleshooting
  3. Implement exponential backoff when hitting rate limits
  4. Monitor certificate issuance via Certificate Transparency logs (crt.sh)
  5. 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