Return-Path: Delivered-To: apmail-httpd-users-archive@httpd.apache.org Received: (qmail 86351 invoked by uid 500); 13 Jun 2003 13:09:16 -0000 Mailing-List: contact users-help@httpd.apache.org; run by ezmlm Precedence: bulk Reply-To: users@httpd.apache.org list-help: list-unsubscribe: list-post: Delivered-To: mailing list users@httpd.apache.org Received: (qmail 86263 invoked from network); 13 Jun 2003 13:09:15 -0000 Received: from unknown (HELO vistasource.com) (12.148.243.70) by daedalus.apache.org with SMTP; 13 Jun 2003 13:09:15 -0000 Received: from [10.2.0.1] (account kent HELO vistasource.com) by vistasource.com (CommuniGate Pro SMTP 4.0.5) with ESMTP id 314022 for users@httpd.apache.org; Fri, 13 Jun 2003 09:10:16 -0400 Message-ID: <3EE9CCFA.3050102@vistasource.com> Date: Fri, 13 Jun 2003 09:09:14 -0400 From: "Kent C. Kollasch" Organization: VistaSource User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: users@httpd.apache.org References: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N Subject: Re: [users@httpd] multiple virtual hosts that use both port 80 & 443 Boyle, Thank you. I had read and reread the VH section of the manual, but apparently the SSL encryption of the header didn't sink in. Your answer makes complete sense and accurately described the results I was seeing. Kent Boyle Owen wrote: >>-----Original Message----- >>From: Miguel Gonz�lez Casta�os [mailto:mgc@tid.es] >> >>Well, actually all my VHs are HTTP not HTTPs but only the >>default (the https I mean), > > > I still don't quite understand you, I'm afraid... I will explain a bit further: Virtual Hosting is the mechanism where the server uses some attribute of the request to assign the request to one of many websites (i.e. VHs). There are three ways that this can be done: > > - IP-based: assignment depends on IP address. Each VH has to have a separate IP. > - Port-based: assignment depends on port number. Each VH has to have a separate port number. This is how we normally do SSL - the SSL VH Listens on port 443 while plain HTTP Listens on port 80. > - Name-based: assignment depends on the "Host" header in the HTTP request which usually contains the name of the website (e.g. www.mysite.com). This is the most popular and versatile method because it allows you to have any number of VHs on the same IP and port - great for hosting! > > You can mix all these methods together as much as you like (as long as you don't create any logical inconsistencies). In fact, this is what normally happens on a production server where you have several NBVHs on port 80 and one SSL VH on port 443. > > Note that the first two methods (IP and port) use attributes of the TCP/IP layer while the third (name-based) uses an attribute of the HTTP layer. This has an important effect in the case of SSL. As you know, SSL encrypts the packets so the "Host" header (which is inside the packet) is not available to the server at the start of the transaction. Hence it cannot choose the correct NBVH. The ip and port information are at TCP/IP level and are not encrypted and this is why SSL VHs have to be TCP/IP based. > > >>This weekend I will try to add more SSL VHs to see if you are right. > > > I rather think I might be right, but by all means test it out (don't believe everything you read on mailing lists :-). One thing to be careful of, however: If you set up two SSL NBVHs and give them the same certificate file, it will *appear* to work! That is, if you do: > > NameVirtualHost 192.168.1.2:443 > > > ServerName server1 > SSLCert mycert > > > > ServerName server2 > SSLCert mycert > > > You will find that https://server1/ and https://server2/ will in fact lead to the correct sites! > > What is happening is that the request comes in encrypted on port 443. Apache doesn't know what VH to give it to (the Host header is encrypted) so goes to the *first* VH on port 443. Apache gets "mycert" sends it to the client and establishes the session. Now apache *can* decrypt the packets so any subsequent requests can be read and the NBVH mechanism "works". > > However, there is a problem. Apache is always using the cert from the first VH. The cert in VH2 never gets used, even if the request is for server2 (because the session has already been established using the cert in VH1). > > This might not be a problem in a lab or intranet environment, but this will never work in the real world because any request for server2 will cause a warning to pop up in the browser that the cert doesn't match the requested URL (remember that the cert contains within it the "common name" of the website it belongs to). If the cert belongs to server1 then that will work OK, but if someone requests server2 they will get a warning. > > This warning is very important because it means that the cert is being used for a different site from that which it was created for. In other words, the site cannot be authenticated and you should not trust it. To put it another way, would you type in your credit card number to a site called "www.amazon.com" if your browser was telling you that "the certificate does not belong to www.amazon.com"? You certainly shouldn't... > > Rgds, > Owen Boyle > Disclaimer: Any disclaimer attached to this message may be ignored. > >>Regards >> >>Miguel >> >>Boyle Owen ha escrito: >> >> >>>>-----Original Message----- >>>>From: Miguel Gonz�lez Casta�os [mailto:mgc@tid.es] >>>> >>>>NameVirtualHost 192.168.1.2:443 >>>> >>>>ServerName server1 >>>> >>>> >>>> >>>>ServerName server2 >>>> >>> >>>If these are supposed to be SSL VHs, this won't work. You can't do >>>name-based VHs with SSL. >>> >>>If they are plain HTTP VHs then it will work but it's a bit >> >>silly to use >> >>>port 443 for plain HTTP since this port is reserved for HTTPS (you >>>wouldn't use port 25 for HTTP, would you?). >>> >>>Perhaps if the original poster could be a bit clearer on >> >>what he wants >> >>>to do? >>> >>>Rgds, >>>Owen Boyle >>>Disclaimer: Any disclaimer attached to this message may be ignored. >>> >>> >>>> >>>> >>>>"Kent C. Kollasch" ha escrito: >>>> >>>> >>>>>Is it possible to set up multiple virtual hosts that use >>>> >>>>both port 80 & >>>> >>>>>443? So far, I've only been able to get it two work with >>>> >>>>two vh's. The >>>> >>>>>other ones seem to redirect to the default server. I >>>> >>didn't have the >> >>>>>same problem with apache 1.3.7 (currently using 2.0.40). >>>>> >>>>>-- >>>>>******************************* >>>>>Kent C. Kollasch >>>>>Manager, IT >>>>>VistaSource, Inc. >>>>>117 Flanders Rd. >>>>>Westboro, MA 01581 >>>>> >>>>>Phone: (774) 760-1015 >>>>>mailto:kent@vistasource.com >>>>> >>>>>Check out our web pages!! >>>>>http://www.vistasource.com -> VistaSource's Home page >>>>>http://www.anywarerealtime.com -> Solutions for optimized >>>> >>>>data retrieval >>>> >>>>>and optimized data analysis. >>>>> >>>>> >>>> >>--------------------------------------------------------------------- >> >>>>>The official User-To-User support forum of the Apache HTTP >>>> >>>>Server Project. >>>> >>>>>See for more info. >>>>>To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org >>>>> " from the digest: users-digest-unsubscribe@httpd.apache.org >>>>>For additional commands, e-mail: users-help@httpd.apache.org >>>> >>>> >>>--------------------------------------------------------------------- >>> >>>>The official User-To-User support forum of the Apache HTTP >>>>Server Project. >>>>See for more info. >>>>To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org >>>> " from the digest: users-digest-unsubscribe@httpd.apache.org >>>>For additional commands, e-mail: users-help@httpd.apache.org >>>> >>>> >>> >>>Diese E-mail ist eine private und pers�nliche Kommunikation. Sie hat >>>keinen Bezug zur B�rsen- bzw. Gesch�ftst�tigkeit der SWX >> >>Swiss Exchange. >> >>>This e-mail is of a private and personal nature. It is not related to >>>the exchange or business activities of the SWX Swiss Exchange. Le >>>pr�sent e-mail est un message priv� et personnel, sans rapport avec >>>l'activit� boursi�re de la SWX Swiss Exchange. >>> >>>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 for more info. >>>To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org >>> " from the digest: users-digest-unsubscribe@httpd.apache.org >>>For additional commands, e-mail: users-help@httpd.apache.org >> >> >>--------------------------------------------------------------------- >>The official User-To-User support forum of the Apache HTTP >>Server Project. >>See for more info. >>To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org >> " from the digest: users-digest-unsubscribe@httpd.apache.org >>For additional commands, e-mail: users-help@httpd.apache.org >> >> > > Diese E-mail ist eine private und pers�nliche Kommunikation. Sie hat keinen Bezug zur B�rsen- bzw. Gesch�ftst�tigkeit der SWX Swiss Exchange. This e-mail is of a private and personal nature. It is not related to the exchange or business activities of the SWX Swiss Exchange. Le pr�sent e-mail est un message priv� et personnel, sans rapport avec l'activit� boursi�re de la SWX Swiss Exchange. > > > --------------------------------------------------------------------- > The official User-To-User support forum of the Apache HTTP Server Project. > See for more info. > To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org > " from the digest: users-digest-unsubscribe@httpd.apache.org > For additional commands, e-mail: users-help@httpd.apache.org > --------------------------------------------------------------------- The official User-To-User support forum of the Apache HTTP Server Project. See for more info. To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org " from the digest: users-digest-unsubscribe@httpd.apache.org For additional commands, e-mail: users-help@httpd.apache.org