Standalone configurator: Dealing with existing processes that are listening on some, but not all, interfaces

[schoen]

Currently the standalone configurator always tries to listen on 0.0.0.0, which is an error if any other process has the same TCP port bound on any interface (including the loopback interface!).

It would be useful to be able to enumerate interfaces in order to be able to bind only non-loopback interfaces in this particular case. It would also be useful to let the user specify an address to listen on using a command-line option.

There are also future consequences for IPv6 support in how this is handled. (I think the CA currently only performs DVSNI tests over IPv4.)

[jdkasten]

Has this been completely addressed @schoen? I know the dvsni-port has been implemented.

[schoen]

No, I haven't done anything on this; right now I think the client will complain if another process has the port bound at all.

[rfnx]

Is there any news on this ? Because on my server I have to shutdown multiple processes completly unrelated to HTTPS, because they use the 443 port.

Is it possible to check the DNS records before and only bind to interfaces needed for the validation ? This seems to be a good solution.

EDIT : or give the user an option to bind on a specific interface ?

[noloader]

Currently the standalone configurator always tries to listen on 0.0.0.0, which is an error if any other process has the same TCP port bound on any interface...

It might also be a security bug. Code audits often have an item to check for the equivalent to the special IP address INADDR_ANY to catch things like accidentally binding to a second interface used for remote system management and administration.

[jsha]

I think the right thing here is to add a flag to specify the IP address on which the standalone authenticator should listen.

Ideally we'd have done this instead of --dvsni-port, e.g. --dvsni-address=1.2.3.4:443. We could specify a new flag with those semantics and deprecate the old one, or we could add a new flag that specifies only the IP.

[Marqin]

@sbraz posted workaroud for this:

cd /var/tmp/webroot/ || exit
python -m http.server --bind xx.xx.xx.xx 80 &
pid=$!
letsencrypt certonly --webroot /var/tmp/webroot/ […]
kill $pid
sleep 0.5
kill -0 $pid && kill -9 $pid

[blark]

It would be really nice if --bind-address could be added as a command line switch rather than having to resort to the hacky workaround above.

[Estartu]

The workaround work's ok when getting a certificate. But what to do for renewal 3 month later. You have to do it all again by hand.

certbot could, if the listen on 0.0.0.0:443 fails, do a DNS lookup on the domain and try a bind on that IP.
The DNS lookup has the added benefit that the bind-address didn't need to be saved in the renewal config and there is no problem when the IP for the domain is changed later on.

[strugee]

@Estartu what about multidomain certs? Unless you want to rebind for every single domain

[strugee]

Besides, that workaround works just fine in a shell script. You don't have to do it by hand.

[Estartu]

@strugee why rebind? just try to open a socket on any IP returned by the DNS request for all domains. If one of the binds Fail the whole process fails. And By the way how is this handled when 0.0.0.0:443 is available?
How does the workaround handle multidomain certs on multiple IPs?

[sbraz]

@Estartu I'd suggest using iptables to redirect all the traffic to the secondary IP addresses to the main one.

[strugee]

@Estartu ah, I see. That'd work. Not sure what you mean by "this" in:

And By the way how is this handled when 0.0.0.0:443 is available?

I haven't tried the workaround but you might be able to pass --bind more than once and even if not, you could spawn >1 server. Hacky, certainly, but hey. It works :P

[Marqin]

Any updates on this?