Client false positive: Port 80 in use on irrelevant IPs


In standalone mode, the client declares a failure if port 80 is in use – seemingly on ANY interface – when, in fact, only the IP address(es) being validated should need to be checked and used.

When making a request, it shouldn’t be necessary to stop all web services on the system, particularly those that are bound to port 80 on IP addresses that have nothing to do with the request being made. Thanks!


…and how does the client know which IP addresses are relevant and which are not?


There are two related issues open for this:

As a workaround, I would recommend using the --webroot authenticator in the meantime.


@pfg: Sorry I missed those open issues! Thanks very much.


@danb35: Obviously a process listening on a wildcard address and port 80 would be relevant. When that’s not the case, since the client already looks up IP addresses of the hostnames involved, it can simply check for processes listening on THOSE addresses and port 80. No?


Where does the client look up the IP addresses? That’s done by the CA, isn’t it?


Strictly, address translation, particularly a fully symmetric translation, might mislead you here

For example, suppose I have a NAT device at the edge of my network which turns into and vice versa and internally all my servers believe they’re using this network. As far as any random HTTPS client is concerned, including Let’s Encrypt’s boulder service, my servers have addresses like but on the servers there’s no sign of that address, just

This is probably a relatively rare case, but today I think it works fine with the Let’s Encrypt client so long as you’re not serving different sites from different addresses on the same machine. I know it’s happening in the wild because in my day job we do this of translation on a much larger scale, though we don’t (yet?) use Let’s Encrypt.


You make it sound so rare. That’s actually the vast majority of my cases, hence my raising the topic in the first place. For me, it would be ideal if the client in standalone mode could be specifically given an IP address and port to which it should bind in order to receive the request it is expecting. It also seems to me that such binding parameters would also be useful in a NAT or otherwise translated case, too, since it’s not always obvious (or even determinable, on further reflection) to which IP and port the standalone client should bind in order to receive the expected request.


Replying to myself, because I realized using the IPs resolved from the SANs is not sufficient. As occurred to me while making my previous reply in this thread, it would be ideal if the standalone client could be specifically told which IP and port it should use for listening.


I agree. I’ve added that comment at Thanks!


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