Max subdomains limit

It seams that renew certificates are counted when checking for certificates per domain limit for new certificate.
I’m currently hitting the ‘Too many certificates issued for domain’ error and to check I use:
https://crt.sh/?q=%.barsy.bg&iCAID=16418&p=1&n=1000
Now in that list the certificates issued in the last 7 days are exactly 20. However (jasmine, 365b, craft, doncho-test, la-piazzetta, saharalounge, ristreto, … ) end several more are renewals.

This means that if you renew your certificates every 60 days you would ultimately be able to produce no more than about 171 certificates for a domain. I’m assuming you issue 3 certificates each 6 days and 2 on the 2 on the 7-th day. (20 in a week), and you renew them 60 days later.

Please, some tell me I’m mistaking somewhere, cause I’ve implemented that system and have 150 more certificates to issue and it seams I have to change the how system and look for another solution :frowning:

Renewals do count towards the limit. However, they aren’t subject to the limit. So the workaround is, when you have a slot available, request any new certificates first and then do any renewals afterwards.

You can also combine up to 100 subdomains on a single certificate, which only counts as 1 towards the rate limit.

Each subdomain is on a different server on the client premises. So combining them in 100 is not an option. If one gets compromised all other are compromised which breaks security.

I’m using dehydrated on a cron job on each server so for your proposed workaround I have to calculate with each next new server to start earlier than a server already issued certificate. This is extremely complicated to be reliable solution.
But even if I do manage to make it, It still would not work, cause I would not get an empty slot.
I have issued approximately 3 certificates per day, so even if I manage to issue a new one before the renewal, the renewal after it would still fill the slot for the next day, and the next day and the next day.

Ok. So I guess my problem is ignored and I have to try to explain it more simply:
Now if you issue 3 certificates each day like this:
01.01 - 3 new certs
02.01 - 3 new certs

07.01 - 3 new certs

And 3 months later you issue manage to request the 3 new certificates before the renewals you would get:
31.03 - 3 new certs
01.04 - 3 new 3 renew
02.04 - no new certificates since you hit the limit of 20 and you can only renew.

That means that once you have reached about 170 subdomains you can only request new once only once in 7 days and only before the other servers haven’t request a renewal.

Can please someone from LetsEncrypt team confirm this limitation and spread some light if any measures will be taken?

This is correct if you spread all renewals evenly in order to stay under the Certificates per Registered Domain limit all the time. However, because the renewals are not subject to the Certificates per Registered Domain limit, you can renew all existing certificates on the same day (even if there are more than 20 of them); then you will not be able to get new certificates for 7 days, but after 7 days you can get more new certificates until the next mass renewal. This way you can get unlimited number of certificates, adding 20 almost every week.

@lukav, if you are hosting these for different people then you might also be able to get a rate limit exemption.

See “If you are a large hosting provider or organization working on a Let’s Encrypt integration” at

https://letsencrypt.org/docs/rate-limits/

I’ve already send the form months ago and tried again when I hit the problem.
Unfortunately there is not reply

Same problem here with renewing certificates and I also sent rate limit form one month ago and nothing.

quick solutions I can think of:

  1. Use a central server to handle the renewals – have your server check to see if renewals are allowed by checking for a local API. Then you can turn renewals on/off as needed.
  2. only run renewals on Saturday/Sunday. Then issue new certs Mon-Fri.
  3. use multiple domains.

@jvanasco
re: 2. It would not work. If you reissue 21 certificates on Saturday/Sunday you won’t be able to issue any new the next 7 days.
re: 3. Although this would work it is actually a marketing game changer that would be too expensive.

There are 2 solutions that will work:

  1. Issue certificates only one day a week and issue new first. Currently that seems the only solution to grant you unlimited certificates for subdomains. However this would mean if you have a new client on the next day you have to wait 6 days before securing his connections.

  2. Apply to get in the PSL (https://publicsuffix.org/), but there is explicit note on the site that you should use Lets Encrypt form if you have our problem. And you won’t be able to set cookies for you main domain, which for some business case could be a deal breaker.

You also have the option of consolidating multiple domain names on a single certificate. You mentioned privately that you do not want customers to be able to see each other’s domain names, but I think between Google and the CT logs, that’s not really an achievable goal.

However, if it is still very important to you to keep each subdomain on its own certificate, you can consolidate your renewals to happen all on the same day every 60 days.

There’s some discussion of this issue on Hitting rate limit after renewing certs. I’ll take your feedback as an additional request to change the exemption so you don’t need to clump up renewals. But in the meantime I’d suggest following one of the above procedures. Your use case is not a fit for a rate limit override because you can issue the necessary certificates under the current limits, given some time.

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.

I wanted to update this thread since we recently announced a change that removes the constraint on order of renewals versus new issuance. The new behaviour grants the renewal exemption regardless of the order of operations and should be much easier to work with.

Thanks to everyone who provided feedback!