SNI doesn't work in practice
A while back I talked about why SSL and name-based virtual hosts don't get along, and a commentator pointed me at the 'Server Name Indication' (SNI) SSL extension to deal with this. The approach SNI takes is for the client to send the server name(s) it wants to talk to as part of the initial handshake; a SNI-aware server can use this to pick the right server certificate right away.
The problem with SNI is that support for it is almost completely lacking in both servers and clients, and has been this way for several years. For servers, no unpatched release of either Apache or lighttpd supports it yet.
(I'm deliberately excluding mod_gnutls here, because I consider things like the lack of a Debian package to be a serious 'do not use' warning sign.)
For clients, the only widely used client that supports it is Firefox 2; IE 7 only supports it when run on Vista, and it's not supported in Mac OS X's WebKit (the base of Safari, among other OS X browsers). The situation with IE is especially problematic, as SNI support depends on the version of the Windows TLS library. If Microsoft is not going to update that on Windows XP, there are a huge number of people who are not going to have SNI available for years.
In short: SNI is a nice idea but not a practical one. I suspect that it's been caught in a chicken and egg scenario, where everyone who needed to do some of the work didn't seem much demand for it because none of the other pieces were there either.
(There's at least three pieces: the web servers, the browsers, and the SSL crypto libraries.)
Sidebar: various resource links
- a SNI test site, so you can see if your environment supports it.
- Daniel Lange's summary of what supports SNI
- the apache ticket to add SNI
- the lighttpd ticket to add SNI
- a general resource page on the overall https and virtual hosts issue