I think this just needs clarification in the documentation, but I'd appreciate a confirmation that I undertstand this all before I create a bug and attach a patch.
I'm running a series of web servers fronting a bunch of backend appservers. Many of those are accessed via mod_proxy in some fashion, usually with several backing nodes. The links between the web servers and the backends are encrypted with TLS, and have proper certificates signed by a CA that match the nodes they run on (ex. cn = box235a4c.example.com). Web traffic comes in via load balancers, to which the end users to connect with something like https://servicename.example.com. The proxy/balancer definitions are using the hostnames that match where the backends run (as per the backend above). My current configuration includes this: SSLProxyVerify require SSLProxyCheckPeerCN off SSLProxyCheckPeerName off Under 2.4.18, the SSLProxyCheckPeerCN and SSLProxyCheckPeerName options are defaulting to on, and preventing access to these services. From what I can gather, to validate proxy certificates against the hostnames specified in the configuration file, the admin must now specify all 3 lines above, instead of just the first (a change from 2.2?). Otherwise, for verification purposes, the hostname the admin has explicitly supplied will be ignored and that value will instead be matched against what the end user provides via the host header. Different discussion: Doesn't this default behavior allow the end client limited probing capability behind the web proxy when the SSLProxyCheckPeer* options aren't set to off? Rick Houser Web Administration
