SNI for multiple SSL Secured sites on One IP
Perhaps one of the most important new features added to recent Apache versions (2.2.12, to be specific) is the long-awaited support for multiple SSL (Secure Sockets Layer) sites on a single IP address.
Prior to this, it was only possible to have an SSL Secured Web site if it was bound to one particular IP address. This means, that before SNI (Server Name Indication) , if for example, you only had two IP addresses, you only had the ability to have two SSL Secured Websites.
On two IP addresses you can have as many regular HTTP sites assigned to either IP, however only two SSL Secured sites.
What made this even more frustrating is that if www.example1.com and www.example2.com were on the same IP and example1.com had an HTTPS site as well, going to https://www.example2.com/ would, in fact, take you to the equivalent of visiting https://www.example1.com/.
This meant that most people who wanted an SSL Secured Website had to restrict one site (both HTTP and HTTPS variants) to a single IP address to avoid this type of confusion.
With Apache 2.2.12 and support for the SNI extension to the SSL protocol, this has changed completely.
Now you can configure name-based SSL Encrypted sites, just as you can configure name-based HTTP sites.
The bottom line is that the five IPs that you needed today to run five SSL sites can be reduced to one IP if you meet the below requirements (provided, of course, you use the newer Apache).
There are some requirements, however:
The server must use Apache 2.2.12 or higher, and have mod_ssl installed.
It must also use OpenSSL 0.9.8f or later and must be built with the TLS extensions option.
And Apache must be built against this version of OpenSSL as it will enable SNI support if it detects the right version of OpenSSL — the version of OpenSSL that includes TLS extension support.
Not every browser yet supports SNI, but the most popular browsers do, and some have for quite a while. This includes Firefox 2.0 or later, Opera 8.0 or later, Internet Explorer 7.0 or later (unfortunately, only on Vista), Google Chrome, and Safari 3.2.1 (unfortunately only on OS X 10.5.6 or later).
Below, I have included a Basic implementation of two SSL vhosts, which could be bound to one IP using SNI.
NameVirtualHost *:443
SSLStrictSNIVHostCheck off
<VirtualHost *:443>
ServerAdmin [email protected]
DocumentRoot /var/www/html/domain.ext
ServerName domain.ext
ServerAlias www.domain.ext
SSLEngine on
SSLCipherSuite ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP:+eNULL
## SSL Certificate File
SSLCertificateFile /etc/httpd/ssl/domain.ext.crt
## SSL Key File
SSLCertificateKeyFile /etc/httpd/ssl/domain.ext.key
## SSL Certificate Authority File
SSLCACertificateFile /etc/httpd/ssl/domain.ext.ca
</VirtualHost>
<VirtualHost *:443>
ServerAdmin [email protected]
DocumentRoot /var/www/html/domain2.ext
ServerName domain2.ext
ServerAlias www.domain2.ext
SSLEngine on
SSLCipherSuite ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP:+eNULL
## SSL Certificate File
SSLCertificateFile /etc/httpd/ssl/domain2.ext.crt
## SSL Key File
SSLCertificateKeyFile /etc/httpd/ssl/domain2.ext.key
## SSL Certificate Authority File
SSLCACertificateFile /etc/httpd/ssl/domain2.ext.ca
</VirtualHost>
What the above does is enable Apache listening to port 443 and turns on listening for virtual host requests on all IPs.
The new keyword SSLStrictSNIVHostCheck is disabled, meaning we will not throw a 403 error if the client does not support SNI.
Instead, they will be redirected to the SSL site defined first (domain.ext in the example), so be sure to define your default site first.
The largest problem here is the client browser support, but that will come in time. The Apache requirements and configuration, by contrast, are very simple and straightforward.

For high performance websites and applications requiring a dedicated solution.
Suitable for low medium traffic websites where you require complete (root) access to your server.
Windows Web Hosting



