Currently there is a 20 certificate a week limit for subdomains, with a possibility for an exception for over 300 certificates week. Why is there a gap of roughly an order of magnitude there? In particular, if one expects to need on the order of even 12 new certificates in an average week, there is no way to factor in the renewals and keep below the 20 certificate a week limit.
[edited to clarify my understanding of the limits applying to subdomains of the same public suffix]
Note that it’s recommended to order renewals after new issuance, because renewals are not blocked by this limit, but do contribute to it. This will let you scale up over time.
I, like most people here, am just volunteering help so my word is not anything official, but there are many strategies for mitigating rate limit issues, including bundling of certificates (allowing up to 2000 domains per week), addition to the PSL (if you’re legitimately a public suffix), etc. The main issue is that rate limits are there because of the limited availability of shared resources. Unlike a commercial CA, more certificates issued do not equate to more money for infrastructure. These limits make it fair for everyone, whereas my understanding of the justification for exceptions is that exceptions are granted when a service is providing certificates for a very wide range of services that have a larger benefit. So yes, it is to sort of weed out those in the middle, to better equip Let’s Encrypt to carry out its stated mission of making the internet more encrypted.
@nchazin: Like @jared.m said, you can still renew certificates after you’ve hit your “Certificates per Registered Domain” limit for the week, due to the renewal exemption. The idea is that by using Let’s Encrypt over time, the number of active certificates you can have on a registered domain gradually increases. That way, people don’t spin up a new domain and immediately issue thousands of certificates.
I’m not sure where the 300 certificates / week number you cited comes from, but to address what I think is your point: Processing rate limit exception requests consumes staff time. We don’t generally want to process rate limit exception requests for people who need, say, 21 Certificates per Registered Domain, because typically people with issuance needs in that range can satisfy them by issuing gradually over a few weeks. So we ask to you only file an exception request if you need a lot of certificates for the same registered domain on a regular basis.
Issuing certs across time works if you can be predictive, but if you need to do it on demand, spread out across each week, you cannot account for new domains versus renewals for pipelining. So if the expectation is to issue a dozen or so requests/week (not 12 every week on a specific day, but more on the order of 2 or so per weekday), is that when it become appropriate to request an exception?
Ah, thanks. I’ve edited that to link to our current form, and to remove the bit about pending authorizations as it’s confusing (most people don’t need a pending authorization increase).
Yep, this is frustrating, and we’re planning to improve this so you don’t have to plan the order of renewals vs new issuance. It might take a little while though; it’s slightly tricky with our current setup.
Just to double check: Are these all subdomains of a single domain? If not, you probably won’t have any rate limit issues at all.
Assuming you’re talking about subdomains of a single domain, I’m afraid the best solution given the current situation with ordering of rate limits would be to try and bundle up all your renewals onto the same day every 60 days. The week after that, you wouldn’t be able to do new issuances, which I realize is a big issue if you’re bringing onboard new sites at a constant rate. That’s part of why we want to fix the renewal ordering issue.