> Am 20.09.2018 um 15:31 schrieb Houser, Rick <[email protected]>: > >> 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 ).
You are correct. Using the externally visible name for ServerName seems best in your scenario. Thanks for explaining your setup. > 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. Totally agree. When using local TLS links between balancers/terminators and httpd boxes, it seems not possible to map that onto the existing configuration concepts that easily. Basically, the TLS is not end-to-end, but a tunnel to a "worker" httpd host that has its own name and own certificate which is used to serve requests for another hostname. In this scenario, the normally desired link between certificate alt names and servername gets in the way. One would need something like "SSLNameIndicator x.internal.net" to make that disconnect clear, it seems. -Stefan
