A rollout that requests a separate certificate for every microsite can run into Let’s Encrypt rate limits. Planning certificate groups, validation and retries before launch helps avoid issuance delays.
This guide explains how to plan certificate groups, validation and renewal for many hostnames. It covers SAN and wildcard scope, HTTP-01, DNS-01 and TLS-ALPN-01 prerequisites, staging, DNS timing and recovery from failed requests. It is a design and operations guide, not a client-specific installation procedure. The objective is a traceable workflow that reduces unnecessary issuance while respecting the limits and renewal rules that actually apply to each order.
Let’s Encrypt Rate Limits and Renewal Exemptions
Rate limits have several scopes. A registered domain is identified using the Public Suffix List: app.example.com and api.example.com share example.com, while blog.example.co.uk belongs to example.co.uk. New certificate issuance for the same registered domain shares a global quota across accounts. Separate limits cover account orders, the exact set of identifiers, authorization failures and API traffic. Creating another account or changing a subdomain does not reset a global registered-domain quota.
On the official page checked on 3 November 2026, the main limits are 300 new orders per account per 3 hours, 50 new certificates per registered domain per 7 days, 5 certificates per exact set of identifiers per 7 days, and 5 authorization failures per identifier per account per hour. These use token buckets that refill over time, not a calendar-week reset. Renewal exemptions matter: do not apply a simple certificate-count calculation without distinguishing new issuance, changed name sets and qualifying renewals.
The official Let’s Encrypt rate-limits page defines current values, refill rates and exemptions. ARI-coordinated renewals are exempt from all rate limits when the order explicitly replaces an eligible certificate, includes at least one matching identifier and the old certificate has not already been replaced using ARI. Non-ARI renewal recognition uses the exact same identifier set, ignoring order and capitalization: it exempts new-order and registered-domain limits, while exact-set and authorization-failure limits still apply. Confirm what your client version actually supports.
SAN and Wildcard Certificate Scope
Certificate grouping changes both the number of records to manage and the scope of each private key. For example, a platform onboarding a hundred partner subdomains can compare individual certificates, smaller SAN groups and a wildcard for matching dynamic names. Estimate initial issuance, later name-set changes and renewal work for each option. A lower certificate count may simplify operations, but the chosen scope must also fit ownership boundaries and the applicable rate-limit budget.
A SAN certificate lists the hostnames it authenticates, such as app.example.com, api.example.com and billing.example.com. Let’s Encrypt allows up to 100 identifiers depending on the selected certificate profile; the maximum is not a recommended target for every certificate. A wildcard such as *.example.com matches one complete label: it covers app.example.com, but neither example.com nor app.eu.example.com. Add the apex separately when required. For Let’s Encrypt, wildcard issuance requires DNS-01; HTTP-01 and TLS-ALPN-01 cannot validate wildcard names.
Large SAN lists produce larger certificates and bind more names to one renewal and deployment operation. A shared wildcard key can authenticate every name within its actual scope, increasing the consequences of unauthorized key access. Splitting by ownership, deployment target and lifecycle can reduce coupling, but adds certificate records to manage. Keep tenant and administrative boundaries in the design. Several wildcards under one registered domain still share applicable issuance limits; they do not create independent global quotas.
Keep SAN groups deliberate. Adding or removing names can create a different identifier set and change the renewal exemption that applies. Group stable services with compatible ownership and deployment schedules; use a wildcard only when its one-label coverage and key-sharing model fit. A new hostname already covered by a valid wildcard does not by itself require reissuance. Record why names share a certificate so later changes do not turn the group into an accidental dependency between unrelated services.
Choosing an ACME Challenge
HTTP-01 validates the response at http://HOST/.well-known/acme-challenge/TOKEN and begins on publicly reachable port 80. Let’s Encrypt permits only supported HTTP/HTTPS redirects to ports 80 or 443, with a redirect-depth limit; serving HTTPS on 443 does not replace the initial port-80 requirement. Every possible frontend must return the correct content or use a supported redirect to the validation service. Check CDN caching, WAF rules, authentication and application rewrites along that path. This method cannot issue a wildcard certificate.
DNS-01 publishes the required TXT value at the challenge name. It supports wildcard issuance and servers whose application ports are not public. Automate updates with narrowly scoped DNS credentials or a separate validation service. Check the provider’s completion signal and all relevant authoritative servers before requesting validation. Queries from a few locations help diagnose readiness, but anycast and caching mean they cannot guarantee what every CA validator will observe. The provider’s own update propagation and recursive cache lifetime are separate timing factors.
TLS-ALPN-01 uses port 443 with challenge-specific ALPN handling and a special validation response. Ordinary HTTPS support alone is insufficient: the ACME client and the component terminating TLS must support the challenge, and all applicable frontends must answer correctly. It cannot validate wildcard names. Use it where the TLS path can be controlled and tested; do not choose it merely because port 443 already serves a website. A CDN that terminates TLS may prevent the origin from handling this exchange.
Compare the official challenge requirements with the actual network path. HTTP-01 needs inbound port 80 and consistent frontend responses; DNS-01 needs safe DNS automation and time for published data to become observable; TLS-ALPN-01 needs a supported TLS validation listener. ACME clients also need outbound HTTPS connectivity, while authoritative DNS must be reachable for DNS queries. Select and rehearse the method before scheduling a large production batch.
Separating Staging and Production
Use Let’s Encrypt’s staging environment to test issuance without consuming production issuance quotas. Staging has its own limits, ACME endpoint and environment-scoped account. Its certificates are not trusted by normal browsers or clients. Keep test output and deployment destinations separate so a successful rehearsal cannot overwrite a public server’s trusted certificate. Do not add staging roots or intermediates to a trust store used for ordinary browsing or production traffic.
A production-like staging rehearsal can exercise concurrent orders, jittered retries and health checks that toggle traffic before switching issuance to production. It can expose issues such as a backend not serving the challenge path or a DNS zone that fails to update. It will not catch every production surprise.
The staging documentation describes the endpoint and client options. Test initial issuance, renewal, failed validation, retries, concurrent TXT handling and controlled deployment using production-like settings. When moving to production, explicitly select the correct CA endpoint, account, credentials and deployment destination. Staging success does not prove that a production quota is available, that all public clients trust the production chain or that production traffic will be unaffected.
Planning Issuance and Renewal
Maintain an inventory of certificate ownership, registered domains, identifier sets, key types and deployment targets. Mark an operation as new issuance, a name-set change or an eligible renewal, then calculate the relevant limits. A controller should retain successful and failed operation state so a restart does not start a duplicate order. Plan a small initial batch and expand only after validation, certificate storage, server reload and application checks have succeeded.
Group hostnames by lifecycle and administrative responsibility. Stable core services can share a SAN certificate when their owners accept coupled renewal and deployment. Dynamic hostnames may fit a wildcard, but different nesting levels need their own matching coverage. Splitting customer, internal and development scopes may improve isolation; avoid distributing one private key to systems that should not share that authority. Each resulting record still needs monitoring, durable storage and a clear renewal owner.
For DNS-01, distinguish two mechanisms. A CNAME at a challenge name directs TXT lookup to another name; NS records delegate a challenge subzone to authoritative nameservers. Let’s Encrypt can follow either arrangement, but an ACME client does not automatically gain permission or plugin support to write the target zone. Configure and test that separately, using limited credentials. The DNS automation and deployment guide provides wider infrastructure context; its tooling is optional and does not replace client-specific challenge configuration.
Use an ARI-capable client to follow the CA’s suggested renewal window, with randomized scheduling and small batches. Verify both ARI polling and replacement-order support in the installed version; the client’s name alone is not proof. Without ARI, base the schedule on each certificate’s actual validity period. Let’s Encrypt recommends the remaining third of lifetime as a fallback, or halfway through for certificates valid for less than 10 days. Do not assume every certificate lasts 90 days or always renew exactly 30 days before expiry.
On failure, record the ACME error type, affected identifier or set, and Retry-After guidance. Diagnose DNS publication, authorization, network access or application routing before repeating validation. Use bounded exponential backoff and jitter for transient errors, while honoring the server’s earliest retry time. Keep diagnostic identifiers and sanitized error details, but never log account keys, certificate private keys or DNS API secrets. An automatic retry should not erase the evidence needed to explain the failure.
Keep account and certificate state in durable storage across deployments. Account layout is an isolation decision: Let’s Encrypt generally recommends a well-protected shared account for large hosting integrations, while separate accounts can serve particular customer or security boundaries. A new account per process restart fragments state and can hit registration limits without escaping global certificate limits. Staging and production have separate accounts. Distinguish account keys from certificate private keys and protect both according to their authority.
Validation Failures and Recovery
These pitfalls can disrupt validation and renewal; here’s how to address them:
For HTTP-01 behind a CDN or WAF, verify the exact challenge path from external networks over port 80. Avoid cached error responses, login redirects and application rewrites that replace the token response. Apply a narrowly scoped exception or supported central-validation redirect rather than disabling protection for the whole site. Check every possible frontend. Let’s Encrypt does not publish a fixed validator IP list, so allowing only a few observed addresses is not a durable validation policy.
For DNS-01, publishing through an API and reaching every authoritative serving location may take time. Check provider status and poll the relevant authoritative servers, then allow the documented propagation interval before validation. Lowering a TXT TTL does not accelerate the provider’s internal rollout. It also does not shorten the remaining lifetime of answers already cached with an older TTL. A successful query from your location is evidence about that response, not a guarantee of immediate global visibility.
A large SAN group reduces the number of certificate records but increases certificate size and links the names to one issuance/deployment operation. Whether the size materially affects connections depends on the network and workload. Split groups when ownership, renewal cadence or deployment requirements diverge, and include all necessary names in each replacement. Recalculate quota use before changing the layout: moving a name creates new identifier sets, and a group restructure is not automatically an exempt renewal.
Protect wildcard keys according to their full one-label scope. Separate keys and smaller groups can reduce shared authority where teams or tenants need isolation. Restrict file and secret-store access, protect backups and test recovery. If RSA and ECDSA certificates are both served, maintain and monitor their separate keys, certificate records and deployment results. One successfully renewed certificate does not prove the other path is valid or that the server has loaded both replacements.
Duplicate certificate limit traps: Repeatedly reissuing the same exact set of SANs can hit issuance limits. Before an emergency replacement, consult Let’s Encrypt’s current rate-limit and renewal guidance. Don’t add an unrelated temporary name merely to sidestep a limit; plan replacement and revocation of a compromised certificate together.
Resolve HTTP challenge conflicts in the component actually serving the request. A framework’s front controller, an authentication layer or a cache may intercept /.well-known/acme-challenge/. Use the client’s documented webroot or server integration and verify the resulting route before notifying the CA. Generic advice to add a “higher priority” location is insufficient across different servers. DNS-01 or TLS-ALPN-01 can be alternatives only after their separate credential, network and client prerequisites are met.
Monitoring and Key Management
Monitor expiration, expected renewal time, last successful deployment, issuance volume and validation errors. Choose alert thresholds relative to actual certificate lifetime and the retry budget: fixed alerts at 21 or 7 days are unsuitable for some short-lived profiles. Distinguish a certificate obtained by the client from a certificate presented by the live service. Check new connections after deployment and include hostname, chain and application health in the result. Investigate failures while there is still time for a controlled retry.
Issuance volume is a great early warning for bad deploys. If you normally renew 5–10 certs a day and suddenly see 200, something changed—maybe a script now reissues on every container restart, or a SAN edit triggers frequent reorders. Investigating that spike promptly can help prevent further unnecessary issuance.
Before loading a replacement, verify its key match, required SANs, validity and CA-provided chain. Run the server’s supported configuration test, perform a controlled reload and probe new connections; a file update alone does not prove deployment. With dual RSA/ECDSA certificates, test both authentication paths and representative clients. Actual certificate selection depends on client support, the chain and server configuration, so “modern clients always choose ECDSA” and universal performance gains are not safe assumptions.
Coordinating Concurrent ACME Operations
An autoscaling deployment can create duplicate orders when every restarted instance independently requests a certificate. Let instances first reuse a valid certificate and key from approved durable storage. When issuance or renewal is needed, assign one coordinator to the certificate record and use a queue with observable states. The coordinator validates, stores the result and starts controlled deployment; it must also preserve failure state and avoid telling frontends to load an unverified or incomplete result.
A central coordinator can own validation and durable certificate storage while frontends consume approved results. Track queued, validating, issued, deployed and failed states so partial completion is visible. Keep the coordinator’s signing, account and DNS authority narrowly scoped and protect distribution to each permitted destination. Centralization reduces duplicate work only when ownership and retry behavior are correct; its own restart and availability need recovery planning. Do not turn a shared certificate store into unrestricted access to every tenant’s private key.
Where a single coordinator is impractical, use a lease or another explicit ownership mechanism for the certificate record being renewed. Other workers should observe the in-progress operation and reuse the result instead of issuing independently. Define lease expiry, crash recovery and how a stale worker is prevented from committing a conflicting result. Persist operation identifiers and existing certificate paths. This is an architectural recommendation to test in your system, not a guarantee that adding a lock eliminates every concurrency failure.
DNS Caching and Challenge Delegation
Query the required TXT values at the authoritative servers and inspect whether all active challenge values remain present. A wildcard and the apex can need multiple TXT values at the same name during concurrent validation; the existence of another value is not itself an error. Delete only obsolete values owned by completed operations. Replacing the entire RRset or cleaning it indiscriminately can break another in-flight authorization. Keep response size under control and coordinate provider updates so concurrent writers do not overwrite each other.
Plan cache timing before a migration or issuance change. Existing positive answers retain their cached TTL; previously cached NXDOMAIN or NODATA responses can remain until the negative-cache lifetime derived from the zone’s SOA expires. Lowering the new TXT record’s TTL cannot flush those answers. The CA may reach a different anycast instance than your test resolver. Document the provider’s update behavior, the relevant TTLs and the wait/check procedure; never treat a fixed few seconds or two successful resolver queries as proof of universal readiness.
For an NS-based design, _acme-challenge.example.com is a child zone whose NS records name the authoritative servers serving that zone; its TXT data lives in that child zone. A CNAME-based design instead aliases the exact challenge owner to a target name such as a validation name in a separately managed zone. These are distinct configurations, not interchangeable wording. The challenge for app.example.com is _acme-challenge.app.example.com, so delegating _acme-challenge.example.com does not automatically cover every subdomain’s challenge. Verify each required owner, client support and target authority before relying on either mechanism.
When to Change Certificate Groups
Change the layout when repeated name-set edits, ownership changes, excessive shared-key access or coupled deployment failures show that a group no longer fits. There is no universal rule that touching a certificate once a month means it is too busy; certificate profiles and renewal lifetimes differ. Prefer stable identifier sets when practical, while honoring necessary application changes. Keep the renewal schedule tied to ARI and actual validity, not a fixed two-month calendar or an assumed 90-day lifetime.
Before splitting or combining certificates, map every required hostname to its replacement, confirm the responsible owner and identify every deployment target. Evaluate the temporary overlap in issuance and storage, applicable quota use and the rollback conditions. A new team should receive only the key authority it needs. Test a small group first and retain a valid, uncompromised recovery path. Record when old certificate records can be retired so unattended clients do not continue renewing unnecessary names.
Private Key Compromise and Replacement
On suspected private-key compromise, treat replacement and revocation as one incident workflow. Generate a new key, obtain a certificate covering the names the service actually needs, deploy and verify it, and promptly revoke affected certificates through the authorized ACME process. Select the keyCompromise reason when applicable. Do not roll back to an exposed key. Revocation does not refund rate-limit capacity, and renewal does not automatically revoke the old certificate. Rehearse the emergency path during normal operation; do not rely on adding unrelated SANs or delaying containment for a new staging exercise.
Account keys, certificate private keys and DNS credentials have different powers and recovery requirements. Limit who can read or use each one, protect backups and keep auditable issuance/deployment events without recording secrets. Dual RSA/ECDSA service is a compatibility option, not a substitute for that separation. Test both paths against representative clients, monitor both expirations and use the correct issuer chain for each. A valid replacement in storage is not complete until the intended TLS terminator serves it successfully.
Deployment and Renewal Checklist
Use the following sequence as a release checklist, adapting client-specific commands and permissions to the chosen deployment. Each stage should produce an observable result before the next stage starts; a successful ACME order is only one part of successful certificate delivery.
Inventory required names and wildcard coverage; select a supported challenge; rehearse the flow in isolated staging; check current production limits and renewal eligibility; publish all required validation responses; issue in controlled batches; verify key, SANs and chain; persist the certificate and account state; test and reload the service; then confirm the presented certificate and application health. Keep active concurrent TXT values intact, and remove only completed operations’ obsolete values.
For ongoing renewal, follow ARI where supported or schedule against actual certificate validity with enough retry margin. Spread operations with jitter and explicit ownership, retain failure state and honor Retry-After. Watch unexpected issuance spikes and missing deployments. Recover with a known-valid, uncompromised configuration where appropriate, and handle compromise through fresh keys and revocation. Keep account, DNS and certificate permissions documented so an operator can diagnose the failure without broadening access unnecessarily.
Maintaining the Certificate Plan
SAN grouping, wildcard scope and a coordinated ACME workflow can reduce unnecessary certificate requests. They do not guarantee that rate limits will never be reached. Recheck official limits and profile rules before large migrations, distinguish initial issuance from qualifying renewals, and verify changes against real DNS and frontend behavior. Keep the certificate inventory and recovery procedure current as teams, domains, client versions and TLS termination points change.
The operating goal is measurable: every required hostname has a valid certificate at its actual TLS endpoint, renewals occur with enough time to recover, and failed operations can be traced to a responsible owner. Durable state, limited credentials and independent deployment checks support that goal. If the planned workload exceeds an adjustable limit, request an increase with adequate lead time; it is not an immediate reset for an exhausted quota. Continue to use staging for changes while preserving clear production boundaries.
