Trouble verifying domains


I’ve been accepted to the beta, but I’m having trouble getting my cert set up. I’m using nginx, so I know I have to do it manually. I’m running the following command:

./letsencrypt-auto --agree-dev-preview --server certonly -d

I’m getting the error:

Failed authorization procedure. <domain> (dvsni): connection :: The server could not connect to the client for DV :: Failed to connect to host for DVSNI challenge

When I enable verbose logging, I get the following:

   x /etc/letsencrypt/keys/0008_key-letsencrypt.pem                       x
   x Creating CSR: /etc/letsencrypt/csr/0008_csr-letsencrypt.pem          x
   x Starting new HTTPS connection (1):      x
   x Starting new HTTPS connection (1):      x
   x Performing the following challenges:                                 x
   x http-01 challenge for                                 x
   x Waiting for verification...                                          x
   x Starting new HTTPS connection (1):      x
   x Starting new HTTPS connection (1):      x
   x Starting new HTTPS connection (1):      x
   x Reporting to user: The following 'connection' errors were reported   x
   x by the server:                                                       x
   x Domains:                                              x
   x Error: The server could not connect to the client for DV             x
   x To fix these errors, please make sure that your domain name was      x
   x entered correctly and the DNS A record(s) for that domain            x
   x contain(s) the right IP address. Additionally, please check that     x
   x your computer has a publicly routable IP address and that no         x
   x firewalls are preventing the server from communicating with the      x
   x client.                                                              x

Finally, I tried using -a manual to manually complete the ACME challenge, but it’s not working there either. I know routing and DNS are set up correctly, and I’ve verified with Wireshark that the challenge Content-Type is text/plain as required. Nevertheless, on attempting to complete the manual verification I get:

x Saving debug log to /var/log/letsencrypt/letsencrypt.log             x
x Starting new HTTPS connection (1):      x
x Generating key (2048 bits):                                          x
x /etc/letsencrypt/keys/0019_key-letsencrypt.pem                       x
x Creating CSR: /etc/letsencrypt/csr/0019_csr-letsencrypt.pem          x
x Starting new HTTPS connection (1):      x
x Starting new HTTPS connection (1):      x
x Performing the following challenges:                                 x
x http-01 challenge for                                 x
x Starting new HTTP connection (1):                     x
x Self-verify of challenge failed, authorization abandoned.            x
x Waiting for verification...                                          x
x Cleaning up challenges                                               x

EDIT: To clarify, I’m running this server at home, and I have forwarded ports 80 and 443 from the router. I have verified that both ports are open and accessible.


If you are running this command with “” it will fail, because you do not own that domain. You would need to run it with your own domain instead.


@jsha I’m not using I replaced my domain here for the examples.


Got it, thanks for clarifying. Just to make sure: Once your certificate is issued, it will be submitted to Certificate Transparency logs, publishing your domain name. Also, according to the Let’s Encrypt privacy policy, the IP addresses used to access the service are not considered private information and may be published in the future. So if you consider your home IP address private, you may want to issue from another IP.

Now, with all that out of the way: The simple_verify in Python attempts to fetch the file from the server you are running it on. Have you confirmed your server can reach itself using the name “” and port 80? If port forwarding is involved, it might have trouble reaching itself.


Ya, I’m okay with the tracking. It gave me a big warning when I tried to do the manual verification.

I have confirmed I’m able to access port 80 on the machine itself from the machine itself. First with telnet by starting nginx and connecting to port 80, then with a wget. Both connections were successful. Just to confirm, I have been stopping nginx each time I attempt the certificate creation. It won’t let me try to create the cert with nginx running.

Could it be an issue of python versioning? I had to create aliases for python and python2 to python2.7.10, since the server currently has 2.7.6 as the default python version and urllib3 cried that it wasn’t a current enough version. Is there another alias or python command that I’m forgetting to redirect?


I don’t think it’s likely to be the Python version, although I work on the server side rather than the client side, so take my advice with a grain of salt.

Additional -v flags cause additional levels of verbosity. Try running with -vvvv?

Also, one issue I’ve had with my own instances: Is it possible that you have a firewall allowing access to port 80 from certain IP addresses but not others? Does your domain resolve to multiple IP addresses?


Here are the results with the -vvvv flag


And it only resolves to that one address, and as far as I know there are no firewalls blocking anything from any address.


Trying to fetch that site from my laptop I get a connection timeout:

$ nslookup

Non-authoritative answer:

$ curl
curl: (7) Failed to connect to port 80: Connection timed out


Ah. You are correct. Looks like when I tried to verify using my VPN that it was working from the outside, I was getting cached pages instead. My ISP appears to be blocking port 80. Is there a way to use a non-standard port to do the certificate creation?


SUCCESS! Using the configuration file, I was able to route the verification to port 443 with the following commands:

authenticator = standalone
standalone-supported-challenges = tls-sni-01

The ISP has left 443 alone, so everything worked wonderfully. Thank you @jsha for all your help.


You’re welcome, glad you got it working!


Is this possible to do with non standalone? i got webroot working fine with nginx listening on port 443, but I can’t get letsencrypt to check https instead of http (my isp also blocks port 80)

I think i can get the standalone server to listen to a different port using --tls-sni-01-port 4443 and proxy_pass https://localhost:4443 to that port but that gives me The client lacks sufficient authorization :: Correct zName not found for TLS SNI challenge


current implementation of webroot is over port 80 http as port 443 https has security flaws and no longer used for webroot


Is this going to be addressed at some point? or will it always be the case and I need to find a new solution?


only LE folks would know but i take it has will be always over http port 80 for webroot right now


This also happens for me. I get “could not connect” unless I use --tls-sni-01-port 4443 and then I get “Correct zName not found”


The IP should be masked before going public, at least the last octet.