Failed to connect to x.x.x.x:443 for TLS-SNI-01 challenge

Server
#1

I’m pulling my hair out trying to troubleshoot this, because I can’t see what the LE server is trying to do. All I get back via the certbox client is an acme failure, saying

(tls-sni-01): urn:acme:error:connection :: The server could not connect to the client to verify the domain :: Failed to connect to x.x.x.x:443 for TLS-SNI-01 challenge

In itself, that points squarely at a communication problem, and would suggest that my server is not listening on that IP address and port, but I can access that same website from my phone (via 4G), through the internet, via looking glass servers from all over the world, etc. There is clearly no general communication problem, yet I never see an incoming packet to tcp/443 (or tcp/80) during the time the client is waiting for a reply. It’s like it just doesn’t try.

The IP address stated in the message is correct, and DNS resolution is working. That DNS entry has been working for years, so it’s not a new entry.

Looking at https://tools.ietf.org/html/draft-ietf-acme-acme-01#section-7.3, it appears that I should be getting an incoming https connection, but when packet sniffing on my outside interface,I don’t even see a SYN to 443, let alone https.

Yet, if I run it in --manual mode, and copy the well-known URL, and then access that from work (different ISP), it works just fine, and I see a tcp 3whs, an https TLS negotiation, and an entry in apache’s log file, so I’m at a loss to explain what acme is trying to connect to. It certainly doesn’t seem to be my webserver.

#2

Could you share the certbot command you’re running?

If this is an actual network issue, it could be caused by anything between your server and Let’s Encrypt’s validation server. Maybe there’s some routing issue, maybe your ISP is filtering traffic from Let’s Encrypt’s validation server (some kind of false-positive), etc. Very hard to debug. :pensive:

I’d also be curious if you’re able to ping outbound1.letsencrypt.org. That’s where the validation request should be coming from.

#3

I guess the external IP and domain are public information anyway, so I’ll include them. Layer 3 to outbound1 is fine, though that doesn’t preclude a block on tcp/443. Having said that, I’ve tested from various sites I have access to around the world, and they have no problem getting to it.

root@www:~# ping outbound1.letsencrypt.org
PING outbound1.letsencrypt.org (66.133.109.36) 56(84) bytes of data.
64 bytes from outbound1.letsencrypt.org (66.133.109.36): icmp_seq=1 ttl=241 time=146 ms
64 bytes from outbound1.letsencrypt.org (66.133.109.36): icmp_seq=2 ttl=241 time=146 ms
64 bytes from outbound1.letsencrypt.org (66.133.109.36): icmp_seq=3 ttl=241 time=149 ms
64 bytes from outbound1.letsencrypt.org (66.133.109.36): icmp_seq=4 ttl=241 time=147 ms
64 bytes from outbound1.letsencrypt.org (66.133.109.36): icmp_seq=5 ttl=241 time=146 ms
64 bytes from outbound1.letsencrypt.org (66.133.109.36): icmp_seq=6 ttl=241 time=149 ms
64 bytes from outbound1.letsencrypt.org (66.133.109.36): icmp_seq=7 ttl=241 time=147 ms
64 bytes from outbound1.letsencrypt.org (66.133.109.36): icmp_seq=8 ttl=241 time=147 ms
^C
--- outbound1.letsencrypt.org ping statistics ---
8 packets transmitted, 8 received, 0% packet loss, time 7008ms
rtt min/avg/max/mdev = 146.474/147.749/149.461/1.085 ms

root@www:~# ./certbot-auto -d dev.oddtech.co.nz
Failed authorization procedure. dev.oddtech.co.nz (tls-sni-01): urn:acme:error:connection :: The server could not connect to the client to verify the domain :: Failed to connect to 43.245.175.11:443 for TLS-SNI-01 challenge

IMPORTANT NOTES:
 - The following errors were reported by the server:

   Domain: dev.oddtech.co.nz
   Type:   connection
   Detail: Failed to connect to 43.245.175.11:443 for TLS-SNI-01
   challenge

   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.
#4

I’m getting a timeout with telnet dev.oddtech.co.nz 443, both from my residential ISP and from within OVH’s network. The IP matches yours.

#5

Aha… I’ve found some tangible evidence that 443 is blocked by something outside my control, but only for parts of the internet. For example, these people can get to my smtp server, but not to my website.

http://mxtoolbox.com/SuperTool.aspx?action=scan%3A43.245.175.11&run=toolpage

Thanks for confirming you also can’t get to it. What country are you testing from ?

#6

It’s an Austrian ISP, the OVH server is located in France.

#7

Cheers. I suspect my ISP is doing something silly… I’ll take it up with them. Thanks

#8

In case this turns out to be out of your control to fix: If you have programmatic access to your DNS (as in: an API to add TXT records), you can use DNS-01 validation with one of the alternative clients like lego.

#9

Thanks. I may have to resort to that, but now I know I’m being blocked, I want to get to the bottom of that too.

#10

Fixed. My ISP was trying to be helpful by blocking “dodgy” traffic by default. Filter now removed :slight_smile:

#11

I’m having this same issue, I’m unable to renew my certificate
I entered:

 ./certbot-auto --standalone-supported-challenges tls-sni-01

after selecting the subdomains I get the same error as mentioned above.

I tried PING outbound1.letsencrypt.org and get a response
I’m trying to renew for the domain www.grippa.nl

anybody an idea because I already pulled all of my hair out and read lots of solution on this forum but till now with no result.

#12

Could you post the full error message just in case? There could be small differences that might be relevant. I’m assuming the way you perform renewal is to stop the web server that’s currently running and listening on port 443 before you run certbot in standalone mode? You might want to look into switching to the webroot plugin in any case, which doesn’t force you to stop your existing web server for renewal. Maybe it’ll solve the problem you’re currently having as a nice side-effect. :smile:

FWIW I have no trouble connecting to port 443 of your domain.

#13

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