On Fri, Apr 12, 2013 at 7:18 AM, Lam, Eugene <euge...@amazon.com> 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" <httpd-dev.2...@velox.ch> 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. Cheers Tom
