Sign up ×
Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

We recently moved an exchange server behind a reverse proxy due to the loss of a public IP. I've managed to configure the reverse proxy (httpd proxy_http).

But there is a problem for the SSL configuration.

When accessing the OWA interface with Firefox, all is ok and working. When accessing with MSIE or Chrome, they do not retrieve the good SSL Certificate.

I think this is due to the multiples virtual host for httpd. Is there a workaround to make sure MSIE/Chrome request the certificate for the good domain name like FF does?

Already tested with the SSL virtual host :

SetEnvIf User-Agent ".*MSIE.*" value BrowserMSIE
  Header unset WWW-Authenticate
  Header add WWW-Authenticate "Basic"


ProxyPreserveHost On


BrowserMatch ".*MSIE.*" \
nokeepalive ssl-unclean-shutdown \
downgrade-1.0 force-response-1.0


SetEnvIf User-Agent ".*MSIE.*"    \
nokeepalive ssl-unclean-shutdown  \
downgrade-1.0 force-response-1.0

And lots of ProxyPassand ProxyReversePath on /exchweb /exchange /public etc...

And it still don't seem to work. Any clue?


Edit 1: Precision of versions

# openssl version
OpenSSL 0.9.8k-fips 25 Mar 2009

/usr/sbin/httpd -v
Server version: Apache/2.2.11 (Unix)
Server built:   Mar 17 2009 09:15:10

Browser versions :

MSIE : 8.0.6001
Opera: Version 11.01 Revision 1190
Firefox: 3.6.15
Chrome: 10.0.648.151

Operating System:

Windows Vista 32bits.

They are all SNI compliant, I've tested them this afternoon

You're right Shane Madden, I have multiple sites on the same public IP (and same port as well). The server itself is just a reverse proxy, that rewrite addresses to internal servers.

The default host is a dev site, configure with the certificate that does not match the OWA (of course... would have been to easy)

<VirtualHost *:443>

    CustomLog "| /usr/sbin/rotatelogs /var/log/httpd/access-%y%m%d.log 86400" combined
    ErrorLog "| /usr/sbin/rotatelogs /var/log/httpd/error-%y%m%d.log 86400"

    LogLevel warn

    RewriteEngine on
    SetEnvIfNoCase X-Forwarded-For .+ proxy=yes

    SSLEngine on
    SSLProtocol -all +SSLv3 +TLSv1
    SSLCertificateFile /etc/httpd/ssl/
    SSLCertificateKeyFile /etc/httpd/ssl/

    RewriteCond %{HTTP_HOST} dev2\.domain\.com
    RewriteRule ^/(.*)$$1 [L,P]


The certificate of domain is a *

The second vHost is :

<VirtualHost *:443>

    CustomLog "| /usr/sbin/rotatelogs /var/log/httpd/exchange/access-%y%m%d.log 86400" combined
    ErrorLog "| /usr/sbin/rotatelogs /var/log/httpd/exchange/error-%y%m%d.log 86400"

    LogLevel warn

    SSLEngine on
    SSLProxyEngine On

    SSLProtocol -all +SSLv3 +TLSv1
    SSLCertificateFile /etc/httpd/ssl/exchange.pem
    SSLCertificateKeyFile /etc/httpd/ssl/exchange.key
   RewriteEngine on
    SetEnvIfNoCase X-Forwarded-For .+ proxy=yes

    RewriteCond %{HTTP_HOST} exchange\.domain2\.com
    RewriteRule ^/(.*)$$1 [L,P]


and it's certificate is only.

I presume the SNI is somewhere not activated on my server. The versions of openssl and apache seams to be ok for the SNI support. The only thing I do not know is if httpd has been compile with the good options. (I assume it's a fedora packet).

share|improve this question

1 Answer 1

up vote 1 down vote accepted

Some browser version numbers would be good, as well as some more information on what else is on that server.

Based on what you have provided, it sounds like there are other SSL certs on that server, and the non-firefox browsers are getting one of the others? From here I'll hazard a guess that the cert they're getting is from the default virtualhost? I'll also hazard a guess that you're testing from a Windows XP system.

Where I'm going with this is that you've got multiple SSL certificates all bound to the same port, and a different one should be presented based on what host name is being visited. This depends on Server Name Indication, which isn't supported by older browsers or by XP's encryption libraries.

Unfortunately, the workarounds for this (which you'll need, there's too many old browsers out there still) are non-trivial; buy a new certificate that'll cover everything on that port (a wildcard or Subject Alternate Name cert), or add an extra IP to the server for the other VirtualHost to listen on with just its own cert.

share|improve this answer
I've found references on SNI after I posted. But seems the browser are compatible and I'm on Vista. I've updated the question. – M'vy Mar 18 '11 at 15:12
Ok I got the problem. Was effectively SNI problem, but httpd was not enough up to date to have SNI enabled. A little yum update httpd solved the problem (updating mod ssl as well). Thanks for your help. – M'vy Mar 18 '11 at 15:55

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.