Let's Encrypt is moving default certificate lifetime from 90 days to 64, then to 45, over the next two years — and by their own account, this will roughly double the number of certificate renewal requests each day. A limit that rarely mattered at a 90-day cadence gets hit twice as often at 45. Here's which specific limit you actually run into, why, how long until it clears, and the one mechanism that sidesteps the whole problem for most automated setups.
Which limit did you actually hit
| Limit | Threshold | What triggers it | Reset |
|---|---|---|---|
| Duplicate Certificate | 5 per exact set of domain names | Reissuing a cert for the identical set of names too many times in a short window — common with a retry loop or a broken renewal cron firing repeatedly | Rolling 168-hour window, not a hard weekly reset — the oldest issuance ages out first |
| Certificates per Registered Domain | 50 per week | Issuing many distinct certificates (different subdomain sets) under one registered domain — common when spinning up many customer or preview subdomains | Rolling 168-hour window |
| New Orders per Account | 300 per 3 hours | High-volume automation hitting the ACME API directly — usually a bug (a loop, a misconfigured batch job) rather than legitimate volume | Rolling 3-hour window |
The error message tells you which one. "Too many certificates already issued for exact set of domains" is the Duplicate Certificate limit — almost always a retry loop reissuing for names that haven't changed. An error mentioning the registered domain broadly, not an exact set, is the per-domain limit. An error at the order-creation step, before any names are even validated, is the per-account order limit.
Why 2026 makes this more likely, not less
The lifetime shortening is real and already announced. Let's Encrypt has confirmed the 90-to-64-to-45-day transition and stated that subscribers don't need to change their own rate-limit configuration — the limits themselves aren't moving. What changes is how often a normal renewal cycle brushes up against them: a 45-day cert renews roughly every 30 days instead of every 60, so a fleet issuing certs for many subdomains — or a retry loop that used to have two months to go unnoticed before hitting the Duplicate Certificate limit — now has about half that.
This isn't hypothetical. On May 8, 2026, Let's Encrypt halted all certificate issuance for roughly two and a half hours after a cross-signed root certificate turned out to be missing required fields. Let's Encrypt's own status page confirmed the rollback and fix. Issuance itself isn't infallible — which is exactly why a retry storm colliding with a shortened renewal cycle is worth planning for rather than discovering during an outage.
The mechanism most automation already has
Renewals recognized through ACME Renewal Information (ARI) are exempt from rate limits entirely, regardless of how short the certificate lifetime gets. A client that supports ARI checks with Let's Encrypt for the actual optimal renewal window rather than guessing off the raw expiry date, and a renewal made through that path doesn't count against the Duplicate Certificate or per-domain limits the way a manually triggered reissue does. The short version: confirm the ACME client in use actually supports ARI (recent certbot and most modern clients do) before assuming rate limits are a real constraint on renewal.
What to actually do at each limit
- Hit the Duplicate Certificate limit: stop retrying immediately — this is the mistake that makes it worse. A script that reissues on every failure eats through the 5-per-168-hour budget in minutes, turning a transient error into a genuine outage of your own making. Check whether the ACME client supports and is using ARI; if not, wait out the rolling window and fix whatever's triggering the retries (a misfiring cron, a webhook firing twice) before it clears
- Hit the per-registered-domain limit: usually genuine high subdomain issuance volume — multi-tenant SaaS onboarding customers with their own subdomains, or a CI pipeline spinning up preview environments faster than certs can be issued. A wildcard certificate sidesteps repeated per-subdomain issuance entirely, though that trades in a different risk (a single private key covering every subdomain) worth weighing on its own terms
- Hit the per-account order limit: almost always a bug, not real volume — a loop or misfiring batch job creating orders faster than certificates are actually needed, sometimes a deploy pipeline retrying a failed step without backing off. Fix the automation before retrying; raising request volume against the same broken loop doesn't fix it, it just burns the budget faster
- Testing changes to issuance automation: use Let's Encrypt's staging environment, which carries much higher limits specifically so a client integration or renewal script can be run repeatedly while debugging, without touching production quota. Staging certs aren't browser-trusted, so they're useless for a live site — but every experiment run against the real environment instead spends real, limited budget you may need later that same week
WebPixie's Certificates Manager shows every certificate public Certificate Transparency logs have recorded for a domain — useful after a rate-limit-driven retry storm to confirm exactly what was actually issued versus what a script attempted. It reads CT logs; it doesn't issue certificates or manage rate limits itself.
Covered in more detail on the WebPixie blog, including a deeper look at how ACME Renewal Information works as its own monitoring signal.
Top comments (0)