Hitting rate limit


I’m hitting a rate limit in my Docker instance:

Error: urn:acme:error:rateLimited :: There were too many requests of a given type :: Error creating new cert :: Too many certificates already issued for: protobuild.org

I have tried adjusting the account email and the outbound IP, but changing neither seems to remove the rate limit. I’ve fixed the issue that caused too many domain registrations, but I can’t bring my website back up (and because the Docker instance is set to auto-restart, it keeps making requests that fail) until the rate limit for that domain is removed.


The only way I’m aware of for “removing” the rate limit is time. You will need to turn off the option in your Docker instance for it asking for new certs. It looks like you got 4 certs on the 24th, so you don’t need to wait long before you can get another cert ( assuming you don’t have backups of the existing ones).


The thing is that I had --keep, but the target folder wasn’t mapped to the host. So when the instance restarted, the certificates and accounts directory was lost.

There really needs to be some web UI to reset the rate limit, because it can effectively break websites (and because of the short 90 day period, it’s not like you can just keep a copy of the private key; you have to keep requesting them on a regular period).


In the meantime, I’m working around this problem by just turning off HTTPS on the website, and making the software that accesses it automatically fallback to HTTP if HTTPS is unavailable.


I hitted the same issue while testing my stuff.

What’s annoying me is I got no idea when the rate limit will end. Is there a way to check this, something like a letsencrypt status page for domain ?


You should test using the staging server - as that does not have the same limits.

You can see what certificates you have had issued by searching for your domain at https://crt.sh/?


The issue was a bug in the certificate registration script in a Docker instance, which caused the certificate to be re-issued every time the Docker instance restarted instead of the script being saved on the host’s permanent storage.

The testing server isn’t of any help in this case, because the bug was discovered weeks after the site was initially set up to use Let’s Encrypt.