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?


1 Like

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.

1 Like

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.