Is there a way to delete currently active certificates and reset the rate limit? I did some automation testing and got limited and now would like to delete all the old testing certs and get new ones. A feature luke that would be great, at least for testing purposes like mine.
This, right here:
More people should probably consider doing this when running tests for stuff.
Unfortunately no. For any issued certificates, Let's Encrypt has to provide OCSP responses for the validity period. See the above comment about testing with the staging environment.
2 Likes
Thanks for pointing me in the right direction. I didnāt know about the tight limits before I started testing. They really should make a global notice for using the staging system for development.
Current documentation says 5 per 7 days and 10 per 30. So still too little for many people AND you need to shift your certificate requests to match the 7 days spacing.
Give us 100 per 30 days and domain. I guess this will solve most use cases. More than 10 is just power user, more than 100 gets into the range where commercial certifcates may be an option. (I would not mind getting more free certificates either ;-))
Please don't configure your web servers or Docker containers to auto-issue on startup. You should keep a cache of private keys and recently issued certificates, and reissue only if they are out of date.
This is partly to make sure you use Let's Encrypt's resources most efficiently, but mainly it's good for the uptime and deployability of your service. If Let's Encrypt has an outage at the same time you are deploying your site, you don't want to be prevented from completing your deploy. And even if there is no outage, Let's Encrypt may be slow to issue, delaying your deploy.
I agree the current rate limits are tough to work with. We're working on ways to tweak them to fit common cases better, but they will take some time to implement. Very much appreciate your patience!
5 Likes
+1 to being able to refresh the limit by clearing certificates / introduce more realistic limits.
As Laravel Forge wasnāt working properly for me (it didnāt like that I had a custom nginx config), when installing the certificates on my existing dev site, I did some experimentation on some new temporary sites to work out what the issue was.
As Forge is just a single button install, thereās no possibility of āusing the staging serverā for testing. So Iāve now hit this limit and canāt even get the certificate installed properly on my dev site let alone my live site.
This would be bad form. They are rate limits, not usage limits - allowing this would escalate the problem rate limits are trying to solve - undue load on Let's Encrypt servers.
I'm also for more realistic limits too - it's likely the current limits are in place to make sure we get reliable service for issuance whilst there's a big boom of interest - as weeks go on requests should level out and they'll be able to support a higher load before Public Launch 
@jsha with regards to Testing Against the Let's Encrypt Staging Environment, is there still a private beta staging server rate limit in place too ?
during private beta there was rate limits, so is that still upheld or removed ?
edit: oh never mind private beta rate limit was against non-staging server too heh
The staging server has much higher rate limits. I donāt remember offhand what they are, but if you run into them let me know and Iāll look into it!
Yeah i ran into the rate limits during private beta and public beta now but i believe both instances were against non-staging server heh ā¦ I slowed down my integration testing for now, waiting for rate limits to increase and I see new code is being introduced into the client which Iād need to take into account i.e. --staging flag https://github.com/letsencrypt/letsencrypt/pull/1848 
Is there any news on raising the limit? I have not yet run into it but fully implementing it in my situation would require a significantly higher limit per domain.
Iām running a server which hosts a whole lot of virtual servers all with their own IP, webserver instances and whatnot.
Those virtual servers all get a subdomain to operate from, right now providing them all with a certificate would easily involve generating more then the set limit for my domain.
Somewhere in the ballpark of 20 to 30 at this particular point in time.
Increasing this limit would greatly help with a more broad implementation of LE certificates.
Superb, thank you for your swift reply!
Please can you explain me what is registrations per IP limit? It is ā30 certification from IP in timeā? Or what you mean as āregistrationā? Iād like generate certificates from one IP for cca 15 000 domains + subdomains. It will long job :D.
Registrations are account objects. They basically contain the public key of your account key, email address, etc. Theyāre separate from certificates. In order to obtain a certificate, you first have to create a registration. The client handles this for you behind the scenes. AFAIK, you can create any number of certificates using the same registration, within the limits of all other rate limits (e.g. certificates per domain).
@jsha, I recently hit the rate limit (error response 429) against the staging server. Normally, this hasnāt been a problem, but I was frequently running through a battery of tests for my client (ACMESharp) the last few days and kept hitting some limit.
Is it possible to raise the limit(s)? I know that you would pby want to make sure you tax the server too much and donāt consume too many resources such as storage, but since this is STAGING, I would almost prefer that the server data gets reset every so often, say every 30 or 60 days and allow a much larger threshold for rate limits to enable more frequent development and testing.
Yep, we can raise the limits on staging. Iāll ask our ops team to do that. Our goal is to set them very high to allow exactly this sort of testing. Can you confirm which rate limit you ran into? That is, what was the detail field of the error object you received?
Weāve definitely thought about resetting the staging server data periodically, but since one of the goals is to test performance with a realistic data set, itās helpful to keep the data around.
The rate limit of 5 per domain is horrible given that it applies to subdomains as well.
Telling us a work-around is to issue one cert with all of the subdomains is questionable advice. I hope you can either remove the restrictions per domain and make it per SUB DOMAIN, or give us wild card certs. This is a blocker for me trying to setup a cert for just my 4th value, including the naked domain after having to reissue a couple certs when I terminated the instances in AWS.
1 Like
Here is the problem detail response:
{"type":"urn:acme:error:rateLimited","detail":"Error creating new cert :: Too many certificates already issued for: xxxxxx.tld","status":429}
Whatās interesting though, is that this message must not be surfacing all the details of the limit that was hit because I only get this error when the test runs on my CI server, but when I run it from my development box (with the same domain), it still works fine. So I suspect this must be some limit per IP address or address range perhaps?
Let me know if you need the specific domain in order to troubleshoot or dig into it.