httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Boyle Owen" <Owen.Bo...@swx.com>
Subject RE: SSL enabled name virtual hosts
Date Tue, 07 Mar 2006 08:37:10 GMT
> -----Original Message-----
> From: Daniel Rogers [mailto:daniel@phasevelocity.org] 
> Sent: Montag, 6. März 2006 19:01
> 
> 
> The end user sees only port 443.  No worries about weird port numbers.

Ok - I read the post and I agree your solution doesn't rely on using a non-standard port externally.
I was confused by the complicated redirecting scheme which, as you've now learned, can be
more easily implemented in mod_rewrite. In any case, I don't know why you need it at all since,
once you have an SSL session running, you can just use the NBVH mechanism to route requests
to the appropriate VH.

Your solution relies entirely on the existence of a certificate with multiple host-names.
If you have this, then you can present it as the single default certificate for every SSL
session and then (since the cert contains all host names) the browser does not complain about
a URL vs. CN mismatch. Nobody would dispute that this mechanism would work - there's nothing
in the protocol to prevent it.

The problem, as William pointed out, is getting and managing the certificate. As you say,
Verisign would need to get into the business of selling such certs, along with a mechanism
for allowing the owner to load new sites (essential for a web-hoster). Bearing in mind that
Verisign et al are supposed to verify the identity of the requester of a cert before issuing
it, how would you propose that works? I guess you'd need a new scheme whereby the cert would
contain a pointer to Verisign who would maintain the list of authenticated SubjectAltNames.
Maybe you're right, maybe Verisign would like to get involved in that business - but it's
clearly something for the future...

I've no doubt that in an academic environment, where you are your own certificate authority
and are making self-signed certs, this could be useful. But I think you're skipping over the
importance of authentication in real-world, commercial SSL.

To sum up: your solution doesn't do anything new and, although technically possible, doesn't
work in the real world because the certificate management scheme doesn't exist. Further, there
are at least two "competing" schemes (server name indication and HTTP upgrade to TLS) that
are already in the pipeline - oh, and don't forget IPv6...

Rgds,
Owen Boyle
Disclaimer: Any disclaimer attached to this message may be ignored. 


> Also, I don't appreciate being called a troll.  

I'm sure you don't, but I never said that.

>
>
>

Diese E-mail ist eine private und persönliche Kommunikation. Sie hat keinen Bezug zur Börsen-
bzw. Geschäftstätigkeit der SWX Gruppe. This e-mail is of a private and personal nature.
It is not related to the exchange or business activities of the SWX Group. Le présent e-mail
est un message privé et personnel, sans rapport avec l'activité boursière du Groupe SWX.
 
 
This message is for the named person's use only. It may contain confidential, proprietary
or legally privileged information. No confidentiality or privilege is waived or lost by any
mistransmission. If you receive this message in error, please notify the sender urgently and
then immediately delete the message and any copies of it from your system. Please also immediately
destroy any hardcopies of the message. You must not, directly or indirectly, use, disclose,
distribute, print, or copy any part of this message if you are not the intended recipient.
The sender's company reserves the right to monitor all e-mail communications through their
networks. Any views expressed in this message are those of the individual sender, except where
the message states otherwise and the sender is authorised to state them to be the views of
the sender's company.

Mime
View raw message