Tom Evans wrote: > On Fri, Apr 12, 2013 at 7:18 AM, Lam, Eugene <[email protected]> wrote: >> Hi Kaspar, >> >> Thanks for digging up that thread. I still think SNI needs to be >> considered, but not in the way I originally thought! >> >> On 4/10/13 9:43 PM, "Kaspar Brand" <[email protected]> wrote: >> >> On 10.04.2013 02:49, Lam, Eugene wrote: >> >> ssl_engine_io.c will pull out this note and use it for SNI and >> SSLProxyCheckPeerCN. Unfortunately, www.example.com does not match >> backend.example.com. >> >> >> I wouldn't call this unfortunate, I would say that it's a >> misunderstanding of what SSL proxying with mod_proxy_http is expected to >> provide. >> >> >> To help "iron out" any misunderstanding, I'll repeat what I know. There's >> at least 2 types of ways to configure mod_proxy_http. I'm only interested >> in the ProxyPassReverse, not ProxyPass. >> >> In the classic *reverse proxy* setup, the CN is always different between 1) >> the cert on the reverse proxy that terminated the original HTTP request and >> 2) the cert on the backend server terminating the backend HTTP request. In >> other words, the reverse proxy (responding to request for www.example.com) >> has already terminated the secure connection with the original HTTP >> requester. The reverse proxy is initiating a new connection with >> "backend.example.com", assuming "backend.example.com" is what appeared in >> the ProxyPassReverse directive. This is expected, right? >> >> When ProxyPreserveHost is off, everything works fine. The backend HTTP >> request's Host header would be backend.example.com, and mod_ssl sees a cert >> with CN=backend.example.com. This is the expected behavior and is the >> supported configuration. >> >> Turning on ProxyPreserveHost breaks this by affecting the Host header. It >> changes the backend HTTP request from the ProxyPassReverse value into the >> value of Host header the original HTTP requester. >> >> The reverse proxy shouldn't expect CN=www.example.com, >> CN=www.example.org, etc. when the backend only has >> CN=backend.example.com. >> >> > > I must be missing something. With ProxyPreserveHost, the backend must > respond to requests for the frontend hostname. If so, and you wish to > use SSL for the proxy connection, you should set up the backend so > that it does have the required certificate, or don't use > ProxyPreserveHost. > > This whole thing seems to be "I told the proxy to treat > backend.example.com to act as www.example.com, backend responds to > www.., but I didn't give it www's certs, so validation fails". > > Using ProxyPreserveHost implies that the backend will correctly > respond to requests with the frontend's hostname, if that is not the > case, don't use ProxyPreserveHost.
Or use SSLProxyCheckPeerCN off Regards Rüdiger
