Rate limit suggestion

I’d like to suggest that renewals do not count against the rate limit at all.

Logic:
Currently there seems to be an enormous disparity between the effect of rate limiting on bigcorp.foo.baz and on smalluser.bigisp.abc

A big corporation can ensure that all issuing of certs happens on X-day mornings, and all renewals happen on X-day afternoons. (with X increasing by 1 each week iteration, to allow
the time-outs to kick in and allow 20 new registrations per week, as per spec.) Thus big ISP can seemingly always get an extra 20 brand new certs per week.

A small customer at a big ISP who can’t be bothered to register on the PSL, however, is stuck with hoping that they can sneak a registration in the hoped-for-slot between the time-out from 20 other customers renewing their certs in the preceding 7 day period and the next renewal.

The renewals will happen at any random time, of course, and once there get to be more than 20 renewals a week then the probability of any new users getting certs issued (or existing client holders successfully changing their cert) starts to get to zero.

If renewals did not count at all, then the extra certificates issued to bigcorp would not be affected, except the timing issue would go away, but users on bigisp would be able able to take part in the lottery to be one of the lucky 20 who got a cert that week.

For me, this’d be much better than now - my ISP gives me and the rest of their few hundred thousand customers a DDNS name (if you care to sign up for it) as part of their wonderfully low-cost Fibre-to-the-home package. But they have not bothered to get on the PSL (the DDNS is under their old dial-up domain name, which still has a landing page dated 2005, complete with SWF adverts…). There are about 22 renewals per week (including some people who seem to renew their cert every 2 weeks - maybe every time they restart their docker image?) so it doesn’t matter how carefully I check when the last-but 20th certificate was issued, the chances are high that someone renews their cert before the slot opens.
I don’t want to cause more costs for the nice guys at duckdns.org , but the rate limiting thing means I can’t use the DDNS I have, and if I ever to manage to find a slot, then I’ll probably be after a multi-domain cert for duckdns.org and my local ISP, so I can transition more easily. This all sounds like more data to be processed than necessary…
David

The rate limits are there for a reason: to ensure the service of Let’s Encrypt works without any trouble. To do that, Let’s Encrypt needs to keep the load on their services below a certain margin and to ensure that, there are rate limits. Note that these rate limits are not just to frustrate users: they are a Let’s Encrypt server side limit to ensure someone won’t cause an outage by generating too much load. Obviously, it doesn’t matter if the certificate is brand new or a renewal: the certificate will be brand new anyway and the load will be the same.

Therefore, Let’s Encrypt won’t just remove the rate limit for renewals. For example, if a client misbehaves and would renew a certificate every second, this would be obviously very bad. Taken into account the share numbers of users and clients, broken clients can cause a Denial of Service.

Again, the rate limits aren’t to frustrate the users, but to ensure a reasonable load on the servers and taking broken clients into account which might renew continuously. Therefore, renewals probably will always keep a rate limit.

They do want to change it so that renewing certificates won’t eat up the “20 certificates per domain” rate limit and prevent you from issuing new certificates.

The duplicate certificate rate limit can still slow down runaway clients.

The problem is that it requires a surprising amount of work so it’s not ready yet. :slightly_frowning_face:

6 Likes

@mnordhoff’s got it exactly right. We see that having to coordinate renewals in order to make room for new issuance is burdensome for subscribers, and sometimes not possible. Eventually we’ll make it so renewals don’t count against the certificates per domain limit.

@Osiris is also right in that we won’t entirely remove rate limits on renewal. In particular, we’ll keep the Duplicate Certificate limit to prevent misconfigured client from generating tons of certificates. But I don’t think that will be a problem for your use case. :slight_smile:

5 Likes

Thanks to all who have replied. It’s good to know it’s already on the to-do list!

Keep up the good work! In work like this, I’m happy for quality over speed any day.

David

1 Like

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