Hi
I’ve read many things about the rate limits in the forum now. But the connection between renewals and new issuances is not entirely clear to me now.
I have the following example:
Greetings Eusebius
As far as I know, the issuance policy is for the root domain, so that would not work. If you renewed the certificates on the first 20 subdomains, I don’t think you would be able to issue certificates for the other subdomains. You could do it like this:
This way, you can issue 20 certs every week, but each batch will be newer than the last, so you can renew each of them every three months without using the limits.
Keep in mind that I don’t know enough about the policy, but this is what I’ve picked up from topics around the community.
Yes, that is what I think is the problem. In my case the problem is the following:
That implies a forced delay of a week at least once every three months if I have a perfectly timed implementation.
From my point of view, that is a major showstopper for a large scale implementation of letsencrypt in a single root domain. Especially because the forms for rising the rate limit are processed really slowly.
I would really appreciate if the renewals would not count against the general limit. That would solve a lot of problems while not compromising the fundamental idea of the limit.
The current policy allows renewals to be exempt from the certificates per registered domain rate limit, but they do count against the limit. Therefore, you currently need to obtain new certificates before renewing old certificates. Obtaining the new certificates will count against the limit, causing it to be reached, but then the renewals will be exempt and can continue. If you do it in the other order, the renewals will count against the limit and then the new certificates will be forbidden to issue because of the limit.
There are several threads on this forum where people have complained that this is somewhat counterintuitive and fragile, so I think the Boulder developers are already aware that it would be preferable to have a simpler way to handle this situation.
Yes, it is not only counterintuitive, it is rather harmful for many deployment styles.
What concerns me more is, that it seems that this issue has no priority at all. I think it is really a show stopper for various types of deployments.
Thanks for the input @Eusebius! Definitely every person who reports that this is an issue for them increases our feeling that it’s worth investing the time to fix, and so this is gradually becoming more of a priority. I appreciate your patience.
In that case, let me chime in: I think this currently is the largest issue preventing adoption of Let's Encrypt in large organizations with a decentralized IT infrastructure, e.g. universities.
These cannot coordinate requesting certificates, are not public suffixes, most likely won't qualify for a rate limit exemption, and would most likely be fine if this issue was resolved because adding subdomains is a fairly rare event.
Here’s a proposal on changing how we do rate limiting to make the renewal exemption agnostic to ordering vs new issuances: https://github.com/letsencrypt/boulder/issues/2800. It probably has too many Boulder internals to be useful to folks in this thread, but feel free to chime in if you have ideas, and feel free to “watch” the issue on GitHub for updates.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.
Hi @Eusebius (et al),
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!