Rate limit update: removal of renewal and new-issuance ordering constraints

A common source of confusion around rate-limits has been the requirement that renewals be done after new issuances in order to fully exploit the renewal rate limit exemption and maximize the number of certificates capable of being issued.

Our rate limiting documentation says:

Also note: the order of renewals and new issuances matters. To get the maximum possible number of certificates, you must perform all new issuances before renewals during a given time window.

To address the challenge of coordinating issuance to meet this requirement & the feedback we’ve received we have changed the rate-limiting code to always apply the renewal exemption such that the order of new issuances and renewals is no longer an issue.

This change is currently active in both the Staging environment and production environments. The rate-limit documentation will be updated shortly.

Edit: Unfortunately the change to the rate limiting code mentioned above is causing performance regressions for certain issuers with rate-limit adjustments whose issuance patterns interact poorly with the new rate limit calculation code.

We have reverted the change for the time being, restoring the original rate limit logic requiring coordination of renewals and new issuance. In the near future we will be performing a database migration to update table schema to support implementing a more performant version of this change.


Edited to reflect the fact that this change has been live in production since July 20th.

Edited to reflect that we are disabling this change in production & staging. Apologies.

Please follow https://github.com/letsencrypt/boulder/issues/2800 for updates on this work. It is not currently scheduled.

1 Like

A new API announcement has addressed this problem: Rate limits: fixing certs per name rate limit order of operations gotcha