Apache 2.0/2.2 is not compatible with OpenSSL 1.0.0, see bug reports:
You should use OpenSSL 0.9.8.
When it's compiled you will have a module called: mod_ssl.so
You can use ldd to check which library of ssl is used:
$ ldd mod_ssl.so
linux-gate.so.1 => (0xb7f2a000)
libssl.so.0.9.8 => /usr/lib/i686/cmov/libssl.so.0.9.8 (0xb7eac000)
libcrypto.so.0.9.8 => /usr/lib/i686/cmov/libcrypto.so.0.9.8 (0xb7d59000)
libpthread.so.0 => /lib/i686/cmov/libpthread.so.0 (0xb7d3f000)
libc.so.6 => /lib/i686/cmov/libc.so.6 (0xb7be4000)
libdl.so.2 => /lib/i686/cmov/libdl.so.2 (0xb7be0000)
libz.so.1 => /usr/lib/libz.so.1 (0xb7bcb000)
/lib/ld-linux.so.2 (0xb7f2b000)
Apache.org has excellent documentation on how to configure your webserver: http://httpd.apache.org/docs/2.1/ssl/ssl_howto.html
Since SNI occurs during the SSL/TLS handshake, it's not possible to detect browser support when the client connects to HTTP.
So, you're right; a user-agent filter is the only way to do this.
The big question is whether you want to act on a blacklist against browsers that you know won't listen for SNI, or a whitelist of browsers that are known to support it. Obscure or new devices being unable to use the site seems like a deal-breaker, so I'd say the whitelist might be the better option.
In your HTTP <VirtualHost>:
# Internet Explorer 7, 8, 9, on Vista or newer
RewriteCond %{HTTP_USER_AGENT} MSIE\s7.*Windows\sNT\s6 [OR]
RewriteCond %{HTTP_USER_AGENT} MSIE\s8.*Windows\sNT\s6 [OR]
RewriteCond %{HTTP_USER_AGENT} MSIE\s9.*Windows\sNT\s6 [OR]
# Chrome on Windows, Mac, Linux
RewriteCond %{HTTP_USER_AGENT} Windows\sNT\s6.*Chrome [OR]
RewriteCond %{HTTP_USER_AGENT} Macintosh.*Chrome [OR]
RewriteCond %{HTTP_USER_AGENT} Linux.*Chrome [OR]
# Firefox - we'll just make the assumption that all versions in the wild support:
RewriteCond %{HTTP_USER_AGENT} Gecko.*Firefox
RewriteRule ^/(.*)$ https://ssl.hostname/$1 [R=301]
Here's the blacklist option, too - keep in mind that this runs the risk of sending a client that doesn't use SNI to an SNI-needed site, but on the other hand, will send users of something new like IE 10 to the right place:
# IE 6
RewriteCond %{HTTP_USER_AGENT} !MSIE\s6
# Windows XP/2003
RewriteCond %{HTTP_USER_AGENT} !Windows\sNT\s5
# etc etc
RewriteRule ^/(.*)$ https://ssl.hostname/$1 [R=301]
There are a lot of browsers out there. I've been pretty loose with the expressions and haven't covered a lot of browsers - this could turn into quite the nightmare to maintain.
Whichever option you choose.. good luck!
Best Answer
The first bit is fairly easy. Download the source (
0.9.8yappears to be the current version of that stream) from http://www.openssl.org, unpack,./configure --prefix=/usr/local/openssl && make && make install.The second bit may be harder. You might get away with starting apache with
(or wherever the install puts the libraries; I don't have a box with such a setup to hand in order to check it) but it may be too big a jump in versions for apache to start. If it is, you're reduced to rebuilding apache from source as well, in order to relink it against your new OpenSSL, and that will rapidly become a maintenance nightmare.
So try it, but if you can't get away with shoehorning the existing apache into run-time loading your newly-built openssl version, you'd probably be better off planning a migration to RHEL6 (or better yet, CentOS 6).