A traditional problem associated with hosting multiple SSL-enabled sites on the same server is that each SSL enabled site had to have its own dedicated IP address. This was less of a problem in the past when there were plenty of IP addresses and web servers frequently came with many IP's by default. However, these days the number of available IPv4 addresses is now very limited so the need to for SSL sites to share IPs just as non-SSL sites do is now more pressing than ever.
Encrypted communication between a web server and a browser is achieved with an SSL certificate. These certificates are created for a domain name such as https://www.memset.com and will only work without browser errors when they are used for their associated domain.
The issue that kept SSL-sites to a single IP is that when a browser requested an encrypted session from the web server the browser would not identify which website it wanted to access the encrypted connection was created. This meant that the web server would send the first SSL certificate that was configured on that IP address in order to start the encrypted session. If the client wanted to view a site other than the first then there would be a certificate/domain mismatch and the browser would issue a warning. The only way to avoid this was for a single SSL site to exist on each IP ensuring that such a mismatch could never occur.
This situation didn't go unnoticed by the technical community who came up with a solution; Server Name Indication. As the name suggests the problem is overcome by the browser requesting an encrypted sessions AND specifying the domain in the initial request. The web server is then able to select the correct SSL certificate with which to create the encrypted session and send that to the browser. SNI is, therefore, able to host as many SSL enabled sites as are required just as has been possible with non-SSL sites.
In order for SNI to work it must be supported by the web server and the browser.
The web server that we will use for this guide; Apache, has supported SNI from version 2.2.15 and later. Most of the linux images available as Memset miniserver images i.e. Debian, Ubuntu and CentOS provide versions of Apache that support SNI from their standard repositories. With the exceptions being the Centos 5.
All majour browsers have supported SNI for some time including those on mobile platforms. The only majour exception being any version of IE on Windows XP. A full list of supported browsers can be found on the Wikipedia SNI page.
SNI will, therefore, be supported by the majority, but not 100% of users.
SNI is actually very easy to deploy using Apache on the linux distributions offered by Memset. Due to this simplicity, this guide will cover instaling and configuring SNI on all three linux distributions offered by Memset; Debian, Centos and Ubuntu.
These two distributions have the same Apache configuration files and directory structure so they will be gone through together.
Apache is not installed by default so it first needs instaling:
apt-get update apt-get install apache2
The OpenSSL apache module needs enabling and apache restarting to load the module:
a2enmod ssl service apache2 restart
Apache is now ready to serve multiple SSL-enabled sites from the same IP!
All that remains to do is to test the setup by configuring a couple of test sites with their own certificates and see if we can get them served.
Site configuration files on debian and ubuntu are placed into:
Typically given the name of the domain that they will host e.g. example.com.conf . The minimum that this file must contain is as follows:
<VirtualHost 22.214.171.124:443> SSLEngine On ServerName secure.example.com DocumentRoot /var/www/example SSLCertificateFile /etc/ssl/certs/example.com.crt SSLCertificateKeyFile /etc/ssl/private/example.com.key </VirtualHost>
In this VirtualHost file the domain being shown is secure.example.com, its website files are located under /var/www/example.
The SSLCertificateFile and SSLCertificateKeyFile directives must point to the location of the SSL certificate and its associated private key. In the above example, I have placed them into the system directories for keys and certificates under /etc/ssl. However, you can put them anywhere you like but the key must only be readable by root so you should make sure its owner is root and it has its permissions set to 600 and is located out of the website directory.
A second such website configuration file would look like:
<VirtualHost 126.96.36.199:443> SSLEngine On ServerName secure.anotherdomain.com DocumentRoot /var/www/another SSLCertificateFile /etc/ssl/certs/anotherdomain.com.crt SSLCertificateKeyFile /etc/ssl/private/anotherdomain.com.key </VirtualHost>
This will serve the domain secure.anotherdomain.com on the same IP address with its key and certificate in the same locations as the first website.
Apache will automatically serve the correct certificate when the encrypted session is initiated by a modern browser. No additional configuration is required to get SNI working.
First apache2 needs installing along with the OpenSSL module:
yum update yum install httpd openssl mod_ssl
Apache is now installed and has SNI support loaded and functioning.
Next the VirtualHost configuration that was placed into unique files for Debian/Ubuntu needs to be added to the bottom of the httpd.conf file. The httpd.conf file is located at:
You must copy and paste all of the same configuration between and including the <VirtualHost> </VirtualHost> tags (as shown above) at the bottom of the httpd.conf file. Then restart apache:
service httpd restart
SNI has no limit on the number of SSL-enabled sites that can be run from a single IP address.
Last updated 28 June 2017, 13:38 GMT