Rate limit documentation missing overall request rate limits

[jmhodges]

It seems that sending HEAD to https://acme-v01.api.letsencrypt.org/acme/new-authz can, in some cases, cause you to hit some rate limit and get a 429 returned. That's unexpected for HEAD since HEAD is equivalent to a GET, not POST, and shouldn't be causing any writes to occur.

I'm not clear on why the wfe code for NewAuthorization and method handling aren't catching this first, but they aren't.

I ran into this because the 429's do not have a replay-nonce response header on them and crypto/acme was breaking on that.

I have a ticket for crypto/acme on this, but this seems like it ought to be fixed both there and in boulder itself.

[cpu]

From the crypto/acme thread it looks like you figured this out:

the 429s from Let's Encrypt are a new, currently undocumented request-per-IP-per-endpoint-per-second rate limit that's set fairly low

I'm not clear on why the wfe code for NewAuthorization and method handling aren't catching this first, but they aren't.

The request-per-IP-per-endpoint limit is being applied before the WFE.

[jmhodges]

Okay! If it's the deal, it's set pretty low when, say, calling for the authorizations of a cert with a number of domains in it in parallel.

[cpu]

@jmhodges That's fair feedback. I expect we're going to be revisiting the specific limit thresholds after the holiday period. In the mean-time I'll get the existing limits on the docs page - its no fun hitting undocumented rate limits.

[cpu]

Opened letsencrypt/website#118 for adding the limits as they exist today to the rate limits documentation.

[cpu]

letsencrypt/website#118 was merged. Website should be updated with the new rate limits documentation in the next while.