SOLVED: The server could not connect to the client to verify the domain :: Could not connect to <domain name>


Please fill out the fields below so we can help you better.

My domain is:

I ran this command: sudo /opt/letsencrypt/letsencrypt-auto renew

It produced this output:

Saving debug log to /var/log/letsencrypt/letsencrypt.log

Processing /etc/letsencrypt/renewal/
Cert is due for renewal, auto-renewing...
Renewing an existing certificate
Performing the following challenges:
http-01 challenge for
Waiting for verification...
Cleaning up challenges
Attempting to renew cert from /etc/letsencrypt/renewal/ produced an unexpected error: Failed authorization procedure. (http-01): urn:acme:error:connection :: The server could not connect to the client to verify the domain :: Could not connect to Skipping.

All renewal attempts failed. The following certs could not be renewed:
  /etc/letsencrypt/live/ (failure)
1 renew failure(s), 0 parse failure(s)

 - The following errors were reported by the server:

   Type:   connection
   Detail: Could not connect to

   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 operating system is (include version): Ubuntu 16.04.2

My web server is (include version): nginx 1.10.0 (Ubuntu)

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

Really not sure what’s going on here. The debug log (let me know if I should post it) shows it has the right IP address, the location where it places the challenges is correct (/var/www/html/.well-known/). I verified that if I place a file under that directory, I get that file when I open it in my browser. I have tried restarting nginx, rebooting the server, but everything seems like it should work.

Any help is much appreciated!


Have you tried surfing to your site ? My Chromium tries to download a small file, just 57 bytes in length, with aparently random binary stuff in it.

Seems to me your nginx isn’t serving HTTP on port 80.


Considering that you are using ddns, you might want to double-check that the domain name in question actually points to your IP.


I’m not sure I’m missing something, but how did you reach that conclusion? Ah, I understand now, is a CNAME for, missed that :stuck_out_tongue:


@Osiris what’s your location? When I click the link in your post, I get redirected to HTTPS and see the Welcome to nginx page.

@leader like I said in my post, the debug log lists the correct IP.



osiris@desktop ~ $ dig

; <<>> DiG 9.10.3-P4 <<>>
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 15688
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

; EDNS: version: 0, flags:; udp: 4096
;		IN	A


;; Query time: 11 msec
;; WHEN: Sun Mar 19 17:34:34 CET 2017
;; MSG SIZE  rcvd: 99

osiris@desktop ~ $ telnet 80
Connected to
Escape character is '^]'.
GET / HTTP/1.1
��Connection closed by foreign host.
osiris@desktop ~ $


Interesting… I’m in The Netherlands as well, and can reproduce the telnet problem… yet in the browser it works fine, e.g. (redirects to HTTPS and then serves the file correctly). Any idea what could be causing this?


Are you sure? Because I checked with WireShark and all clients (telnet, wget, curl, Chromium) get the same result on a network level: binary garbage.

It’s just curl just outputs the binary stuff on the CLI, wget thinks he’s getting test.txt and saves the result as such, but in reality he’s getting junk as well. And the browser assumes the binary stuff would probably be test.txt, so it also offers to save the file, while this file too is just binary garbage.

Could you check the contents of your downloaded test.txt? I’m sure it’s not containing the words/letters you were planning it to be :wink:

Your nginx is doing TLS on port 443, so I’m quite certain your nginx configuration for the “main” HTTP server block on port 80 is somehow corrupt.


The test.txt file contains the text “test”, which is the same thing I see in my browser. Clearly from what you’re saying the fact that Let’s Encrypt reports that it can’t connect is correct, though so far I’m confused as to why it works for me.
The obvious answer would be that I’m at home and that makes some difference, but I tested this from the office as well, with the same result.


And the IP is really, really the correct one?


Well, it’s what reports: “Uw IP-Adres:”, and it’s also listed as the WAN IP-address in my router status page. So it sure seems that way.

However, produces the garbage file like you say. Maybe there’s some sort of NAT issue going on on the ISP end, though I have no idea how to verify that.


There were cases previously when IP resolved internally would be different from the one resolved externally. Hence the suggestion to double-check :slight_smile: Seeing though that it appears valid but the requests are producing binary garbage, that would be interesting to find out why … Any odd compression enabled in server configuration, supported by the browser but not by curl or verification agents?

Actually, you seem to be running HTTPS on port 80 … Double-check your server configuration.


Hm, interesting, OpenSSL gave me an error when I tried that :hushed::

osiris@desktop ~ $ openssl s_client -connect -servername
140507793696400:error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol:s23_clnt.c:794:

Also, my Chromium doesn’t agree :stuck_out_tongue:

This site can’t provide a secure connection sent an invalid response.


Weird. Though it has been checked via another service, which might simply strip the port in my case. Plot thickens … :slight_smile:

@MaartenStaa, when you said you are seeing the text in your browser, are you sure you are looking at HTTP and not HTTPS (especially that you have HSTS there)? If HTTPS version works as expected but not HTTP version, I would try to make sure that port 80 is in use by Nginx and not something else first (for example with lsof -i). If it is Nginx - check its configuration. If it’s not, kill/move whatever process sits on 80 or use verification other than HTTP.


Ok, I found the problem. So my nginx config was set up to redirect all port 80 requests to https, and then the server block for port 443 was configured to handle requests correctly.

However, I incorrectly defined the first server block with…

server {
        listen 80 default_server http2;
        listen [::]:80 default_server http2;

Not realising that http2 is only supported on ssl servers (unless configured appropriately). To be honest, I’m still not sure why it did work in my browser but not for you guys, but after removing the http2 part, it works correctly.

Thanks everyone for your help in trying to figure this out!


Very likely because of HSTS - you have visited your HTTPS version previously, so you never actually hit HTTP while doing that test with your browser.


Yeah, maybe. I was under the impression that even with HSTS you’d hit the http version in incognito mode, but perhaps not.


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