rancher-letsencrypt
rancher-letsencrypt copied to clipboard
Error 429 Too many pending authorizations
Please see the thread here: https://community.letsencrypt.org/t/error-429-too-many-pending-authorizations/27273
I'm using the Route53 DNS method for challenge proof.
I'm not sure which side is broken here, but I'll leave my service stopped for a day and try to get some more preliminary logs.
I found the cause:
[rancher@ip-172-16-0-216 ~]$ docker logs 16e9e872da5f
level=info msg="Starting Let's Encrypt Certificate Manager v0.4.0 3c41d73"
level=info msg="Generating private key (2048) for [email protected]."
level=info msg="Creating Let's Encrypt account for [email protected]"
level=info msg="Using Let's Encrypt Production API"
level=info msg="Trying to obtain SSL certificate (dev.jewlr.com,dev.jewlr.ca,dev.jewlr.co.uk,dev.jewlr.com.au,dev.jewlr.fr,dev.jewlr.de,dev.jewlr.es,dev.jewlr.nl,dev.jewlr.ie,staging.jewlr.com,staging.jewlr.ca,staging.jewlr.co.uk,staging.jewlr.com.au,staging.jewlr.fr,staging.jewlr.de,staging.jewlr.es,staging.jewlr.nl,staging.jewlr.ie) from Let's Encrypt Production CA"
level=error msg="[dev.jewlr.ie] Error obtaining certificate: Error presenting token: Failed to determine Route 53 hosted zone ID: Could not find the start of authority"
level=error msg="[staging.jewlr.ie] Error obtaining certificate: Error presenting token: Failed to determine Route 53 hosted zone ID: Could not find the start of authority"
My opinion is that the Let's Encrypt image should not get itself into an endless loop which eventually causes the 429 errors should there be a problem with proving ownership due to missing Route53 entries, etc. - instead the service should die once with the error so I can determine and fix the problem (the underlying cause is buried in subsequent 429 logs)
Is the service looping on trying to create the certificate or is it actually the container restarting again end again on error? The underlying problem is probably that one of the zones does not exist?
The latter, container restarts over and over again.
Yes, that is indeed the underlying error, however since I have to wait a good amount of time before the initial authz nearly finishes, I don't have those original logs without having to go back to the host and get the raw logs from Docker.
The thread in the forums also has some good tips in terms of handling open authz so the 429 error isn't encountered.