Why Let’s Encrypt Says Too Many Certificates for This Registered Domain

This one catches teams that think they are being careful.

Each individual certificate request looks reasonable. The problem only shows up when you zoom out and realize all of those requests belong to the same parent domain.

What the error means

Let’s Encrypt allows 50 certificates per registered domain every 7 days. The limit is global across accounts and refills gradually, about one certificate every 202 minutes.

So if you issue certs for:

• www.example.com
• api.example.com
• login.example.com
• tenant-a.example.com
• tenant-b.example.com

they are all pulling from the same pool if the registered domain is example.com.

What "registered domain" means

Let’s Encrypt uses the Public Suffix List to determine the base domain for rate limiting.

That is why:

• www.example.com rolls up to example.com
• app.example.co.uk rolls up to example.co.uk

This is the part people miss. Different subdomains do not usually mean different limits.

How people actually hit it

The usual causes are operational:

• preview or branch environments request real production certs
• every subdomain gets its own fresh cert even when that is unnecessary
• multiple systems issue independently for the same base domain
• client state is not preserved, so deployments keep creating new certs

The limit often exposes a messy certificate strategy more than a traffic problem.

How this differs from the exact-set limit

The exact-set limit is narrow. It is about one identical hostname bundle.

The registered-domain limit is broader. It is about total issuance volume under the same parent domain, even when the individual hostname bundles are different.

You can hit this one without ever repeating the same exact cert.

Why renewals matter here too

Healthy renewals reduce pressure. ARI-based renewals are exempt from rate limits, which is what you want.

But if the platform keeps creating new production certificates for slightly different names, or keeps forgetting prior state, the registered-domain pool disappears surprisingly fast.

What to do next

1. Stop unnecessary production issuance

If preview stacks, tenant provisioning, or deploy scripts are still asking production for certs while you investigate, pause them.

2. Count demand at the parent-domain level

List all systems that issue under the same base domain. That usually tells the real story much faster than looking at one failed host in isolation.

3. Reduce certificate sprawl

Not every subdomain needs its own certificate lifecycle. Sometimes it does, but a lot of stacks end up with dozens of small certs because nobody stopped to design the system.

4. Preserve renewal state

If containers or automation keep behaving like first-time issuance, the problem will come back.

5. Use staging while fixing the model

Do not spend the remaining production allowance testing challenge changes or deployment hooks.

When an override makes sense

Let’s Encrypt does allow override requests for the registered-domain limit. That can be legitimate for larger platforms or multi-tenant systems with real volume.

But an override is not a substitute for cleanup. If your process is wasteful, you will just hit the higher ceiling later.

Common misunderstandings

"Each subdomain has its own quota"

Usually no. They roll up to the same registered domain.

"I can switch ACME accounts and get around it"

No. The limit is global across accounts.

"Revoking old certs will give space back"

No. Revocation does not restore the allowance.

"This means Let’s Encrypt is rejecting renewals"

Not exactly. It usually means the overall certificate volume under the parent domain has become too noisy.

FAQ

What does this error usually mean?

It means production issuance across the same parent domain has crossed the current 7-day allowance.

Is this the same as the exact-set limit?

No. That one is about one identical hostname bundle. This one is about total volume across the registered domain.

Can Let’s Encrypt override it?

Yes, for legitimate larger-scale use cases. That still does not fix wasteful certificate behavior.

What is the best operational fix?

Reduce needless production issuance, keep renewal state stable, and stop treating every environment like a first-time cert request.