Error 429 too many registrations for this IP

#1

My domain is:
mrrobotcloud.duckdns.org
I ran this command:
caddy / caddy in a docker server
It produced this output:
acme: Registering account for xxxx
2019/01/18 16:20:58 registration error: acme: error: 429 :: POST :: https://acme-v02.api.letsencrypt.org/acme/new-acct :: urn:ietf:params:acme:error:rateLimited :: Error creating new account :: too many registrations for this IP: see https://letsencrypt.org/docs/rate-limits/, url:
My web server is (include version):
Caddy [0.11.2]
The operating system my web server runs on is (include version):
Docker/Ubuntu 16.04
My hosting provider, if applicable, is:
OVH/SYS
I can login to a root shell on my machine (yes or no, or I don’t know):
yes
I’m using a control panel to manage my site (no, or provide the name and version of the control panel):
no

Im getting the rate limiting error, even after waiting more than 3 hours, either when using the caddy executable, or running it though docker I receive this message. Was working fine for the last few months, the caddy container starting rebooting, so Im assuming thats why I got the ban, but I removed the container and waited without any success

#2

You can create a maximum of 10 Accounts per IP Address per 3 hours. You can create a maximum of 500 Accounts per IP Range within an IPv6 /48 per 3 hours.

It sounds like you are not persisting the contents of the Caddy container. Caddy wouldn’t be registering new ACME accounts unless it was started from a fresh slate every time.

#3

It worked before, and I can see in my filesystem all of my certificates, plus I have this running on a different server with the same config without any issues.

The certs are there, and its been offline for more than 3 hours, but Im still limited.

#4

See: https://letsdebug.net/mrrobotcloud.duckdns.org/17464

#5

^ Caddy might be using DNS or TLS-ALPN rather than HTTP I guess.

@mholt might have some ideas on the behavior of account registration, though.

#6

Well port 80 is down because my caddy container is down. I could spin up an apache one that runs on 80 and 443?

#7

43%20PM
Screen Shot 2019-01-18 at 4.49.43 PM.png2124Ă—646 71.5 KB

Installed apache quick to see

#8

Does the renewal now work?

#9

Nope, tried running the caddy executable in the same folder, but containerized or not I get this:

Activating privacy features… 2019/01/18 16:54:17 registration error: acme: Error 429 - urn:ietf:params:acme:error:rateLimited - Error creating new account :: too many registrations for this IP: see https://letsencrypt.org/docs/rate-limits/

#10

I hope this won’t create any issues going forward…

#11

Whoops, thats supposed to be no

Its just an OVH box so I have full root access

#12

OK “NO” makes more sense.

#13

Installed certbot to see if it was a caddy issue… Dry-run doesn’t throw any errors, but trying to get a certificate for that basic apache install gives me the same 429 rate limit error.

#14

https://letsdebug.net/mrrobotcloud.duckdns.org/17491?debug=y

I see an error that says:

DEBUG
1 Certificates contributing to rate limits for this domain
Serial: 417319055578290286944709400725202947188573
NotBefore: 2019-01-16 19:40:10 +0000 UTC

Does that mean i’m on the 1 week ban? Not the 3 hour one?

#15

I see [quote=“Dude245, post:3, topic:83204”]
It worked before, and I can see in my filesystem all of my certificates
[/quote]

Maybe those certificates aren’t mounted into the container properly? Or maybe Caddy is not configured to look for them in the right place? I suppose it’s also possible that the directory containing certificates was persisted, but the directory containing account information was not.

I do think @_az’s evaluation is most likely correct: Caddy for some reason thinks it doesn’t have an account yet, and is attempting rapid re-registration. Containers in particular often cause problems for a variety of clients, by not persisting account data across multiple runs.

Since this is a rate limit applied to your IP address, it will persist regardless of which client you use. However, it will expire in 3 hours and you can try again. In the meantime you can take a look at your container configuration and see if you can find the issue.

#16

Hmm, it just let me create about 10 subdomains then started giving me the error again. I think it might be resetting and using a default user every time its created so its “creating” a new user?

I don’t see anything wrong with my config though:

docker run -d --name caddy \
-v /root/dockerFS/caddy/Caddyfile:/etc/Caddyfile \
-v /root/dockerFS/caddy/:/root/.caddy \
-v /root/dockerFS/caddy/sites/:/srv \
--restart=unless-stopped \
--net=host \
abiosoft/caddy:php-no-stats
#17

Yep, I think that’s what’s going on.

It’s possible that some release of the abiosoft/caddy:php-no-stats package changed the working directory of the Caddy that gets started, so it doesn’t pull its config from your mounted volume.

#18

@Dude245 read fully through this recent Caddy issue: https://github.com/mholt/caddy/issues/2400

It sounds suspiciously like your symptom and the timeline matches up (fixed in master only 6 hours ago).

#19

I think that might have been part of the issue, but I also specificied my email in the caddy configs now as well. Working as intended now!

#20

To help verify that this is fixed, build Caddy from https://github.com/mholt/caddy/commit/a7aeb979be5a59ae82fac0783fe54b83c7fc57fd and let us know how it goes. A new release will be going out very soon, potentially within a day, unless people can confirm that it’s still not fixed (but “it works for me” and the tests pass).