Hello,
https://community.letsencrypt.org/t/programmatically-distinguishing-rate-limits/97986/14
^^ W/r/t this LE forum thread, what would be involved in proposing an
ACME extension that provides a reliable, machine-parsable mechanism to
distinguish one rate limit from another?
My specific use case is: the client I’m building iterates through users
on a system and requests certificates as needed: e.g., a newly-added domain,
expired certificate, etc. On a server that has just enabled automatic
certificate generation (or even has just transferred in a user with hundreds of
domains) this will easily run up against Let’s Encrypt’s rate limit of 300
certificate orders per 3-hour timespan.
We could throttle that locally, but the software we publish runs on
servers that we don’t administer, so if an admin has requested an adjustment to
that rate limit (as I suspect many will), we’ll either complicate those admins’
lives by making them keep a local configuration in sync manually with their LE
account, or hard-code 300-per-3hrs and deny them the benefit of their raised
raite limit, which is even worse.
So the solution we’re looking at right now is that we request
certificates until we hit that specific orders-per-3hrs rate limit, then we
stop (until the next cron-scheduled run). This way, from the admin’s
perspective, stuff Just Works™. But that is the *only* rate limit that we want
to treat that way; since all of the other rate limits concern specific domains,
we treat those as nonfatal since a rate limit error for one domain likely won’t
affect others.
The problem is that right now, the only way we have of identifying that
specific rate limit is to look for the string “too many new orders” in the
error document’s “detail”. It’s awfully brittle, but there’s apparently no
other way.
An ACME extension to solve this, then, seems worth proposing. Thoughts?
Thank you!
-Felipe Gasper
Mississauga, Ontario
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme
