Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
Received-SPF: pass (asf.osuosl.org: domain of daniel@phasevelocity.org
 designates 66.92.189.46 as permitted sender)
Subject: Re: SSL enabled name virtual hosts
From: Daniel Rogers <daniel@phasevelocity.org>
To: dev@httpd.apache.org
In-Reply-To: <440C821A.8060602@rowe-clan.net>
References: 
	 <FDD5D99066749040AF9098A720E9897701451BD1@CIWMEXZSA0E.ex.ordersx.org>
	 <1141668080.7600.51.camel@crunchy>  <440C821A.8060602@rowe-clan.net>
Content-Type: text/plain
Date: Mon, 06 Mar 2006 11:37:44 -0800
Message-Id: <1141673864.7600.93.camel@crunchy>
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit

On Mon, 2006-03-06 at 12:40 -0600, William A. Rowe, Jr. wrote:
> Daniel Rogers wrote:
> > 
> What you failed to address in your example is that *one and only one*
> certificate is used to handshake to port 443.
> 
> >>- Using SubjectAltName to allow for an "all-purpose" certificate sounds 
> >>like a good idea and would be fine in a research environment where you 
> >>are making your own certs. But I don't think it would be very practical
> >> in a commercial situation. If you are a web-hosting company, are you 
> >>really going to get a new certificate every time a site wants an SSL VH?
> >> Who sells these certs? How expensive are they?
> > 
> > I'll answer these two points together.  subjectAltName doesn't have to
> > allow an "all purpose" certificate.  It can be on a single host, or an
> > enumerated set of hosts.
> 
> Then use this today as the primary certificate of a normal name-based
> vhost solution, with the subjectAltNames of all the certificates.  If that
> really works for browsers today, that's lovely.
> 
> What is missing here is that if I'm a mass vhosting service of joesrepairs.com,
> tomsgarage.com, salliessewingcircle.com, parentsformorality.org and xxx.com,
> I don't know that the parents really want their site associated with a porn
> site, while tom and joe across the street from each other might have an issue
> as well.  If you use the subjectAltName you need to list *all* these on your
> single physical IP/port which is used for the *one* certificate that the server
> presents to the client for handshaking.

Ah ha!!  I see, said the blind man.  So I've used this subjectAltName
for Dovecot, postfix and httpd simultanously.  It works with
Mozilla/Firefox, Mail.app, Thunderbird, Safari, and evolution.  I
haven't check with IE.  Though if anyone wants to you can check these
ssl sites, which all present the same certificate.  (the page itself
gives a link to the CA cert, if you'd like to check that part too).  No
virtual hosting is going on here, so you see the same site with all of
them.
https://spike.phasevelocity.org/
https://phasevelocity.org/
https://www.phasevelocity.org/
With firefox, or any of the programs I mentioned above, I get no
hostname mis-matched error.
I think the more insidious problem is that no tools I've used so far
actually show the subjectAltName hostnames without delving into the
certificate details, and looking for it, in particular.  If you actually
perform a cursory examination the certificate once you've connected to
site, it only shows the commonName of the cert, which might be totally
unrelated to the hostname to connected to.  Even though, if you trust
the CA, it accepts the cert as valid, which would be very disconcerting
if you were not expecting it.  If fact, as I just checked, I don't think
it is possible to get a human readable form of the subjectAltName field
at all from within the Firefox certificate examination dialog.  Thus
there is no way to examine the certificate from within firefox, and
actually verify, even in an obscure way, that the certificate is valid
for this host, even though Firefix will accept the certificate as valid
and present no host-mismatched error.  Disconcerting indeed!

> To be clear, all of this has been rehashed weekly for years.  Everyone thinks
> they invented the next best thing since sliced bread to work around these
> constraints, while asking us to spend our time explaining the constraints
> -again- each time.  Unlike most others, you obviously thought on this alot
> and deserved a response for your efforts.  subjectAltName and wildcard
> certs might be an option for some, so perhaps the documentation needs to be
> revised if, in fact, the subjectAltName solution is supported by all modern
> browsers (or most with explicit exceptions.)

Hmm, I feel it is certainly worth exploring whether or not
subjectAltName works in IE.

> But don't confuse either subjectAltName or a wildcard cert for adding more
> arbitrary certificates for each individual name-based virtual host.  The
> certificate has been presented.  It's also possible, perhaps, that you can
> move from the original cert to a replacement cert of that individual site
> alone, by creating both a master cert of all subjectAltName entries as well
> as an individual cert of the single commonName.  Simply force a renegotation.
> Yet and still, the browser/client/user -will- be presented one and only one
> certificate when connecting to a given IP/port of an https server, and this
> fact cannot be avoided without either TLS name handshaking or plain text
> connection-upgrade to a secure connection.

Indeed, there is no arguing on that point.  Then I suppose my proper
course of action is to:

1. Demonstrate a working NameVirtualHost, single cert SSL configuration.
2. Verify that it works in most browsers
3. Update the FAQ and documentation as to the limitations, and the need
for special certificates.

Thanks Bill and Owen, for making taking the time to make this clear to
me, even though you have undoubtedly explained this a hundred times
before.

-- 
Daniel