Mailing List Archive

SNI with apache 2.4.1 reverse proxy

after upgrading from 2.2.21 to 2.4.1 I'm seeing a problem with SNI in
combination with reverse proxying.

I have a VM with wordpress in it behind an apache reverse proxy. The
reverse proxy runs on the host system and port 12443 of this host is
forwarded into the VM and connects to 443 there. The reverse proxy
configuration lives in a virtual host that redirects all requests for a
number of different server names/aliases to port 12443 and thus into the

The working HTTPS reverse proxy configuration of httpd 2.2 looks like

<VirtualHost *:443>
DocumentRoot /var/www/

ServerAlias *
ErrorLog /var/log/apache2/
CustomLog /var/log/apache2/ combined
UserDir disable

SSLEngine on
SSLCertificateFile /etc/ssl/certs/
SSLCertificateKeyFile /etc/ssl/private/
SSLCACertificateFile /etc/ssl/certs/

ProxyRequests Off
ProxyPass /
ProxyPassReverse /

SSLProxyEngine on
SSLProxyCACertificateFile /etc/ssl/certs/cacert.pem
SSLProxyCheckPeerCN On
SSLProxyCheckPeerExpire On
SSLProxyVerify require
SSLProxyVerifyDepth 1

Apart from the port change, this setup isn't very VM-specific.
Therefore, the problem I'm seeing should hit any SSL reverse proxy setup
where multiple frontend names are forwarded to the same backend server
via a static ProxyPassReverse URL.

After upgrading to 2.4.1, when accessing, the
apache inside the VM logs:

[Fri Apr 06 11:23:55 2012] [error] Hostname provided
via SNI and hostname provided via HTTP are different

My guess was that 2.4.1's mod_ssl now uses SNI towards the backend as
well and indeed there's the following code in ssl_engine_io.c that's not
in 2.2.21:

* Enable SNI for backend requests. Make sure we don't do it for
* pure SSLv3 connections, and also prevent IP addresses
* from being included in the SNI extension. (OpenSSL would simply
* pass them on, but RFC 6066 is quite clear on this: "Literal
* IPv4 and IPv6 addresses are not permitted".)
if (hostname_note &&
sc->proxy->protocol != SSL_PROTOCOL_SSLV3 &&
apr_ipsubnet_create(&ip, hostname_note, NULL,
c->pool) != APR_SUCCESS) {

Having seen this, I added

SSLProxyProtocol SSLv3

to the reverse proxy configuration to disable usage of SNI and indeed
the setup now works again with 2.4.1.

Is there an explicit configuration option for en-/disabling usage of SNI
towards the proxy backend servers? Should there be (I think yes)?

Also I realise that the problem is more fundamental: What if I wanted to
host multiple sites inside the VM and actually use SNI? Therefore I
tried configuring the reverse proxy with a dynamic backend URL like

ProxyRequests Off
SetEnvIf Host (.*) reverse_proxy_host=$1
ProxyPass / https://${reverse_proxy_host}:12443/ interpolate
ProxyPassReverse / https://${reverse_proxy_host}:12443/ interpolate
ProxyPreserveHost On
ProxyPassInterpolateEnv On

This however does not work: The reverse proxy gives an error and logs
the following for all requests:

[Fri Apr 06 13:00:30.275588 2012] [ssl:debug] [pid 20237:tid 139649156212480] ssl_engine_kernel.c(243): [client] AH02034: Initial (No.1) HTTPS request received for child 0 (server
[Fri Apr 06 13:00:30.275588 2012] [authz_core:debug] [pid 20237:tid 139649156212480] mod_authz_core.c(809): [client] AH01628: authorization result: granted (no directives)
[Fri Apr 06 13:00:30.275588 2012] [core:info] [pid 20237:tid 139649156212480] [client] AH00128: File does not exist: proxy:

The proxy initialisation also looks hinky:

[Fri Apr 06 13:00:29.791558 2012] [proxy:debug] [pid 20237:tid 139649224263488] proxy_util.c(1640): AH00925: initializing worker https://${reverse_proxy_host}:12443/ shared
[Fri Apr 06 13:00:29.791558 2012] [proxy:debug] [pid 20237:tid 139649224263488] proxy_util.c(1680): AH00927: initializing worker https://${reverse_proxy_host}:12443/ local
[Fri Apr 06 13:00:29.791558 2012] [proxy:debug] [pid 20237:tid 139649224263488] proxy_util.c(1712): AH00930: initialized pool in child 20237 for (${reverse_proxy_host}) min=0 max=25 smax=25

Also I realise that blindly using the request's Host header for reverse
proxying isn't the most secure thing to do.

What would be the proper way to go about this?
Thank you,

To unsubscribe, e-mail:
For additional commands, e-mail: