Denial of service attack on shared hosts


I am unable to renew my certs because I’m hitting a rate limit: "Error creating new registration :: too many registrations for this IP: ". It seems somebody on my web host is spamming requests so that I can’t get a renewal.

But why are renewals subject to the registrations-per-IP limit? Should’t a valid renewal always go through? Or is my renewal script implemented improperly? I’m using this script:

I made an issue to the Github page of the script, but didn’t find a solution: The developer says: “We have to register a new private key before we can issue a cert with it. That’s why it is running an additional registration call.”


Renewals are not subject to the registrations-per-IP limit. What it looks like that script is doing is attempting to register a new account with Let’s Encrypt every time and issuing a new certificate, not renewing an existing certificate on an existing account. Thus the rate limit errors.

I’m not familiar with that particular script, but registering a new account that way for every renewal is not advisable and will lead to exactly this sort of problem you are experiencing - especially on a shared host with multiple people doing similar. There’s some more information available in the Let’s Encrypt rate limits and integration guide.

If possible, I would suggest looking for an alternative client/script which re-uses existing accounts when attempting renewals to bypass this particular rate limit.


I’m the original author of the script @jnalanko is using. The main reason I chose to re-register each time is because it appears that a registration (using the v1 API, at least) is based off of a private key and an email. If I’m understanding this correctly, to reuse one registration means sharing and not rotating the private key. I thought this was considered poor practice. Have best practices changed or did I not understand correctly? Also, has this changed at all since LE originally launched?

Thanks! As soon as I get a sense of the correct way to do this, I’ll get a new version out that handles this properly.


Now that I’m re-reading the docs, it looks to me like there is an account private key which is used for registering and maintaining that registration. But it looks like I can also create a separate private key which is used for creating the CSR. Am I understanding this correctly and are there best-practice concerns I’m missing?



One account per user/customer is generally considered the best practice I believe - hence this rate limit. See the integration docs at specifically One Account or Many?. Clients like certbot et al will save the account key and re-use for future issuing and renewal purposes.

The CSR key is separate from the account key, and is generated for each certificate.


Thanks! I’ll get to work.


Hi folks,

Thanks for jumping in with answers @eggsampler, appreciated!

To expand on the information already shared in this thread: Let’s Encrypt actually forbids using the account public key as the public key in a CSR so you necessarily have to create a separate account keypair and certificate keypair. Doing otherwise won’t work :slight_smile:


So I’ve been unknowingly generating a private key, registering with it, then throwing it away. :man_facepalming:


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