because LE's error message says IP address it tried and most time clients are running on same server if it uses http or tls challenge, I think it would make sense to warn user that on fail log that client doesn't think that domain was pointed to us. not sure what reasonable way to detect when there is various NAT masks outside IPs though, one idea is try pinging address from log and trigger message if it took over 3~5 ms, but we may have wireless servers so even that isn't conclusive.
3 Likes
Display and have them visually compare:
- the
dig/nslookupresults for theirFQDN - the
ifconfig.io/ifconfig.meresults from their system
4 Likes
I mean, I could see some value in a client integrating the Let's Debug API and offering to use it, along with things like making sure the authoritative DNS servers are responding with an IP that seems to come to where the client is running. Though various NAT/portmapping/split-DNS/etc. scenarios can make it hard to avoid false positives, so it's probably more something to offer as help if things aren't working rather than something to require passing before attempting requesting a certificate.
But certbot often says things like "Ensure that the listed domains point to this Apache server and that it is accessible from the internet.", and people post here because they need help understanding that the listed domains aren't pointing to their server or that it's not accessible from the internet, so there's only so much one can do, too.
6 Likes
I think what @orangepizza was suggesting is that when an ACME Client sees an error from LE about connection problem (e.g., timeout) it lists an IP address.
The Client could parse that message and check whether that IP address is actually the public IP. The Client could then give specific advice to correct that. As it is, we just have the generic "probably a firewall" warning for timeouts and more obscure info on others (like "error getting data").
Manually we often suggest running something like curl https://ifconfig.io to confirm IP. Not a good idea to rely on that specific service. But, LE or Let's Debug could offer a similar service. Still, because of outliers we may just offer better advice to some while offering more confusing advice to others.
5 Likes
I would argue that LE is offering that service, and by telling you that it couldn't connect to your site it is explicitly telling you that the IP address in DNS isn't working as expected. 
A significant problem is that many people don't realize that their site isn't accessible, or at least not accessible for clients using IPv6 or DNSSEC or outside their ISP network or whatever, and think of it as a problem getting a certificate rather than a problem with connectivity in general.
It'd be helpful for ACME clients to assist, particularly if they can do things like suggest that the IPv4 and IPv6 addresses are pointing to different ASNs or that their DNSSEC is broken. But I'd argue that it might be even more helpful if web server software and control panels and whatnot did that too, since really most problems aren't really about certificates. (And of course, ideally certificate acquisition would be built into that web server software or control panel, rather than a bolt-on like certbot-style clients are, but I do understand that it's hard to change the whole world at once.)
5 Likes
I meant a service instead of https://ifconfig.io (or similar) which shows the public IP of the requester. Relying on 3rd party services is not a great idea for what I described.
We know the error message is something isn't working as expected. The idea was to do some of the debugging automatically rather than sending them here for the same advice 
Fully agree that connectivity problems are a large group of what we handle here. Any automated advice to help people with those is an improvement. Alas, it is unlikely to get added to enough Clients to help much even if it could be made practical.
Perhaps Let's Debug could offer something. It could parse the IP from an LE "comms" type error and show a message saying "Check this IP matches your public IP by doing blah blah"?
6 Likes
This seems like something ACME Clients could/should just implement for their own users.
6 Likes
What i thought in addition of that is acme client doing http challenges is in privileged position that it almost guaranteed to be same machine that site is host on. So unlike from letsdebug which may from admin's phone, acme client knows that LE was looked somewhere else, not me.
And for detecting nat now i think trying traceroute to ip le given and notifiy user if there is public IP hop: if it goes ISP router that wouldn't be ourselves.
4 Likes
I forgot to mention one bit of context here - One of the major Clients (IIRC, it was Certbot) initially had a feature in which the Client first tried to load an HTTP-01 Challenge before triggering the Authorization endpoint. If it could not load the expected challenge, it would then fail with a useful message alerting the user to a DNS or local configuration issue. IIRC, this feature got removed entirely as setups became more complex.
TLDR; Client(s) already did a variant of this, but removed it. It was very useful and made a lot of sense.
3 Likes
I think cPanel's AutoSSL did something like that?
2 Likes
cert-manager does a self-check for HTTP-01 and DNS-01 challenges: Troubleshooting Issuing ACME Certificates - cert-manager Documentation
lego validates DNS-01 records propagating too: Options :: Let’s Encrypt client and ACME library written in Go.
5 Likes
Perhaps I was thinking of acme-tiny and not Certbot - acme-tiny/acme_tiny.py at master · diafygi/acme-tiny · GitHub
5 Likes
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.