Allow MDPortMap for virtual hosts, or disable the port check

[mkauf]

Multiple virtual hosts can listen on different IP addresses, so the port mapping may differ for each virtual host. Currently "MDPortMap" is a global setting.

It would be an improvement to have the "MDPortMap" setting for each virtual host. But then mod_md also needs to check whether there are contradicting port mappings for virtual hosts that are on the same IP address, so this would make the code more complex.

An easier solution would be a new configuration setting to disable the port check, so that mod_md just assumes that all managed virtual hosts are reachable for Let's Encrypt. We could call this setting "MDPortCheck".

[icing]

I agree that MDPortMap currently has a too simplistic view for multi-homes hosts settings.

With the abolishment of the 'tls-sni-01' challenge, all current challenges use the domain to be verified either in Host: or SNI. That means the port number itself is not really interesting, only the fact of the domain can be used in http: and/or https: requests/connections.

Currently, a configuration of MDPortmap http:80 just adds http-01 challenge types to the options available and nothing more. It is overly specific. Something like

MDPublicAccess http https
MDPublicAccess none

would maybe serve better, configurable global or per MDomain.

I think I draw the line at MDomains where individual VirtualHost vary in accessibility. Such a setup can be done, but that leads to overcomplications in the module. Split such an MDomain in two, I would recommend.

What do you think?

[mkauf]

I like this idea 👍 It's easy to use and powerful enough.

[icing]

Hmm, I think I need to backtrack a bit here. This is a larger change than thought at first.

Right now, mod_md uses the http: and https: ports also to make a guess if a VirtualHost uses SSL or not. Which is not really correct in all cases as well. I have an idea how to have a more reliable detection without specifying ports, but that does not fit on the margins of this page...

[icing]

Ok, after more work and more thinking and reading your first post again, I think it has less complexity and the same freedom if users of such multi-homed setup configured the challenges directly.

So, if you have an MD that might look available to other challenges, but is not, you configure

MDCAChallenges http-01

for it and no other method will be used. mod_md will also refrain from questioning your choice. So, it will not try to be smart and check ports in such cases. The auto-configuring out the challenges to use (and port checks on availability) will only run when no challenges are specified.

This allows also for some esoteric setups. For example you can have a separate http: server that just answers challenges, using the thumbnails of account keys.

WDYT?

[mkauf]

Sounds good! Configuring the challenges needs some knowledge about which ACME challenges work in which cases. The documentation is a bit outdated, it does not explain that tls-alpn-01 is for port 443, see the "prerequisites" section on https://httpd.apache.org/docs/trunk/mod/mod_md.html

With updated documentation, I think that's a good solution 👍

[icing]

Ok, updated README and the Apache documentation in trunk. Although, I can describe this particular behaviour there only after copying the 2.1 over.

I leave this issue open until this has happened.

[icing]

Updated in Apache subversion in r1868506.