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
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).