Certbot nginx plugin - error getting validation data

[Cronnay]

I’m having a problem with the TLS-SNI-01, and I believe it’s nothing wrong with the DNS. If I connect to the IP or domain, I get the same website.

> Failed authorization procedure. zoomicweb.com (tls-sni-01): urn:acme:error:connection :: The server could not connect to the client to verify the domain :: Error getting validation data

I am using the nginx plugin.

What can I do?

[cpu]

Hi @Cronnay,

I split this post into a new thread since it seems unrelated to the original and its easier to help you with your specific problem in a dedicated thread.

Checking the logs from the server side I see that the underlying error is “No route to host” for the resolved IPv4 address (185.196.38.5). From my own laptop I’m able to ping this IP but not connect to it with openssl s_client:

$ openssl s_client -connect 185.196.38.5:443 
connect: No route to host
connect:errno=113

I’ve asked our operations folks to see if they can suggest a course of action but presently it seems like there are routing issues affecting connections between your server and a few network vantage points (most importantly the Let’s Encrypt validation authority).

Do you have any suspicions about what it could be?

[isk]

@cpu

openssl s_client -connect 185.196.38.5:443

Running some tests from the VA, it looks like there are intermittent connectivity problems. Sometimes resulting in no route to host and sometimes getting connection refused. I'd expect the connection refused just means the server is no longer presenting what the VA expects, but the no route to host is the bigger problem.

[Cronnay]

Unfortunately I am not really familiar with devops, so I cannot really tell what the problem is.

If it helps; I followed this guide to help me set ut my server
https://www.phusionpassenger.com/library/walkthroughs/deploy/nodejs/ownserver/nginx/oss/el7/deploy_app.html

I am using CentOS7

[schoen]

@cpu

I've asked our operations folks to see if they can suggest a course of action but presently it seems like there are routing issues affecting connections between your server and a few network vantage points (most importantly the Let's Encrypt validation authority).

I believe the "No route to host" error could be a red herring. I don't know what particular network stack does this but I've seen cases where connecting to one port returns "No route to host" and another connects successfully. Indeed, that's what I see on this machine right now: connecting via port 80 works and via port 443 doesn't, giving a "no route to host"! This is then not actually an IP routing problem at all.

http://www.pcvr.nl/tcpip/icmp_int.htm#6_6 says that many different ICMP errors are translated into the Unix error "no route to host" (making this error potentially quite misleading in this regard).

I ran a packet sniffer while trying to connect to this host and I saw ICMP code 10 ("Host administratively prohibited"), which my OS nonetheless displayed as "No route to host" even though I don't regard that as a good explanation of the actual ICMP message. (Also, maybe this means that Boulder should somehow try to log this error more specifically, if the sockets interface provides any way to get that detail, although I'm not at all sure that it does.)

Anyway, this suggests a firewall problem to me.

[cpu]

@schoen

I believe the "No route to host" error could be a red herring. I don't know what particular network stack does this but I've seen cases where connecting to one port returns "No route to host" and another connects successfully. Indeed, that's what I see on this machine right now: connecting via port 80 works and via port 443 doesn't, giving a "no route to host"! This is then not actually an IP routing problem at all.

http://www.pcvr.nl/tcpip/icmp_int.htm#6_6 says that many different ICMP errors are translated into the Unix error "no route to host" (making this error potentially quite misleading in this regard).

Wow! Thanks for the information. I wasn't aware there were so many conditions that could manifest this particular error and always interpreted it at face value.

@schoen

(Also, maybe this means that Boulder should somehow try to log this error more specifically, if the sockets interface provides any way to get that detail, although I'm not at all sure that it does.)

Good idea - I opened Handle "no route to host" during validation as a specific error type. · Issue #2879 · letsencrypt/boulder · GitHub for this. We'll have to discuss internally whether it meets the bar to skip the v1 feature freeze.

@schoen

Anyway, this suggests a firewall problem to me.

This definitely seems like the most likely explanation. @Cronnay, are you aware of a firewall that you or your hosting provider may be running that needs to be configured to allow traffic on port 443?

Thanks again @schoen!

[Cronnay]

It looked like I fixed it!

I must’ve forgotten to open the 443 port.
So my website works fine now, it’s just routing that seems to be a problem. As mentioned earlier, I’m not really familiar with linux, or devops in general.
But I’ll find something!

[schoen]

I don’t think there was ever really a routing problem. It’s just that an old Unix tradition has mapped many different site-connection errors from ICMP to the same error message, “No route to host”, even though that doesn’t correctly describe all of them. So I think the only problem was not opening port 443.

[Cronnay]

Sorry, I must have been unclear.
I meant that I have a current routing problem, so I get error 404 on everything but “/”.

The https works, its fine!