> -----Original Message----- > From: Joost de Heer [mailto:sanguis@xxxxxxxxx] > Sent: Montag, 7. November 2005 19:12 > To: Boyle Owen > Cc: users@xxxxxxxxxxxxxxxx > Subject: RE: [users@httpd] 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: users-unsubscribe@xxxxxxxxxxxxxxxx " from the digest: users-digest-unsubscribe@xxxxxxxxxxxxxxxx For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxx
|