The problem with supporting multiple host names over SSL on the same server is that they each require a unique, static IP address. As many of you probably know, static IP addresses are not cheap and are not easy to come by. In order to get more than a single static IP address a justification form usually needs to be filled out. One thing you may not know about IPv4 addresses is that they are quickly running out. As such, anything that can be done to use these addresses more efficiently would be beneficial to all until IPv6 becomes more commonly used.
A solution to the SSL problem is to use Server Name Indication or SNI. SNI allows the host name to be sent during the initial SSL transaction making name based virtual hosts possible for secure connections. While SNI has been around since at least 2003, it is only now gaining momentum as people are being forced to use it. As it turns out, Apache began supporting SNI in version 2.2.12 (the latest version is 2.2.15). As such, using the examples from my previous post on this topic, it would be possible to utilize SNI and remove the need for multiple static IP addresses. However, just because the server can support it does not mean you should implement it. As it also turns out, SNI has operating system and web browser as well as server dependencies. This means until people begin moving to newer computers, SNI is still not all that practical.
Using Microsoft Windows as an example, SNI was not supported by their web browser until IE 7. In addition to using IE 7, the Microsoft Operating System (OS) must be running Windows Vista or later. Unfortunately, many people today still run Windows XP (I know I do!). Since many commercial companies depend on great user experiences the aforementioned limitations do not make SNI an appealing solution for everyone. However, for those on the cutting edge this solution may be acceptable.
The addition of SNI to Apache introduced a new directive call SSLStrictSNIVHostCheck. From the Apache documentation: This directive sets whether a non SNI client is allowed to access a name based virtual host. If set to on in the non default name based virtual host, non SNI clients are not allowed to access this particular virtual host. If set to on in the default name based virtual host, non SNI clients are not allowed to access any name based virtual host belonging to this IP / port combination.
What the documentation does not make clear is what happens if:
- The SSLStrictSNIVHostCheck directive is not enabled
- The SSLStrictSNIVHostCheck directive is enabled on all but the default (i.e. first) name based virtual host
- The requested server name does not match any virtual host
And the request is made from a client that does not support SNI. In this case, the default name based virtual host is used, which may or may not be the expected behavior. As such, it is important that the default name based virtual host have the most restrictive access control. Otherwise, clients can access restricted resources by sending a request for any unknown host name.
More information about SNI and how to configure it on Apache is available at: http://wiki.apache.org/httpd/NameBasedSSLVHostsWithSNI
With a couple options available on how to configure Apache with SSL support, the next step is to generate or purchase SSL certificates. Any one who goes out to purchase SSL certificates should know in advance what they are purchasing. In my next blog post, I will cover some important things to know and keep in mind when purchasing SSL certificates.
© 2010, Steve Flanders. All rights reserved.
