Programmatically distinguishing rate limits

Hello,

Is there any way for code to distinguish reliably among the various rate limits that can trigger rateLimited errors?

I’m developing a client that, for example, needs to behave differently if it hits the 300-orders-per-3hrs limit than when it hits the 20-certs-per-registered-domain-per-week limit. (Specifically: In the “300” case, the client will save its state then pick back up after a few hours; in the “20” case it’ll just skip to the next set of domains.)

2 Likes

Today, I don’t think this can be done reliably. Even Boulder’s own tests are “stringly” defined at the moment. I have a similar interest in seeing this improved.

But I believe that can be solved once two enhancements are made to Boulder:

  1. Sending Retry-After headers when new orders give rateLimited responses
  2. Populating subproblems on rateLimited responses

The combination of having the list of identifiers that were rejected for rate limits + knowing the retry time for the order should be what you need, right?

2 Likes

Retry time would be a nice bonus, but a way to distinguish the different rate limits from each other is the fundamental need.

Right now I’m going to have to look for too many new orders in the error detail, but obviously I’d much prefer something more robust!

the list of identifiers that were rejected for rate limits

And just to clarify: this isn’t the fundamental need, either. What I’m looking for are, e.g., strings like orders, registeredDomainsPerCert, etc. in the error, so I can tell which rate limit was exceeded. It’s a bit less important to know (programmatically) which identifiers in the request triggered the rate limit—though that would also be useful information.

I wanted to suggest that you might infer that a lack of identifiers in subproblems that had the rateLimited error URN, means that you cannot create any new orders. But yeah, nah.

I wonder if this all belongs in an ACME extension. Seems like it poses a minor interoperability risk to ACME in general, especially with a couple of new CAs having gone live recently.

3 Likes

What is the best forum to open a feature request for this?

And, for the time being, can I at least reasonably text-match on the “detail”?

@cpu: With the recent announcement of subproblems support, would it be feasible to add a subproblem that indicates rate limit excesses (and which ones)?

Is there a list of the subproblems that LE gives in its error objects?

Just to make sure I understand, you’re thinking of the case where a finalize order request fails because one or more of the identifiers in the CSR/Order are rate-limited?

I’m not sure I understand the question. A list of the conditions where we may returns subproblems?

Don’t they get bounced at newOrder now? https://github.com/letsencrypt/boulder/pull/4074

1 Like

@cpu:

Just to make sure I understand, you’re thinking of the case where a finalize order request fails because one or more of the identifiers in the CSR/Order are rate-limited?

The more pressing problem for us is actually the case where LE refuses to create a new cert order because of the new 300-orders-in-3hrs rate limit. I need to identify that specific rate limit because we handle it differently from all of the others.

A list of the conditions where we may returns subproblems?

Yeah, anything with a specific identifier that can identify specific problem states. Going by the 2 examples given in the subproblems announcement, maybe that’s not a thing for the currently-deployed subproblems, but the ones I’m requesting (e.g., ordersRateLimit) would be.

Yes, good point :+1: Same question, s/finalize/new/g :slight_smile:

I don’t understand how subproblems relate to this case. That’s an account level rate limit and so there isn’t any identifier in the order to tie a subproblem to. Subproblems are specifically for calling out plural per-identifier errors.

The only cases that have subproblems today are newOrder requests with policy errors for more than one identifier, and finalize requests with more than one identifier that fails rechecking CAA.

Ah, ok. That makes sense. Thank you.

1 Like

Np!

I filed an issue to add subproblems for the case where the certificates per name rate limit is triggered for multiple identifiers in a newOrder request: https://github.com/letsencrypt/boulder/issues/4360 I think that makes sense. Thanks for inspiring the idea with the thread comment.

Returning to the original question in this thread and your newOrder rate limit concern:

I think the ACME WG is the best place to take this. I agree that a way to provide more detailed rate limit information in a standardized CA-agnostic manner is missing from RFC 8555.

And, for the time being, can I at least reasonably text-match on the “detail”?

I think it’s reasonable to match the detail message here. It won’t be CA-agnostic and we do change rate limit detail messages on occasion without making API announcements but it is unlikely to happen to this particular detail string anytime soon.

1 Like

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