[SOLVED] Certbot/Resolution Errors(?) - Failed authorization procedure :: The server could not connect to the client to verify the domain

Hi all,

Certbot isn’t able to create certificates using http-01 challenge using a webroot with nginx running. I might be able to stop nginx to try python’s SimpleHTTPServer module to get certificates, but what about renewal? I understand TLS-SNI challenges are disabled and causing issues with plugins for nginx and apache, but that shouldn’t have anything to do with http-01 challenges.
I had existing and unrevoked certificates for some of the same domains. I’m unable to revoke the certificates because they’re in a long gone server with lost backups.
I have all of the information below, and can verify that files are being created in my .well-known/acme-challenge directories with inotifywatch and watch -n 0.1 ls -lRa just to make absolutely sure certbot is creating files.

However, I don’t see any records of any client accessing any of the challenge files in .well-known/acme-challenge, even though the contents of the folder are accessible through HTTP.
http://texastelephone.com/.well-known/acme-challenge/test.txt Displays the contents of the message.

Do the acme-challenge files need to be accessible as a MIME type other than application/octet-stream, like text/plain? Would it matter anyways if there aren’t any requests for the files hitting my server from the Let’s Encrypt server?

I can supply information from the DNS records if needed.

My domain is:

texastelephone.com, ftp.texastelephone.com, mail.texastelephone.com, www.texastelephone.com

I ran this command:
certbot certonly -w /srv/http/default/ -d texastelephone.com -d ftp.texastelephone.com -d mail.texastelephone.com -d www.texastelephone.com --installer nginx --webroot  --test-cert &> certbot.log 
It produced this output:
root@texastelephone:/srv/http/default# cat certbot.log
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Obtaining a new certificate
Performing the following challenges:
http-01 challenge for texastelephone.com
http-01 challenge for ftp.texastelephone.com
http-01 challenge for mail.texastelephone.com
http-01 challenge for www.texastelephone.com
Using the webroot path /srv/http/default for all unmatched domains.
Waiting for verification...
Cleaning up challenges
Failed authorization procedure. texastelephone.com (http-01): urn:acme:error:connection :: The server could not connect to the client to verify the domain :: Fetching http://texastelephone.com/.well-known/acme-challenge/kuVKXwC3ntgXufOnfMyslc1HSL45IEbTHmbo7kSqIBg: Timeout, ftp.texastelephone.com (http-01): urn:acme:error:connection :: The server could not connect to the client to verify the domain :: Fetching http://ftp.texastelephone.com/.well-known/acme-challenge/VAHCNfQoDtW5EhYjkzzyNYq-fdMVYjFXNRidKGqLo-E: Timeout, www.texastelephone.com (http-01): urn:acme:error:connection :: The server could not connect to the client to verify the domain :: Fetching http://www.texastelephone.com/.well-known/acme-challenge/vjmzqWB8l2hZFfTM1Wv4I18UH3rSmIJa62Qh6halxoE: Timeout, mail.texastelephone.com (http-01): urn:acme:error:connection :: The server could not connect to the client to verify the domain :: Fetching http://mail.texastelephone.com/.well-known/acme-challenge/ypMc3_LwDtTM5NFOL7Tg6ayU0GrbAI-kztgJRCkfgAo: Timeout
 - The following errors were reported by the server:

   Domain: texastelephone.com
   Type:   connection
   Detail: Fetching

   Domain: ftp.texastelephone.com
   Type:   connection
   Detail: Fetching

   Domain: www.texastelephone.com
   Type:   connection
   Detail: Fetching

   Domain: mail.texastelephone.com
   Type:   connection
   Detail: Fetching

   To fix these errors, please make sure that your domain name was
   entered correctly and the DNS A 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 version: nginx/1.10.3
built with OpenSSL 1.1.0f  25 May 2017
TLS SNI support enabled
configure arguments: --with-cc-opt='-g -O2 -fdebug-prefix-map=/build/nginx-2tpxfc/nginx-1.10.3=. -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2' --with-ld-opt='-Wl,-z,relro -Wl,-z,now' --prefix=/usr/share/nginx --conf-path=/etc/nginx/nginx.conf --http-log-path=/var/log/nginx/access.log --error-log-path=/var/log/nginx/error.log --lock-path=/var/lock/nginx.lock --pid-path=/run/nginx.pid --modules-path=/usr/lib/nginx/modules --http-client-body-temp-path=/var/lib/nginx/body --http-fastcgi-temp-path=/var/lib/nginx/fastcgi --http-proxy-temp-path=/var/lib/nginx/proxy --http-scgi-temp-path=/var/lib/nginx/scgi --http-uwsgi-temp-path=/var/lib/nginx/uwsgi --with-debug --with-pcre-jit --with-ipv6 --with-http_ssl_module --with-http_stub_status_module --with-http_realip_module --with-http_auth_request_module --with-http_v2_module --with-http_dav_module --with-http_slice_module --with-threads --with-http_addition_module --with-http_geoip_module=dynamic --with-http_gunzip_module --with-http_gzip_static_module --with-http_image_filter_module=dynamic --with-http_sub_module --with-http_xslt_module=dynamic --with-stream=dynamic --with-stream_ssl_module --with-mail=dynamic --with-mail_ssl_module --add-dynamic-module=/build/nginx-2tpxfc/nginx-1.10.3/debian/modules/nginx-auth-pam --add-dynamic-module=/build/nginx-2tpxfc/nginx-1.10.3/debian/modules/nginx-dav-ext-module --add-dynamic-module=/build/nginx-2tpxfc/nginx-1.10.3/debian/modules/nginx-echo --add-dynamic-module=/build/nginx-2tpxfc/nginx-1.10.3/debian/modules/nginx-upstream-fair --add-dynamic-module=/build/nginx-2tpxfc/nginx-1.10.3/debian/modules/ngx_http_substitutions_filter_module
The operating system my web server runs on is (include version):
Distributor ID: Debian
Description: Debian GNU/Linux 9.3 (stretch)
Release: 9.3
Codename: stretch
My hosting provider, if applicable, is:


I can login to a root shell on my machine (yes or no, or I don’t know):


I’m using a control panel to manage my site (no, or provide the name and version of the control panel):


You have AAAA records in your DNS for all four names, but the IPv6 address they point to isn’t responding on port 80 (I checked it here). If you intend to have working IPv6 connectivity for your site, make sure the address is correct and that your server is listening on IPv6. If not, remove the AAAA record as Let’s Encrypt will use it in preference to IPv4 if the record exists.

1 Like

Thanks! I changed my DNS records, and my certificate generation was successful.

1 Like

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