Server Name Indication(SNI)

The IBM HTTP Server for i supports Server Name Indication. Server Name Indication is an extension to the SSL and TLS protocols that indicates what hostname the client is attempting to connect to at the start of the handshaking process.

Server Name Indication is an extension to the SSL and TLS protocols that indicates what hostname the client is attempting to connect to at the start of the handshaking process. This allows a server to present multiple certificates on the same IP address and port number and hence allows multiple secure (HTTPS) websites to be served off the same IP address without requiring all those sites to use the same certificate. It is the conceptual equivalent to HTTP/1.1 virtual hosting for HTTPS.

Name-Based Virtual Hosting is a very popular method of identifying different virtual hosts. It allows you to use the same IP address and the same port number for many different sites. When people move on to SSL, it seems natural to assume that the same method can be used to have lots of different SSL virtual hosts on the same server. But in fact, it's not generally possible without the SNI support. The reason is that the SSL protocol is a separate layer which encapsulates the HTTP protocol. So the SSL session is a separate transaction, that takes place before the HTTP session has begun. The server receives an SSL request on IP address X and port Y (usually 443). Since the SSL request did not contain any Host: field, the server had no way to decide which SSL virtual host to use. Usually, it just used the first one it found which matched the port and IP address specified.

The solution is an extension to the SSL protocol called Server Name Indication (RFC 4366), which allows the client to include the requested hostname in the first message of its SSL handshake (connection setup). This allows the server to determine the correct named virtual host for the request and set the connection up accordingly from the start.

With SNI, you can have many virtual hosts sharing the same IP address and port, and each one can have its own unique certificate (and the rest of the configuration). If both Apache Server and browser support SNI, then the hostname is included in the original SSL request, and the web server can select the correct SSL virtual host.

The client browser must also support SNI. Here are some browsers that do:

Mozilla Firefox 2.0 or later
Opera 8.0 or later (with TLS 1.1 enabled)
Internet Explorer 7.0 or later (on Vista or higher, does not work on XP)
Google Chrome (Vista or higher. XP on Chrome 6 or newer. Mac OS X 10.5.7 or higher on Chrome 5.0.342.1 or newer)
Safari 3.2.1 or later (on Mac OS X 10.5.6 and Windows Vista or higher)

The first (default) virtual host for SSL name-based virtual hosts must include TLSv1 as a permitted protocol, otherwise Apache will not accept the SNI information from the client and it will be as if the client did not support SNI at all.

Since the first (default) virtual host will be used for any request where the provided server name doesn't match another virtual host, it is important that the first virtual host have the most restrictive access control, otherwise clients can access restricted resources by sending a request for any unknown hostname. (This isn't actually any different from using virtual hosts without SSL.)

Specify both SSLServerCert and ServerName directives to set the server certificate and fully qualified domain name(FQDN) for those specific name-based virtual hosts to have the SNI support.

Example:

<VirtualHost *:443>
    SSLEngine On
    SSLAppName QIBM_HTTP_SERVER_APACHE1
    DocumentRoot /www/webserver/example1
    ServerName www.example1.com
    SSLServerCert QIBM_HTTP_SERVER_CERT1
</VirtualHost>
<VirtualHost *:443>
    SSLEngine On
    SSLAppName QIBM_HTTP_SERVER_APACHE2
    DocumentRoot /www/webserver/example2
    ServerName www.example2.com
    SSLServerCert QIBM_HTTP_SERVER_CERT2
</VirtualHost>