https://issues.apache.org/bugzilla/show_bug.cgi?id=55866
--- Comment #3 from Mikhail T. <[email protected]> --- (In reply to Yann Ylavic from comment #1) > If your backend does not use the same host name (and hence certificate CN) > the client is requesting on the frontend, you shouldn't use > ProxyPreserveHost (or expect SSLProxyCheckPeerCN to accept the peer > certificate). I'm using ProxyPreserveHost because the back-end's behavior depends on the Host-header, that's simple enough. In our particular case, the back-end needs to set a cookie for mod_auth_form. Though cookie-verification happens on the front-ends, the cookie-settings is proxied to the central server. That central server is setting the same cookie for dozens (if not hundreds) of domains. Placing them all into its certificate -- and remaking the certificate each time a new front is added -- is impractical. The cookie-issuing back should not even need to know about all possible fronts -- indeed, there may be an infinite number of them. Nor should it be necessary -- the purpose of using SSL on the proxy->back connection is to ensure the integrity of THAT connection only. The client->proxy may or may not even be using SSL at all, but the SSL's rejection of the back-end should signal the danger of back-end having been hijacked. Disabling SSLProxyCheckPeerCN defeats the major purpose of using SSL -- allowing man-in-the-middle attack against the proxy->back connections. > Possible duplicate of Bug 54656. Well, they are related, yes. And I agree with William's comment-3 there. But whereas Bug 54656 seeks to add a new configuration directive to allow turning the alternative behavior on, I argue, that the current behavior is plainly incorrect and ought to be corrected. -- 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]
