ACME error 429 POST hain certificates

Help
1

Please fill out the fields below so we can help you better. Note: you must provide your domain name to get help. Domain names for issued certificates are all made public in Certificate Transparency logs (e.g. crt.sh | example.com), so withholding your domain name here does not increase secrecy, but only makes it harder for us to provide help.

My domain is: ne002.fkwall.online

I ran this command: xrayr restart

It produced this output:

Jun 06 21:15:10 ne001 systemd[1]: Started XrayR Service.
Jun 06 21:15:10 ne001 XrayR[20920]: XrayR 0.9.0 (A Xray backend that supports many panels)
Jun 06 21:15:10 ne001 XrayR[20920]: 2023/06/06 21:15:10 Start the panel..
Jun 06 21:15:10 ne001 XrayR[20920]: 2023/06/06 21:15:10 Xray Core Version: 1.7.5
Jun 06 21:15:10 ne001 XrayR[20920]: 2023/06/06 21:15:10 [Warning] core: Xray 1.7.5 started
Jun 06 21:15:10 ne001 XrayR[20920]: 2023/06/06 21:15:10 [INFO] [ne002.fkwall.online] acme: Obtaining bundled SAN certificate
Jun 06 21:15:11 ne001 XrayR[20920]: 2023/06/06 21:15:11 Could not obtain cttps://acme-v02.api.letsencrypt.org/acme/new-order :: urn:ietf:params:acme:error:rateLimited :: Error creating new order :: too many failed authorizations recently: see https://letsencrypt.org/docs/failed-validation-limit/
Jun 06 21:15:11 ne001 XrayR[20920]: 2023/06/06 21:15:11 Could not obtertificates:
Jun 06 21:15:11 ne001 XrayR[20920]:         acme: error: 429 :: POST :: hain certificates:
Jun 06 21:15:11 ne001 XrayR[20920]:         acme: error: 429 :: POST :: https://acme-v02.api.letsencrypt.org/acme/new-order :: urn:ietf:params:acme:error:rateLimited :: Error creating new order :: too many failed authorizations recently: see https://letsencrypt.org/docs/failed-validation-limit/
Jun 06 21:15:11 ne001 XrayR[20920]: panic: Could not obtain certificates:
Jun 06 21:15:11 ne001 XrayR[20920]:         acme: error: 429 :: POST :: https://acme-v02.api.letsencrypt.org/acme/new-order :: urn:ietf:params:acme:error:rateLimited :: Error creating new order :: too many failed authorizations recently: see https://letsencrypt.org/docs/failed-validation-limit/
Jun 06 21:15:11 ne001 XrayR[20920]: goroutine 1 [running]:
Jun 06 21:15:11 ne001 XrayR[20920]: log.Panic({0xc0008d3d28?, 0xc000172e10?, 0xc0008d3d58?})
Jun 06 21:15:11 ne001 XrayR[20920]:         log/log.go:384 +0x65
Jun 06 21:15:11 ne001 XrayR[20920]: github.com/XrayR-project/XrayR/service/controller.(*Controller).Start(0xc0008da900)
Jun 06 21:15:11 ne001 XrayR[20920]:         github.com/XrayR-project/XrayR/service/controller/controller.go:84 +0x27f
Jun 06 21:15:11 ne001 XrayR[20920]: github.com/XrayR-project/XrayR/panel.(*Panel).Start(0xc0005b9300)
Jun 06 21:15:11 ne001 XrayR[20920]:         github.com/XrayR-project/XrayR/panel/panel.go:209 +0x556
Jun 06 21:15:11 ne001 XrayR[20920]: main.main()
Jun 06 21:15:11 ne001 XrayR[20920]:         github.com/XrayR-project/XrayR/main/main.go:97 +0x250
Jun 06 21:15:11 ne001 systemd[1]: XrayR.service: Main process exited, code=exited, status=2/INVALIDARGUMENT
Jun 06 21:15:11 ne001 systemd[1]: XrayR.service: Failed with result 'exit-code'.
Jun 06 21:15:21 ne001 systemd[1]: XrayR.service: Scheduled restart job, restart counter is at 725.
Jun 06 21:15:21 ne001 systemd[1]: Stopped XrayR Service.

My web server is (include version): aapanel

The operating system my web server runs on is (include version): Debian 11

My hosting provider, if applicable, is: vultr

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): v2board

Im getting the rate limiting error, even after waiting more than 3 hours

2

Looks like you have systemd configured to restart this failed job. What options do you have to control the number and delays for the restarts? Is there a way to check a system log to see if this is causing excessive requests?

Because, normally on production Let's Encrypt you get 5 failures per hour per account per hostname. Which means it should work if you waited 3 hours.

Also, you can find the actual reason for the failure using the Let's Encrypt staging system. It has a different rate limit.

4 Likes
3

There are some weird words/typos in the output:

Did that happen during copy/paste, or is that the actual output?

Also, is that "725" counted in seconds?

2 Likes
4

There's two problems here:

Your server is most likely not able to respond to http validation (http request on TCP port 80), unless you are using DNS validation. Check your firewall, VM networking config and make sure http requests are being forwarded to this server. You will need to wait for the rate limit to expire or use a different CA.

The XrayR service fails to start if it fails to get a new certs, rather than just re-using a cert from last time. This is a serious design flaw and you should raise this with the developers. Even starting up with a dummy/self-signed cert would be better than not starting at all. It's even possible this startup failure prevents http validation, if you are redirecting to https immediately.

Certs should be preserved on service/container restarts, not recreated and if you can do so you should store certs in a non-temporary volume. Based on XrayR/config.yml.example at c183c6492e1fae57c3b50af6ab4783833158499b · XrayR-project/XrayR · GitHub I suspect if you pointed to a path on a permanent volume it wouldn't have to get a new cert on startup.

3 Likes
6

the actual output.
no.

7

Then that output seems garbled/incorrect.

What is meant by "725"?

2 Likes
8

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