Tim Starling wrote:
Lane, Ryan wrote:
HTTPS does support virtual hosting. You can have certificates with wildcards, e.g. *.wikipedia.org, and you can even have certificates that list multiple second-level domains. In theory we could even support https://en.wikipedia.org/, by having LVS pass the traffic off to an SSL proxy cluster, which forwards to the Florida squids via a secure tunnel.
From what I've read HTTPS does not support name-based virtual hosting, only IP based virtual hosting, as the SSL connection happens before the request is made. So, if you have two virtual hosts such as:
<Virtualhost en.wikipedia.org> ... </Virtualhost>
<Virtualhost de.wikipedia.org> ... </Virtualhost>
The first virtual host will always be used as the server has absolutely no clue, when the connection is made, which virtual host it needs to use.
I believe this is the point Neil was trying to make.
The same is true of unencrypted HTTP. The server has no idea, when the connection is made, what virtual host will be required. That only comes when the client sends the Host header.
The issue is that with HTTPS, the server has to send a certificate before the client sends the Host header. The certificate has to match the hostname.
See http://wiki.cacert.org/wiki/VhostTaskForce for a discussion of the various ways of achieving this.
-- Tim Starling
And, once the various browsers and CAs have all sorted out the different ways of generating and handling these wildcard and multi-name certs in a fully interoperable way, the problem will have been solved. But for the moment, I believe that this currently isn't the case: although, if there is a way to do this across all the currently-deployed browsers, I'd be interested to hear about it.
-- Neil