https://issues.apache.org/bugzilla/show_bug.cgi?id=55866
Bug ID: 55866
Summary: When ProxyPreserveHost is on, SSL expects the wrong CN
from the backend
Product: Apache httpd-2
Version: 2.4.4
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: P2
Component: mod_proxy_http
Assignee: [email protected]
Reporter: [email protected]
Consider the following sample configuration for Apache running on
front.example.com:
SSLProxyEngine on
...
<Location /foo/>
Require all granted
ProxyPreserveHost on
ProxyPass https://back.example.com/foo/
</Location>
Accessing http://front.example.com/foo/ will cause an SSL-connection to be
opened from front to back, as expected.
Unfortunately, the SSL-engine on the client-side (on front) will expect the
certificate presented by the back to contain "front.example.com" in its CN,
rather than the "back.example.com":
AH02005: SSL Proxy: Peer certificate CN mismatch: Certificate CN:
back.example.com Requested hostname: front.example.com
This is not happening, when ProxyPreserveHost is set to off, as is the default.
As a work-around, one can set SSLProxyCheckPeerCN to off, but that defeats most
of the usefulness of SSL between front and back.
The fix would change things so that the proxy-code still passes the original
front.example.com in the Host:-header (because the ProxyPreserveHost is set to
"on"), but expects the back.example.com in the CN of the certificate returned
by the back end.
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
