Update: now it’s working, only come minutes after the time of creation of the first certificate!
@jsha Hey I just hit a 429 trying to register on Staging. I’m not doing anything near 500 Reg/IP per 3 hours. I’ve probably registered about 50 times in the past few hours.
What’s going on?
[EDIT: just got new IP address and I can register fine]
Is it possible to re-download a certificate & key I already created? I didn’t realize there was a rate limit, so while testing automation around renewal, I deleted the /etc/letsencrypt directory entirely…
The certs you can get from the CT logs, the private keys however stay on your server only unless you backed them up elsewhere.
1 Like
Why do people keep doing that?
1 Like
Is it possible to request a manual, one-time reset of the rate limit for a specific domain?
Yes. You do this by waiting 7 days 
Seriously though, the entire point of LetsEncrypt is that it should work automatically with minimal amount of human support … otherwise the model will never work. If you managed to hit the limits, you accidentally broke this model. You should fix whatever you did so that this doesn’t happen again.
And then you wait until the time-limit expires. In the meantime, if you are really stuck, you use a certificate from a different provider. StartSSL would be an obvious choice.
Hopefully, once the public-beta is over, this will be handled in a more user-friendly way. But for now, that’s what you agreed to put up with, when you decided to take part in the beta program.
1 Like
Fair enough I hit the limit by testing the command several times for the purpose of automation. Lesson learned!
I wish the documentation was a little bit more “in your face” about using the staging servers for this purpose. They have no (or really high?) limits. So, they work great for debugging automated scripts; but they don’t serve publicly-recognized certificates. So, they are not suitable for production use.
1 Like
Not all of us are doing this “by mistake”. Some of us have a dozen separate servers, such that using a single combined cert isn’t an option. Hopefully something suitable is done post-beta to alleviate this.
I wrote / use https://github.com/srvrco/getssl for automatically running the script across multiple remote servers if that helps ( as long as you have ssh access with keys to the remote servers, then you can automatically add the challenge codes etc to those servers ), if it’s just the automation issues that is preventing you having a combined cert.
Alternatively, you can use DNS to manage the challenges, and verify different servers …
You get 5 certificates per domain and week. With a limited lifetime of 90 days and renewal after 60 days, that gives you about 8 weeks to stagger your requests. In other words, you can have 5*8 = 40 sub-domains for each of your domains. If you need more than that, maybe it would make sense to add your domain to the public suffix list (effectively lifting this limit)?
Or maybe, I don’t understand @nneul’s problem quite right.
Please do not suggest that. Being in the list has important implications on how browsers and clients will treat your domain. You should not request to be listed just because you want more Let's Encrypt certificates.
Certainly I could stagger them (and have) - for that specific limited case, however, I also have a similar situation where staggering them isn’t really that user friendly and the shared-deployment doesn’t work either since it’s spread across lots of different developers with different systems.
In many cases, having a single cert with lots of hostnames on it isn’t appropriate from a policy/appearance standpoint, though that certainly is an option for some deployments.
Fair enough. I should have been a little more verbose.
If you have lots of different sub-domains, there is a good chance that these subdomains are entirely independent (e.g. they are in fact delegated to different owners). In that case, marking the top-level domain as a public suffix is probably the correct answer.
But there are of course other reasons for having this many different sub domains. And @weppos is entirely correct that inclusion in the public suffix list should not be done, if the only reason is trying to work around current rate limits imposed during the beta phase of LetsEncrypt.
Thank you for pointing this out.
1 Like
Agree completely on the domain not belonging on the public list when it’s different subdomains because each is a different server/service. In a third case of mine (student and individual desktops systems at a university) - for that, their designated top level subdomain would likely be completely appropriate for the PSL.
Long thread, but the issue is very relevant.
Imagine having to wait 7 days before being able to take the next step, since most people issuing are developers and not end clients, this means we delay the delivery of our work by a full week because there was an error on some script (that we used to generate the certificates).
I have read here some plausible ways of increasing the limit without too heavy cost on your database.
One very simple way, would be to provide a form on a public site to unlock a domain from the retention. having to go to a 2nd place to unlock would keep the current limit t avoid script abuse and also allow us to manually unlock once we have figured out that there was a problem.
Another option is just to reduce the throttling, I never saw a throttling of 7 days, if reduced to 12 hrs you can be sure that people would still feel annoyed enough to change abusive scripts and avoid stress on your db.
nevertheless, thank you for the essential service you have been providing.
Use the staging server! (As is said on the rate limits documentation page.)
Using the "live" server for developing is.. Well.. Just stupid, no offence 
Unless you've got a very good reason not to use the staging server while developing, but then you wouldn't hit the rate limit.. I hope..
1 Like
There might be different meanings of “developer” here 
I’m assuming @Osiris is meaning an ACME script developer, and hence absolutely correct. I have a feeling that @dreamerworks is possibly meaning a website / animation / … developer and is placing the work they do for their client on a separate subdomain each time (although could be wrong ) @dreamerworks can you clarify your meaning / use ?
The problem is these limits are being hit for real use - not staging/development.
Right now - with both renewals AND new certs counting against the 20/week limit - if you already have 100+ certs in use, it is really easy to have used up the 20 in renewals, and then suddenly it’s several days before you create any new cert.
That will only get worse as the number of certs in service grows, since your likelyhood of hitting the limit for renewals will be steadily increasing.
Yes - I know that the limit does not APPLY TO renewals, but renewals still use up those slots, making it to where you can’t register any new cert.
This is magnified if you have user self service (such as multiple people in an organization) doing their own certs, since you might not even have visibility to the fact that they had done renewals this week.