As of r39934 Chromium now supports the server_name TLS extension (server name indication) in OS X (latest build). This support requires OS X 10.5.7 or later. Hopefully it’ll make its way into a dev/beta/stable release of Google Chrome itself soon.

For those who are more curious than they ought to be about how I wrote this patch… Apple added support in their Secure Transport library for the server_name TLS extension, but has not updated their documentation. As of 10.5.7 (or possibly 10.5.6) the SSLSetPeerDomainName function — which is ostensibly used for OS level certificate verification — causes OS X to send the server_name extension in the TLS client hello. However, since Chromium doesn’t use OS X’s built-in verification it wasn’t passing this data through prior to the patch.

To test you can hit up my IDN SNI site https://☣.ws/ or https://alice.sni.velox.ch/. The former will throw a certificate error if you are on a non-SNI enabled browser and the latter will have text stating that the SNI extension is missing.

Server Name Indication (SNI), an extension to TLS, allows browsers that support it to connect to SSL hosts that do not have dedicated IPs (much like standard http virtual hosting has worked for years). This extension, however, must be supported on both the server and client side. Microsoft has not yet chosen to support it (maybe IIS 8?), but the Apache project did with the 2.2.12 release. Recently, Ubuntu 9.10 Server became the first server distribution to ship with Apache and OpenSSL built with the appropriate flags, so if you’d like to follow along you can use a 9.10 VM.

In the ideal case everything is the same as a regular vhost, but you’ll first need to enable SSL. On Ubuntu this requires you to run a2enmod and type “ssl”. After that you’ll need to add

NameVirtualHost *:443

to the root conf, then make your VirtualHost much like a normal one. A very basic pair of vhosts is seen below.

<VirtualHost *:443>
	ServerAdmin webmaster@localhost
 
	DocumentRoot /my/doc/root
	ServerName mydomain.com
	SSLEngine On
	SSLCertificateFile /path/to/domain.crt 
	SSLCertificateKeyFile /path/to/domain.key
</VirtualHost>
<VirtualHost *:443>
	ServerAdmin webmaster@localhost
 
	DocumentRoot /my/doc/root
	ServerName mydomain2.com
	SSLEngine On
	SSLCertificateFile /path/to/domain2.crt 
	SSLCertificateKeyFile /path/to/domain2.key
</VirtualHost>

These vhosts should be placed in different includes ideally, but it isn’t required. If you just want to test with a self-signed certificate you can create one with

openssl req -new -nodes -keyout mykey.key -out mycert.cer -days 3650 -x509

You’ll need to specify the domain name you want in the “Common Name” section.

Once you’ve got all this done you can restart apache and test it out! If you test on a browser that doesn’t support SNI (IE on XP) you’ll get the SSL cert for the first vhost apache parses. To disable accessing it on non-SNI hosts you can add

SSLStrictSNIVHostCheck on

to the root conf. This will cause a 403 error for those browsers.

If you’d like to see an example implementation of SNI you can check out my IDN domains https://☢.ws/ and https://☣.ws/. These sites are hosted on the same IP with different SSL certificates. I have strict host checking turned on so visiting them with a non-SNI capable browser will result in a 403 error.¹