Configuration of dummy default vhost and prevent virtual host fallback with https requests to IP-PD host

Background

Consider 4 hypothetical FQDNs that all resolve to 192.0.2.42:

• example.com
• www.example.com
• foo.example.org
• legacy.example.net

Now, consider two hypothetical servers bound to 192.0.2.42 (obviously, not at the same time... I'm just illustrating two different scenarios):

• Server has one "site" that's the default. Any https request directed to port 443 of a FQDN that resolves to the server's IP address ends up mapping to it.

• Server has name-based virtual hosts enabled. The vhost to which example.com and www.example.com is the catch-all default. foo.example.org and legacy.example.net are mapped to two other vhosts.

The Problem:

Requests to https://example.com, https://www.example.com, https://foo.example.org, and https://legacy.example.net all work as expected... but two undesired side effects exist as well:

• https://192.0.2.42 (what RFC-9110 calls an "IP-PD reference identity") falls through to the default site after the browser displays a warning & the user swats it away. Strict-Transport-Security headers won't save the day.

• An attacker can point a domain under his control (say, "badguys.example") to 192.0.2.42, send the user to https://badguys.example, and (assuming the actual FQDN is a bit less blatantly bad, the browser itself is buggy, and/or the user is a complete idiot), and the same scenario as 192.0.2.42 comes into play. Once again, STS won't save the day.

The Solution (the devil's in the details)

From what I understand, the proper solution is something along the following lines:

• Enable name-based virtual hosts, if not already done.

• Create a "dummy-default" vhost that catches all requests that aren't explicitly mapped to one of the "real" vhosts.

• Configure SNI. Among other things, the default vhost is responsible for presenting a TLS cert with example.com, www.example.com, foo.example.org, and legacy.example.net in the SAN

The gory details?

• The default vhost needs a unique FQDN of its own that resolves to 192.0.2.42 (as opposed to 127.0.0.1, or some other IP address... otherwise, SNI will fail.) Right?

• It doesn't have to be GLOBALLY DNS-resolvable... it's good enough to just stuff it into /etc/hosts on the server running Apache (or Nginx, or Tomcat, or whatever the server is running). Right?

• The default vhost's FQDN (say, "default999.example.com") needs to be in the SAN, along with the other 4 names. Otherwise, when Apache (or whatever) goes to start up, it'll sanity-check the cert for its default host & crap out if everything isn't 100% perfect. Right?

• It de-facto has to be a subdomain of a TLD under the organization's control (like "default999.example.com"), because no CA will allow you to stick an IP address or a hostname that isn't both theoretically DNS-resolvable AND under a TLD you demonstrably own & control) into the SAN. Right?

• Assuming the desired behavior for the default vhost is, "handle all requests by returning a 4xx status code"... which one is, in fact, the most appropriate?

  • 421?
  • 422?
  • 400?

Before I went to really scrutinize the list of 4xx response codes, I thought for sure there would be at least one that specifically relates to vhosts and explicitly means something like, "You made a http(s) request to a URL whose FQDN resolves to the IP address of this server, but this server has not mapped it to a site and is therefore returning this error."

Except... as far as I can tell, over the span of approximately 25+ years since Apache first introduced name-based virtual hosts, nobody involved with IETF (or Microsoft, Apache, or anyone else) has apparently ever thought errors specific to them were important enough to merit a proper http response code of its own. 421 or 422 almost seem to match... but after reading their official definitions (RFC 9110), I'm not so sure.

• It sounds like 421 only applies to http2 requests in scenarios where the user agent combines requests for two vhosts on the same server that the server itself refuses to allow to be combined.

• It sounds like 422 is only supposed to be used in scenarios where you're encoding a request to the server as xml in the body of a request

• I've seen a few posts here suggesting 404... but to me, 404 has always meant, "good site, bad file". Maybe I'm being pedantic, but it just feels viscerally wrong & inappropriate to return 404 when the host itself is invalid.

So... does 400 (Invalid Host) sound like the best choice, or can someone think of a better one?

Finally... getting back to the most important part of the question... am I correct about having to give the default vhost a real fqdn that's listed in the SAN? At least, with Apache, Nginx, and IIS?