Too Many Certificates Already Issued for Exact Set of Domains

Your renewal fails, and the log shows this.

Error creating new order :: too many certificates already issued for exact set of domains: example.com,www.example.com: see https://letsencrypt.org/docs/rate-limits/

This shows up right after certificates started getting shorter across the board, and I do not think that is a coincidence. As renewals run more often, a small automation bug that used to fire once every few months on a 90-day schedule can now fire several times a week. That is exactly the pattern that trips this limit. If you missed it, I covered the shorter lifetime change itself in this earlier post.

What this error actually means

Let's Encrypt runs several separate rate limits, and this error message only tells you which one you hit, not why. For most self-hosted setups, the one behind this specific message is the Duplicate Certificate limit. According to Let's Encrypt's own rate limits documentation, you can request a maximum of 5 certificates for the exact same set of domain names within a rolling 7 day window. That limit is global. It applies across every ACME account, not just yours.

This is different from a second, larger limit called Certificates per Registered Domain, which allows up to 50 certificates per week for a domain overall. Renewals are meant to be exempt from that larger limit specifically, since Let's Encrypt says plainly that they designed their limits so that "renewing a certificate almost never hits a rate limit." But renewals still count against the smaller 5-per-week duplicate limit, and that is the one people usually hit by accident.

The real causes, and why they get worse now

Three things cause this far more often than a genuine traffic spike or a one-time mistake.

• A --force-renewal flag left in a cron job. This flag renews unconditionally every single time the job runs, whether the certificate actually needs it or not. On a 90-day certificate, a careless weekly cron job with this flag might have gotten away with it for a while. As certificate lifetimes shrink toward 45 days or less, that same cron job runs more often relative to the certificate's real lifespan, and burns through your 5 weekly slots much faster.
• Duplicate automation running from more than one place. This is common on self-hosted setups where more than one tool tries to manage the same certificate. A reverse proxy with its own built-in ACME client, plus a separate Certbot cron job on the host, plus maybe a Docker container also trying to issue for the same domain, all count against the same global limit.
• A broken retry loop after a failed renewal. If your renewal script retries immediately on any failure instead of waiting, a single unrelated problem, like a brief DNS hiccup, can turn into five wasted attempts in an afternoon.

What does not fix this, even though it feels like it should

Some common advice for this error actively makes things worse, so let me be direct about it. Switching from Certbot to a different ACME client like acme.sh does not reset anything. The limit is enforced against the exact set of domain names you are requesting, not against your account or your specific software. A new client hits the exact same wall.

Deleting your existing certificate directory to "start clean" is worse, not better. Doing this throws away your account key and your working certificate, and does not touch the server-side counter at all. You end up with no valid certificate and the same rate limit still in place, which is a strictly worse position than where you started.

What actually works

First, stop retrying. Every failed attempt from an aggressive retry loop can consume another one of your remaining slots. Let it rest.

Second, check your crontab and any renewal scripts for a stray --force-renewal flag, and remove it. Certbot's normal renewal command already checks whether a certificate actually needs renewing, so forcing it on every run is rarely necessary.

Third, check for duplicate automation. If you run a reverse proxy with built-in ACME support and a separate Certbot setup, pick one and disable the other for that domain.

Fourth, just wait. Let's Encrypt patched this limit in 2022 to use a gradual refill system instead of a flat weekly reset, so the practical wait time after being limited is usually closer to a day and a half, not a full week. Your existing certificate, if you still have one, keeps working while you wait, since it does not get revoked by hitting a rate limit.

The catch: this is a good moment to check your ARI support

If you are still on an older Certbot version without proper Automatic Renewal Information support, treat this as the nudge to finally upgrade. ARI-aware clients renew based on server-provided timing instead of a fixed local schedule, which naturally avoids a lot of the unnecessary duplicate renewal attempts that cause this error in the first place.

FAQ

Will this rate limit affect my currently running site?
No, not directly. Your existing valid certificate keeps working. The rate limit only blocks new issuance for that exact set of domains until it resets.

Does using the Let's Encrypt staging environment help me avoid this?
For testing, yes. Let's Encrypt provides a separate staging environment with much higher limits specifically so you can test configuration changes without touching your real production limits. Use it any time you are debugging renewal logic rather than testing against the live environment.

If I add or remove one subdomain from my certificate, does that reset the limit?
Yes, in a sense. The duplicate limit is keyed to the exact set of names in the request. A certificate for example.com and www.example.com is a different bucket from just example.com alone, so changing the exact set of domains gives you a fresh counter for that new combination, though I would not treat this as a real workaround since it just moves the problem.

Can I ask Let's Encrypt to manually reset my limit?
Generally no for small sites. Let's Encrypt states plainly that rate limits cannot be manually cleared on request. There is a separate process for large hosting providers who need permanently higher limits, but that is not meant for an individual site working through a temporary mistake.

How do I know exactly when I can try again?
Let's Encrypt includes a Retry-After value in the error response itself, which tells you the specific time your next attempt is likely to succeed, so check your client's full error output rather than guessing.

Bottom line

This error almost always comes from something retrying too often, not from a real traffic problem. Stop the retries, remove any forced renewal flags, check for duplicate automation, and give it a day or two. As certificates get shorter across the board, this exact mistake is going to show up more often for people who never had a renewal problem before, simply because their automation now runs on a tighter schedule than it was built for.

Sources: Let's Encrypt, Rate Limits documentation; Let's Encrypt, Scaling Our Rate Limits to Prepare for a Billion Active Certificates. Verified against Let's Encrypt's own documentation on August 30, 2026.