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.
@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 216.58.213.128/25 into 10.4.8.0/25 and vice versa and internally all my servers believe they’re using this 10.4.8.0 network. As far as any random HTTPS client is concerned, including Let’s Encrypt’s boulder service, my servers have addresses like 216.58.213.132 but on the servers there’s no sign of that address, just 10.4.8.4
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 https://github.com/letsencrypt/letsencrypt/issues/255. Thanks!
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.