httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <>
Subject Re: SSL enabled name virtual hosts
Date Mon, 06 Mar 2006 18:40:26 GMT
Daniel Rogers wrote:
> My SSL virtual hosts are, effectively, Name based, not port based (there
> are only two ports involved 443, and 444 for unlimited virutal hosts).
> All ssl virtual hosts are on port 444, and their name is used to
> distinguish them.
> The end user sees only port 443.  No worries about weird port numbers.

Of course this works for the server.  So do named based port 443 servers
on the server side today.  You don't need all this PHP script - httpd's
VirtualHost mechanics work (so does mass vhosting via module or rewrite.)

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,,, and,
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.

Certainly, if you are serving,,
and, then this might be a lovely solution.

> Also, I don't appreciate being called a troll.  I am trying to make
> reasoned articulate arguments.  I haven't insulted anyone, and I am
> really making an effort to understand the arguments people are
> presenting me.

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

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.



View raw message