On 16.04.2012 16:47, Michael Weiser wrote: > So implementation-wise this will most likely have two parts of code: > > 1. Determining the hostname to put into SNI data depending on > ProxyPreserveHost somewhere in the reverse proxy module. > > 2. Putting that value into the SNI data in mod_ssl's ssl_engine_io.c.
I'm not too familiar with the history/motivation of the ProxyPreserveHost directve (which dates to as far as 2002, see r93089), but in the context of proxy SSL requests, I think it isn't a particularly good idea to support this feature... because essentially, it opens up the door to MitM attacks: you're asking mod_proxy_http to, say, request URI https://foo.example.org/index.html, but directing it via TLS to a host configured with certificate bar.example.org. mod_proxy_http's "blindness" for MitM attacks was also the reason for introducing SSLProxyCheckPeerCN in r760866/r768504, I assume. In addition to dealing with SNI extension / Host header mismatches you would also have to accommodate for the case of CN / Host header mismatches. To solve your immediate problem in 2.4, what you could try is: ProxyPass / https://127.0.0.1:12443/ ProxyPreserveHost On SSLProxyCheckPeerCN off This prevents mod_ssl in 2.4 from adding an SNI extension to the proxy request (it will skip IP addresses), and will pass the Host reader from the original request to the backend. You need to turn off SSLProxyCheckPeerCN at the same time (unless your backend cert has CN=127.0.0.1) - but in the end, this just reflects what you're asking mod_proxy_http to do: connect via TLS to host with cert X and request resource from host Y. Kaspar
