Wandering Thoughts archives

Why SSL and name-based virtual hosts don't get along

Part of validating a SSL certificate is making sure that it is a SSL certificate for what you are actually connecting to, to avoid the possibility of a man in the middle attack. SSL certificates for websites have a field (the CN portion of the 'Distinguished Name') that names the host they are for, and so target validation consists of checking that the certificate's CN is the same name as the host portion of the URL.

This checking is pretty literally a string compare; the web browser does not do anything like checking to see whether the CN host and the hostname in the URL map to the same IP address. (Okay, the string comparison does DNS case folding. I don't know if it does IDNA folding so that CN names can be in native character sets, but I suspect not).

The problem for name-based virtual hosting is that the SSL certificate exchange happens immediately after the https connection is made, before the client sends any HTTP headers, including the Host: header that would tell the server what virtual host it is trying to connect to and thus which SSL certificate the server should use. The only things the server knows when it's picking what certificate to use is what IP address and port the client is connecting to, so if you want a single web server to give out multiple SSL certificates you have to use multiple IP addresses (or multiple ports).

The one exception to this is a wildcarded SSL certificates and subdomains. You can get a SSL certificate for *.example.org, and then you can use name-based virtual hosting for multiple <something>.example.org websites, because all of their hostnames will match the certificate's CN. The drawback is that such certificates can be hard to get and generally cost a bunch more money than regular certificates (because the certificate authority is losing out on all that juicy cash they would get by making you buy a certificate per virtual host).