Tim Starling wrote:
Neil Harris wrote:
Tim Starling wrote:
[...]
See http://wiki.cacert.org/wiki/VhostTaskForce for a discussion of the
[...]
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.
The interoperability table in the article I linked to has three methods that work in the current versions of the major browsers, two of which work in the older versions as well, and one of which that works with every client they tested. What's the problem?
-- Tim Starling
Both methods have their own drawbacks and advantages.
The problem with multi-name certs is all the other platforms: mobile phones and embedded web browsers, HTTP client libraries for Java/Python/Perl etc, bizarre things like man-in-the-middle HTTPS proxies (yes, they're out there)... until you've tried it, you don't know if its going to work, unlike using IP addresses to select the cert to be sent, which is known to work for all HTTPS-speaking clients.
Of course, this doesn't mean you shouldn't do the multi-name cert thing; the wiki page suggests it should just work for all the major browsers, which implies that it should just work for something like 99% of all web users, just that it's going to need a lot of testing before it goes live, and then providing fallback to plain HTTP login for all clients which cannot handle this, most probably based on user-agent strings.
-- Neil