Why Let’s Encrypt Says Too Many Certificates for the Exact Same Set of Domains

This is one of those Let’s Encrypt errors that sounds abstract until you realize what probably happened.

The same certificate request, or something very close to it, kept getting issued in production over and over.

Not renewed cleanly. Re-issued.

What the error actually means

Let’s Encrypt allows 5 certificates for the exact same set of identifiers every 7 days. That limit is global across accounts. It refills gradually, about one certificate every 34 hours.

So if you keep requesting a certificate for:

• example.com
• www.example.com

and you keep doing that in production, you eventually run out of room for that exact hostname bundle.

What "exact same set" means

The wording matters.

If you add api.example.com, that is a different set. If you request only www.example.com, that is also a different set. The limit is tied to the full identifier bundle, not to one hostname in isolation.

That detail is why people get confused. They see a working site, run issuance again for "the same cert," and do not realize Let’s Encrypt is tracking the whole bundle very literally.

How people usually trigger it

The common causes are boring operational mistakes:

• a deploy recreates ACME state every time
• a container has no persistent certificate state
• an install script always asks for a new cert instead of renewing
• someone keeps using production while debugging

The problem is usually not volume in the abstract. It is repetition.

Where ARI changes the picture

This part matters more now than it used to.

If the client supports ARI (ACME Renewal Information), Let’s Encrypt treats those renewals much more cleanly. ARI-based renewals are exempt from rate limits.

If the client does not support ARI, older renewal behavior can still run into the exact-set limit. That is why two systems can both claim to be "renewing" while only one of them behaves the way you would expect.

Why this error is a red flag for process, not trust

This message does not usually mean the CA distrusts the domain. It usually means the certificate lifecycle is messy.

Something keeps creating fresh production orders when it should be renewing an existing lineage or testing in staging first.

That is why the clean fix is almost never "try again later." It is "stop doing whatever keeps generating the same production order."

What to do next

1. Stop new production requests for that same bundle

Do not keep clicking the button. Do not keep rerunning the script. Wait and fix the behavior.

2. Check whether the client is really renewing

Look for:

• missing persistent state
• recreated containers
• copied config without certificate history
• hooks that always request a new cert

3. Check whether ARI is supported

If the client can renew using ARI, that is the direction you want.

4. Move testing to staging

If validation, routing, or hooks still need work, staging is where that work belongs.

The bad workaround people discover

Yes, you can change the identifier set and get a different outcome. For example, adding another hostname makes it a new bundle.

That does not mean it is a good fix.

It can:

• create a certificate you did not actually want
• confuse the deployment model
• push you toward the registered-domain limit instead

In other words, it bypasses the symptom while leaving the process problem alone.

Common misunderstandings

"This means my domain validation is broken"

Not necessarily. This error is usually about repeated issuance, not failed validation.

"Revoking certs resets the limit"

No. Revocation does not give the quota back.

"Renewals should never hit this"

They should not if the renewal path is modern and stable. Older non-ARI renewal behavior can still run into it.

FAQ

What does this error usually mean?

It means production has already issued too many certificates for the same hostname bundle in the current 7-day window.

Is this the same as the registered-domain limit?

No. This one is narrow and literal. It is about one exact set of names.

Can Let’s Encrypt override it?

No. There is no override for the exact-set limit.

What is the real fix?

Make renewal state stable, stop recreating production orders, and use staging for debugging.