This entry was originally posted in slightly different form to Server Fault
There are two methods of using virtual hosting with HTTP: Name based and IP based.
IP based is the simplest as each virtual host is served from a different
IP address configured on the server, but this requires an IP address for
every host, and we’re meant to be running out. The better solution is to
use the Host: header introduced in HTTP 1.1, which allows the server to
serve the right host to the client from a single IP address.
HTTPS throws a spanner in the works, as the server does not know
which certificate to present to the client during the SSL connection set
up, because the client can’t send the Host: header until the connection
is set up. As a result, if you want to host more than one HTTPS site,
you need to use IP-based virtual hosting.
However, you can run multiple SSL sites from a single IP address using a couple of
methods, each with their own drawbacks.
The first method is to have a SSL certificate that covers both sites. The idea
here is to have a single SSL certificate that covers all the domains you want
to host from a single IP address. You can either do this using a wildcard
certificate that covers both domains or use Subject Alternative Name.
Wildcard certificates would be something *.example.com, which would cover
www.example.com, mail.example.com and support.example.com. There are a number
of problems with wildcard certificates. Firstly, every hostname needs to have a
common domain, e.g. with *.example.com you can have www.example.com, but not
www.example.org. Secondly, you can’t reliably have more than one subdomain,
i.e. you can have www.example.com, but not www.eu.example.com. This might work
in earlier versions of Firefox (<= 3.0), but it doesn’t work in 3.5 or any
version of Internet Explorer. Thirdly, wildcard certificates are significantly
more expensive than normal certificates if you want it signed by a root CA.
Subject Alternative Name is a method of using an extension to X509 certificates
that lists alternative hostnames that are valid for that certificate. It
involves adding a “subjectAltName” field to the certificate that lists each
additional host you want covered by the certificate. This should work in most
browsers; certainly every modern mainstream browser. The downside of this
method is that you have to list every domain on the server that will use SSL.
You may not want this information publicly available. You probably don’t want
unrelated domains to be listed on the same certificate. It may also be
difficult to add additional domains at a later date to your certificate.
The second approach is to use something called SNI (Server Name Indication)
which is an extension in TLS that solves the chicken and egg problem of not
knowing which certificate to send to the client because the client hasn’t sent
the Host: header yet. As part of the TLS negotiation, the client sends the
required hostname as one of the options. The only downside to this is client
and server support. The support in browsers tends to be better than in servers.
Firefox has supported it since 2.0. Internet Explorer supports it from 7
onwards, but only on Vista or later. Chrome only supports it on Vista or later
too. Opera 8 and Safari 8.2.1 have support. Other browsers may not support it.
The biggest problem preventing adoption is the server support. Until very
recently neither of the two main webservers supported it. Apache gained SNI
support as of 2.2.12, which was released July 2009. As of writing, IIS does not
support SNI in any version. nginx, lighttpd and Cherokee all support SNI.
Going forward, SNI is the best method for solving the name-based virtual
hosting of HTTPS, but support might be patchy for a year or two yet. If you
must do HTTPS virtual hosting without problems in the near future, IP based
virtual hosting is the only option.
on said:
I guess you might be interested in FOAF+SSL if no already in your radar : http://esw.w3.org/topic/foaf+ssl
Hope this helps,
on said:
The biggest blocker for SNI seems to be a lack of support on XP. Last time I checked no browser, firefox included supported it there.
on said:
mod_gnutls for Apache had SNI for a long time.
on said:
mod_gnutls for Apache had SNI for a long time.
on said:
mod_gnutls for Apache had SNI for a long time.
on said:
Another downside for SNI is that the hostname gets leaked into the clear.
on said:
It’s stupid that they would send the hostname in clear instead of a hash which the server could then look up among the hashes of its common names.
on said:
Another case for IPv6.
on said:
@tomaw is right! If I understand correctly, XP will NEVER get an IE that has sni.
And @Tobias is right too! mod_gnutls is great and has had sni support since at least last March:
http://www.docunext.com/blog/2008/03/mod-gnutls.html
on said:
You’re concerned that the hostname leaks? Hell, you even did a (oh my god its unencrypted) DNS query before contacting the specific IP-address asking for the host!
on said:
Surely the biggest problem is browser support. After all if you want to use SNI you can upgrade your server.
You’d have a hard time upgrading IE6 everywhere
http://marketshare.hitslink.com/browser-market-share.aspx?qprid=2
I guess its time will come (or maybe by that point we will all be using IPv6).
on said:
This has been a problem forever. SNI sounds like a good solution. the issue of clients supporting it better than servers may sound bad, but actually its good that client support is as far as it is. This is mostly a problem that only concerns sysadmins/network admins anyways because they don’t want to use so many IPs, so if its just a matter of server support, then those admins can just seek out a server solution that will work for them. However, they cannot control what clients will be able to handle SNI or not.
on said:
In principle, you could also listen on alternate ports, but that’s less user-friendly and moreover plays badly with some paranoid firewalls.
on said:
We’ve been running SNI at MIT for a bit over a year now (on http://scripts.mit.edu/ , the non-static-content server); we use Apache, and had been using sni.velox.ch’s patch for mod_ssl. Currently 32 of our 420 or so *.mit.edu virtual hosts have server certs. Admittedly MIT is a bit of a self-selecting group, but there is a fairly large IE contingent. My personal theory is that people on IE on XP are more likely to click the “ignore” button on cert warnings than people on other browsers or OSes. 🙂
on said:
buy nexium online