> One would need something like "SSLNameIndicator x.internal.net" to make that > disconnect clear, it seems.
If going so far as to add a new directive, I would personally prefer disabling the check rather than adding another to get around this. That could be done with a Boolean directive. For a more flexible approach going forward in 2.6, what do you all think about the idea of adding a new directive to re-define a log statement's level at runtime? This would have made both these log issues a minor inconvenience for end users and easily addressable via the documentation for my specific case. Something like this: LogMessageReduce <APLOGNO> <LEVEL> If such directives are present, log entries would consult a table and substitute the logging level inside ap_log_error for any matches. I can't see this working without an interface change in ap_log_error to get directly at the number, however. Obviously, this function is called a LOT, so there is potential for slowdown depending on how it's written. I would personally write this as a reduce only function, so the lookup checks never happen unless a log message would have been written, in which case it would be overshadowed by the log write itself. Rick Houser Web Engineer > -----Original Message----- > From: Stefan Eissing <stefan.eiss...@greenbytes.de> > Sent: Thursday, September 20, 2018 09:57 > To: dev@httpd.apache.org > Subject: Re: minor nit in mod_ssl > > EXTERNAL EMAIL > > > > Am 20.09.2018 um 15:31 schrieb Houser, Rick <rick.hou...@jackson.com>: > > > >> 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 >
