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