httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Houser, Rick" <>
Subject SSLProxyCheck* behavior
Date Thu, 07 Jan 2016 16:44:17 GMT
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 =

Web traffic comes in via load balancers, to which the end users to connect with something
like  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

View raw message