> Envision a TCP load balancer routing TLS-crypted traffic across a number > of internal hosts, with each of the named virtual hosts presenting the correct > certificate, and known to httpd by their ServerAlias on the outer-facing > interface. > Not terminated at the edge balancer.
We are using IP/port based vhosts and ServerName directive, but yes, that's one example. In our current config, the load balancer is talking to a lot of vhosts using TLS with a single host-specific certificate. From my perspective, the underlying problem is merely attempting to associate the ServerName with the certificate at all, since they belong at different places in the protocol stack. The ServerName needs to be set to the externally facing endpoint of the infrastructure (the encapsulated HTTP traffic), and the certificate needs to be correct for the local TLS link. I know of no reason from a technical/protocol perspective that there couldn't be a dozen different hops in between (ex. application-layer firewalls, virus scanner, reverse proxies, etc.). My understanding is that using ServerAlias instead of ServerName would potentially leak information about the host, via server generated content. The documentation seems to reinforce this (https://httpd.apache.org/docs/2.4/mod/core.html#servername ). From a pragmatic approach, lay users will not be encountering this type of configuration, so keeping the message at a more verbose level still makes some sense and could help identify a legitimate misconfiguration. IMO, a production system should be able to run with info level logs without blowing up on false positives, however. Rick Houser Web Engineer
