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.
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.
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.
I’d also be curious if you’re able to ping outbound1.letsencrypt.org. That’s where the validation request should be coming from.
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.
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.
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.
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.
FWIW I have no trouble connecting to port 443 of your domain.