Failed Authorization (Timeout) But LetsEncrypt was able to access the server?!?

My domain is:
central.enzed.me

I ran this command:
certbot --nginx -d central.enzed.me

It produced this output:
Failed authorization procedure. central.enzed.me (http-01): urn:ietf:params:acme:error:connection :: The server could not connect to the client to verify the domain :: Fetching http://central.enzed.me/.well-known/acme-challenge/Qc_F0Y91zSnkJRjitgOWmAlHPLogEXmKDa84uvsrG7c: Timeout during connect (likely firewall problem)
IMPORTANT NOTES:

  • The following errors were reported by the server:
    Domain: central.enzed.me
    Type: connection
    Detail: Fetching
    http://central.enzed.me/.well-known/acme-challenge/Qc_F0Y91zSnkJRjitgOWmAlHPLogEXmKDa84uvsrG7c:
    Timeout during connect (likely firewall problem)
    To fix these errors, please make sure that your domain name was
    entered correctly and the DNS A/AAAA record(s) for that domain
    contain(s) the right IP address. Additionally, please check that
    your computer has a publicly routable IP address and that no
    firewalls are preventing the server from communicating with the
    client. If you’re using the webroot plugin, you should also verify
    that you are serving files from the webroot path you provided.

My web server is (include version):
Nginx 1.14.0 (Ubuntu)

The operating system my web server runs on is (include version):
Ubuntu 18.04.4 LTE

My hosting provider, if applicable, is:
Self-Hosted

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

The version of my client is (e.g. output of certbot --version or certbot-auto --version if you’re using Certbot):
certbot 0.31.0

When I checked the server logs after the failed authorization attempt, I found that the LetsEncrypt automated process successfully retrieved the file from the .well-known/acme-challenge authorization file.

XXXX@proxy:/etc/nginx/sites-available# cat /var/log/nginx/enzed.com.au_access.log | grep Qc_F0Y | more
34.222.229.130 - - [20/May/2020:04:05:37 +0000] “GET /.well-known/acme-challenge/Qc_F0Y91zSnkJRjitgOWmAlHPLogEXmKDa84uvsrG7c HTTP/1.1” 200 118 “-” “Mozilla/5.0 (compatible; Let’s Encrypt validation server; +https://www.letsencrypt.org)”
3.14.255.131 - - [20/May/2020:04:05:37 +0000] “GET /.well-known/acme-challenge/Qc_F0Y91zSnkJRjitgOWmAlHPLogEXmKDa84uvsrG7c HTTP/1.1” 200 118 “-” “Mozilla/5.0 (compatible; Let’s Encrypt validation server; +https://www.letsencrypt.org)”
18.196.96.172 - - [20/May/2020:04:05:37 +0000] “GET /.well-known/acme-challenge/Qc_F0Y91zSnkJRjitgOWmAlHPLogEXmKDa84uvsrG7c HTTP/1.1” 200 118 “-” “Mozilla/5.0 (compatible; Let’s Encrypt validation server; +https://www.letsencrypt.org)”

Those IPs are all the secondary validation servers, the primary validation server’s request seems to be missing.

See this thread: ACME v1/v2: Validating challenges from multiple network vantage points

Check that you haven’t got any hosts blocked on your firewall.

1 Like

We don’t have any hosts blocked at the firewall level. We can use certbot successfully with other domains on the same host, just this one particular domain is having an issue.

It could have just been a temporary network stall.

When I test right now, no timeout occurs: https://acme-v02.api.letsencrypt.org/acme/authz-v3/4711744348 . You should see a hit from 66.133. or 64.78. in your access log, alongside the 3 hits from AWS.

Have you tried again recently?

I just gave it another try and it worked. Seems like it was just one of those transient things.

Certbot is great, not so good though when you’re migrating a site and want to have the SSL in place before you flick the switch on the IP in DNS.

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