> -----Original Message-----
> From: Joost de Heer [mailto:[EMAIL PROTECTED]
> Sent: Montag, 7. November 2005 19:12
> To: Boyle Owen
> Cc: users@httpd.apache.org
> Subject: RE: [EMAIL PROTECTED] Limiting SSL to a specific virtual host
> 
> 
> >> > NB - Remember that you can't do name-based VHs with SSL.
> >>
> >> I think Apache 2.1 can.
> >>
> >
> > You think wrong.
> 
> I do think it can do it too. Although the certificate of the 
> first vhost
> is always used, after the traffic is decrypted the vhosts act 
> like normal
> name based vhosts. If all your vhost-domains are in the same 
> subdomain,
> and you have a wildcard certificate for this subdomain, SSL name based
> vhosting works.

Don't confuse yourself. You describe two schemes above; 

(1) (where all VHs use the cert from the first VH): This is accidental 
behaviour. If apache can't decide which VH to use it uses the first one. This 
is default behaviour in every apache - 1.3 or 2.0 or 2.1. Thus the SSL session 
is established with the cert from the first VH. Once the session is up, apache 
can see the Hostname headers and further requests are routed to the correct VH 
- so it looks like it works. The big problem is that the common name in the 
cert doesn't generally match the hostname so you get authentication warnings in 
the browser. Authentication is just as important as encryption in real-world 
SSL. So this is not a proper solution.

(2) Wildcard certs: Here the cert has common name like "*.wibble.com" and so 
sites like www1.wibble.com and www2.wibble.com will authenticate properly. This 
is a proper solution. The trouble is getting the cert - VeriSign used to do 
them, but I'm not sure they sell them anymore. I guess they realised they could 
make more money selling individual site certs.

The point about Apache 2.1 is that it includes a new module (as mentioned by 
Nick) which supports a new extension to TLS. This allows for "Server Name 
Indication" where the client tells the server what hostname it wants to connect 
to. Basically, it copies the Hostname up from the HTTP layer into the HTTPS 
layer making it visible to the TLS negotiation phase. When this is fully 
supported by browsers (NB - it's the browser that starts the conversation so it 
has to be aware of this new extension), then NBVH will be possible in SSL/TLS.

The other workaround is to wait for IPv6, then you get so many IP addresses 
that you don't need to bother with NBVH at all. I don't know which will come 
first...

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



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

---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: [EMAIL PROTECTED]
   "   from the digest: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to