Do certificate renewals count against the rate limit?

Not against the main one. Renewals — a new certificate for the exact same set of hostnames — are exempt from the Certificates per Registered Domain limit (50 per week), which is what lets a domain with hundreds of subdomains keep renewing forever. But renewals are still bounded by the Duplicate Certificate limit: 5 per week for one identical set of names. So legitimate, once-every-60-days renewal never comes close. If you're hitting the wall, something is requesting far more than a real renewal schedule would — and that's the thing to find, not the limit to raise.

How long until the limit resets so I can issue again?

Not a full week, despite what older guides say. In early 2025 Let's Encrypt replaced the fixed weekly window with a token-bucket system that refills continuously. The Duplicate Certificate bucket regains roughly one certificate every 34 hours, so once you're blocked you're typically clear again in a bit over a day, not seven. The catch: if your broken automation keeps firing during that time, it drains the bucket as fast as it refills and you never recover. Stop the loop first, then wait.

Can I just switch to a different domain or subdomain to get around it?

You can, and it's usually the wrong instinct. The Certificates per Registered Domain limit is measured at the registered domain — the Public Suffix List's eTLD+1, so example.com and all its subdomains share one budget. Spraying certificates across sub1, sub2, sub3 to dodge the Duplicate limit just burns the 50-per-week domain limit instead, and leaves you with a pile of near-identical certs that all expire and renew together. The fix is to issue one correct certificate and stop re-issuing it, not to spread the damage.

Views: 9

too many certificates already issued (Let's Encrypt)

'too many certificates already issued'? It's a deploy loop, not renewals. Spot it in CT logs, use staging, wait out the token bucket. Free instant check.

Check your domain for this issue now

Free, no sign-up. Runs the exact check this guide describes and shows what to fix.

Problem

Your deploy went out, and now the certificate step is failing with too many certificates already issued for exact set of domains. Nothing about your domain changed. You didn’t ask for a hundred certificates. And yet Let’s Encrypt is refusing to hand you one more, right when you need it.

The instinct is to treat this as an arbitrary quota you bumped into and to go looking for a way around it. That’s the trap. This error is almost never about you asking for too many certificates on purpose — it’s about something in your setup asking for the same certificate over and over, quietly, on every restart or every deploy, until it exhausted a limit that a normal server hits maybe six times a year. The error is a symptom. The bug is a loop.

Which limit you actually hit

Let’s Encrypt has several rate limits, and the two that trip people are easy to confuse:

Certificates per Registered Domain — 50 per week. This counts every certificate issued for example.com and all its subdomains together, because it’s measured at the registered domain (the Public Suffix List’s eTLD+1). Big deployments with lots of subdomains hit this one.
Duplicate Certificate — 5 per week. This counts certificates for the exact same set of hostnames. Ask for a cert covering example.com, www.example.com six times in a week and the sixth is refused.

The wording tells you which one you’re looking at. too many certificates already issued for exact set of domains is the Duplicate Certificate limit — you asked for the identical certificate too many times. A message about the registered domain is the 50-per-week limit. They have different causes and different fixes, so read the error before you do anything.

Why it’s almost never renewals

Here’s the number that reframes everything: a real certificate renews roughly every 60 days. Even the shorter lifetimes Let’s Encrypt is moving toward — 47-day certs, renewed around the two-thirds mark — put you at maybe a dozen renewals a year for one name. Nothing about a legitimate schedule gets near 5 in a week.

So when you hit the Duplicate limit, the certificate isn’t renewing. It’s being re-issued, and something is doing it in a tight loop. The usual suspects:

A container or pod that requests a fresh certificate on every start instead of persisting /etc/letsencrypt (or its ACME state) to a volume. Crash-loop or scale up and down a few times and you’ve issued five identical certs before lunch.
A CI/CD pipeline that runs certbot as part of every deploy, treating “get a certificate” as an idempotent build step when it’s a rate-limited network call.
Multiple servers or a misconfigured cluster all requesting the same certificate independently, none of them sharing storage, each convinced it needs its own copy.
An automation retry that doesn’t back off — the request fails for an unrelated reason, the script retries immediately, and each attempt that reaches issuance spends a token.

The common thread is that certificates are being thrown away and re-requested instead of stored and reused. Fix the storage, and the rate limit stops being a problem you ever see.

The token bucket: you don’t wait a full week

A lot of advice still says “wait seven days for the limit to reset.” That stopped being true in early 2025, when Let’s Encrypt replaced the rigid weekly window with a token-bucket model. Capacity now refills continuously instead of resetting all at once: the Duplicate Certificate bucket earns back roughly one certificate every 34 hours, so after you hit the wall you’re usually able to issue again in a bit over a day.

But the bucket only refills if you stop draining it. If your broken loop keeps firing while you wait, it grabs each token the moment it appears and you stay blocked indefinitely. The order matters: stop the automation, then wait. Watching the clock while the loop runs is how people convince themselves the limit is “stuck.”

Check what’s already been issued

Before you re-issue anything, look at what Let’s Encrypt already gave you — because every certificate it issues is published to public Certificate Transparency logs, and those logs are queryable. This is the fastest way to see the loop: if CT shows fifteen certificates for the same names in the last three days, you’ve found your bug and you don’t need a sixteenth. Very often the certificate you’re trying to issue already exists and is perfectly valid — the automation just isn’t loading it.

While you’re fixing the loop, point your clients at Let’s Encrypt’s staging environment, which mirrors production with vastly higher limits. Test your renewal flow there until it stops re-issuing, then switch back to production once.

Diagnose with DechoNet

SSL Check reads the certificate a host is actually serving — issuer, validity dates, and the Certificate Transparency history — so you can confirm whether a valid certificate already exists for your names before you spend another issuance. If the served cert is current, the problem is deployment, not issuance.
DNS Lookup confirms the hostnames you’re requesting certificates for resolve where you expect, which catches the case where a duplicate request is really a typo’d or stale hostname quietly generating its own certificates.

Resolution Checklist

Read the exact error. exact set of domains = the Duplicate Certificate limit (5/week); a registered-domain message = the 50/week limit.
Stop the automation that’s re-issuing. Do this first — the token bucket can’t refill while the loop is draining it.
Check Certificate Transparency (via SSL Check or a CT search) for how many certs were issued for these names recently. A pile of duplicates confirms a loop.
Persist ACME/certbot state to durable storage so restarts and deploys reuse the existing certificate instead of requesting a new one.
Move testing to the staging environment until your flow stops re-issuing.
Wait out the bucket — roughly 34 hours for one Duplicate token — then issue once, in production, and confirm it’s stored.

When to Escalate

If you genuinely need more than 50 certificates a week for one registered domain (a large multi-tenant platform, say), that’s a real capacity need, not a bug — Let’s Encrypt has a rate-limit adjustment request form for exactly this.
If certificates are being re-issued from a managed platform (a PaaS, a load balancer, a hosting control panel) you don’t fully control, the loop is in their automation; the fix is a support ticket to them, not more requests from you.
If you’ve stopped all automation, waited well past 34 hours, and still can’t issue, verify you’re not sharing the registered-domain limit with another team or tenant on the same base domain before assuming the limit is wrong.