421 Misdirected Request with FQDN (domains with trailing dot) with SAN

[fdelapena]

This is tightly related to https://bz.apache.org/bugzilla/show_bug.cgi?id=58007 which is still reproducible on latest httpd 2.4.x series. Possibly interesting as well: https://bz.apache.org/bugzilla/show_bug.cgi?id=60969

When setting modmd in a .conf file, even when adding all md* settings before virtual hosts, it's triggering this issue when trying to open e.g. a 2nd virtualhost fqdn from browser, e.g. https://foo.example.org. after a https://bar.example.net. is set, like it was setting per-vhost instead of a common setting for all of them. This could even like a mod_ssl limitation. I can confirm all FQDNs work properly when using mod_ssl without per-vhost ssl settings. Anyways, when testing TLS with external clients, no SNI looks involved.

Maybe it's better to fix this behavior in mod_ssl or httpd instead of working around mod_md, however it was not possible to find a workaround to make mod_md work with FQDNs.

[icing]

What is the mod_md related problem? Should we document that configurations for the module and virtual hosts should not use the FQDN with a trailing dot?

[fdelapena]

All virtual hosts were configured without trailing dot, so is not related to configuration that requires documentation updates. The trailing dot triggers the issue when added client side (e.g. browsers).

Problem with mod_md is, if you configure certificates with two or more subdomains, the subsequent virtualhost won't load if you add a trailing dot when accessed from the browser. E.g. this pair works as expected, but in affected subdomains the fqdn version would return HTTP 421 if used mod_md:

https://httpd.apache.org/ https://httpd.apache.org./ (fqdn version)

For example:

MDomain example.org www.example.org

<VirtualHost *:443>
    ServerName example.org
    DocumentRoot /var/www/example.org
</VirtualHost>

<VirtualHost *:443>
    ServerName www.example.org
    DocumentRoot /var/www/example.org
</VirtualHost>

Browsing to https://www.example.org./ would fail. Similar configuration with mod_ssl will work unless you add SSL settings inside virtual hosts, e.g. downgrading to TLS 1.2 for a specific virtual host. This seem to happen with mod_ssl when setting SSL* configuration parameters on virtual hosts that potentially imply SNI, even when apparently there is no SNI involved if unused (client certificate authentication with TLS reauthentication, for example).

The trailing dot on clients is mostly unknown nowadays (and most sites have broken support on them), however it is a protection for the search path spoofing attack: on a malicious network with bad DHCP, the assigned DNS resolver could fail to resolve e.g. https://example.com/ and have set a search domain, e.g. badsearchdomain.example, making the request forwarding to https://example.com.badsearchdomain.example/, while https://example.com./ would prevent that redirection and just failing to resolve. The user might not realize of the domain change and get scammed. DNSSEC does not help here if the DNS server has it disabled and the local resolver does not enforce it (usual default on most OSes).

I did not test this with MDBaseServer on, could potentially workaround this issue. However, I'm not using mod_md currently due to this issue for further testing attempts.

[icing]

Sorry, but I still fail to see how SNI and virtual host selection has anything to do with mod_md. The module "just" provides certificates to mod_ssl and that module does select the server config to use based on the SNI and its configuration.

If you see something wrong with that behaviour, you should open an issue against httpd itself and mod_ssl in particular. The 421 response, internally the define HTTP_MISDIRECTED_REQUEST, is used in http_protocol.c and ssl_engine_kernel.c only. You might have observed 421 in your tests with a config involving mod_md, but that does not make the module do anything wrong.

If I am wrong on this, please point me to the code that you regards as faulty.

[fdelapena]

Thanks, then I'll add some comments on https://bz.apache.org/bugzilla/show_bug.cgi?id=58007 on how to reproduce this issue in detail in latest version yet, and how mod_md gets affected, besides how to reproduce it with plain mod_ssl and how to work around it.