Paying your way out of rate limits


Pretty self-explanatory. N00bs like myself who happily bypass the RTFM phase to dive right into testing in production, would be more than happy to get out of jail for a small donation.


But why? Add or remove a FQDN from the cert request, and you’ve just bypassed the most common rate limit. Now, if you’ve managed to make more than 50 certs in a week, maybe you need to wait a bit and figure out what you’re doing.


Hi @domq,

As @danb35 said, the default rate limits should be more than enough for almost any sort of use. Want to describe your use case and we can help you understand whether you need an increase or not?


Also, seeing the exact rate limit error you are getting would be helpful.


This sounds like it would inevitably backfire and create a PR problem…
“LE charges to allow you to get a free cert”
Or the beginnings of a very slippery slope…
If LE needs to raise more money it could simply lower the rate limits to squeeze more money out of such people.

Either way, I say this would be a bad idea (in any practice).

A better idea would be to find, and pay for, independent help with your LE cert setup problem.
[if you can’t resolve them yourself nor with the help of this community]


Hi @domq!

Thanks so much for your post. I’m JP, I have the unique opportunity to work for Let’s Encrypt in both of the areas you are describing.

We always appreciate donations to Let’s Encrypt. We truly seek to break down the financial, educational, and technical barriers for a more secure Web and can definitely use the monetary support of persons and organizations who have the means to do so!

Everyone should be able to use Let’s Encrypt, in both small ways (securing personal blogs or websites) and in big ways (like the thousands of servers Datto uses Let’s Encrypt on ). Luckily, for those big ways that need the higher rate limits, we do have a get out of jail without a small donation! The RTFM phase (RTFM= Read The Fancy Manual, correct?) to reach those higher limits is this document: . I feel so very strongly that every large integrator should read that document as well as this one: as it will help the large integrator make a great implementation. By reading the docs, many large Let’s Encrypt integrators are able to build their environment in a way that their certificates are issued so seamlessly they don’t often have to think about it!

That all being said, I triage the rate limit adjustment requests that come in through the form in the documentation. If I can be of help, please let me know.

Thanks for using Let’s Encrypt in big ways, I hope to see you and potentially your organization supporting a more encrypted Web in big ways too!


Automated payment system to reset rate limits and avoid business interuption

I believe the reason for rate limits is not simply financial, so I do not think money would solve the problem. There are technical, policy, and threat model aspects to consider.

(I’m speculating here. But this is why I support Let’s Encrypt’s rate limits, and also hopefully some insight as to why it’s more complex than just money.)

Technical reasons for rate limits

Certificates, CAs, and even your web server are all part of an ecosystem called Public Key Infrastructure (PKI). PKI does not scale infinitely and it does not scale particularly quickly, either.

For instance, certificate transparency logs must record every certificate issuance in near-real time and must comply with strict availability requirements.

The theory behind these technologies has not progressed to the point where it’s feasible for a non-trivial number of subjects to request an unbounded number of certificates. Although insert and lookup operations in Merkle Trees grow ~logarithmically over N entries, space requirements grow linearly. If the rate of inserts grows polynomially over time (i.e. N clients being issued M certificates = N*M, as M approaches infinity), then you exceed what even most cloud storage providers deal with in terms of growth, where most of their clients add data ~linearly.

Another thing to consider is that OCSP caching becomes essentially useless if certificates are issued without bounds. OCSP responders are already overworked (due to a lack of proper stapling—shameless plug for the Caddy web server which does this properly automatically and by default!). Currently, CDNs and caching make OCSP feasible. But the shorter the effective lifetime of a certificate, the more cache misses there will be. Even OCSP stapling would be rendered ineffective if the certificate wasn’t used for the duration of the staple.

In other words, it’s technically difficult (and professionally unreasonable) to expect other operators of public key infrastructure to scale to your demands without bounds.

One other reason, which is probably the most important: rate limits expose bugs in software and configurations. Fix it, don’t just make the hole deeper.

Policy reasons for rate limits

CAs need to adhere to baseline requirements (BRs) which include various forms of due diligence to prevent abuse. Lack of rate limits for a system which is designed to be automated at least looks irresponsible, so it’s good practice to help prevent abuse, even if the abuse is accidental.

Also, tracking hundreds or thousands of accounts per user/site/service/client/“subject” is an accounting nightmare.

Finally, although I’m not sure what the restrictions are for non-profits, I doubt regulating authorities smile upon non-profit organizations selling services.

Threat model reasons for rate limits

Almost every endpoint on Let’s Encrypt’s servers mutates state. The obvious reason to enforce rate limits is to help prevent DoS.

Imagine the fallout if an attacker was able to cause misissuances at an unbounded rate. Reporting and revoking a only a handful of certificates is feasible: but on the scale of hundreds, or thousands, or more, certificates is a bit daunting (and strains the CRLs).

Anyway, just thought I’d post some thoughts about it. Hope it’s helpful.

closed #8

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