Recently I was interested in setting up a few of my websites to use Secure Sockets Layer.  Before this we used a Reverse Proxy to map requests coming into our firewall to the appropriate HTTP server instance because we only have one public IP mapped to multiple local IP addresses.

When it came time for SSL, though, things were more difficult.  This is because with normal SSL communications the SSL certificate negotiations are done before the Host HTTP header is sent, which means that if you have an HTTP configuration with multiple virtual hosts using separate and distinct SSL certificates, only the first SSL certificate will be used which, of course, is the wrong one when you're going to the second site in the configuration.  This means the browser will report an error saying that the SSL certificate belongs to the wrong site.

There are a couple ways around this issue.  The first would be to purchase an SSL certificate for multiple domains (note, this is not referring to wildcard certificates).  This was my last resort since it would mean purchasing a new certificate when I already had 2 separate SSL certificates for each site.  The next would be set up another public IP address.  This wasn't something I was interested in either.

The final method, and reason for this article, would be to use what is called Server Name Identification (SNI) which is now available with V7R2 and up.  A good write up about this in more detail with links to RFCs is located at https://serverfault.com/questions/109800/multiple-ssl-domains-on-the-same-ip-address-and-same-port.

SNI allows the host name to be sent during the initial SSL/TLS negotiations, which of course means that you can then use multiple virtual hosts using SSL.

But now with V7R2 the Powered by Apache HTTP server has been upgraded to version 2.4.  This means we have a couple new directives that allow us to get around this problem.  The main one we are interested in is SSLServerCert.  This directive allows us to tell the system which SSL certificate to use for each distinct host.  While this may seem similar to the SSLAppName directive, it is not.  The SSLAppName directive allows you to specify an application name which is associated with an SSL certificate.  The SSLServerCert directive you specify the certificate label as shown here:

Yes, it does seem redundant, doesn't it.  But oh well.  I also found the very limited documentation on this new feature very hard to understand... mainly because in dealing with SSL and application names I was more used to that then using the certificate label.

In the end, I set up my bvstools.com and fieldexit.com sites as shown here:

<VirtualHost xx.xx.xx.xx:443>
   SSLAppName BVSTOOLS_SSL
   SSLServerCert "www.bvstools.com 2017"
   SSLEngine On
...
      
</VirtualHost>

<VirtualHost xx.xx.xx.xx:443>
   SSLAppName FIELDEXIT_SSL
   SSLServerCert www.fieldexit.com
   SSLEngine On
...
   
</VirtualHost>

As you can see, the certificate label for BVSTools contained a space, which means we need to put the label text in quotes (I would have called it something different if I knew I would be doing this in the future, but this works just fine as well!)  Also, instead of separate configuration files and separate server instances, both of the SSL sites needed to be placed into one configuration file.

So, another good reason to updated to V7R2 or higher is this nice new feature.  It only works on "modern" browsers, but if someone is using a browser this doesn't work on, they have other problems they need to take care of first.