Ahhh, now I begin to understand. I was incorrectly thinking the secure channel just could not be established. You say it is established but defaults to using the first certificate it can find. That would mean I can forget about my next step, which would have been to try different certificates for different hosts. I can either live with the name mismatch, or use IP-based VHosts.
Thanks for your help, Jeff. I did look in the archives, but either you have explained it better or else the explanations have finally started to sink in. > -----Original Message----- > From: Jeff [mailto:[EMAIL PROTECTED]] > Sent: Friday, April 05, 2002 12:49 PM > To: [EMAIL PROTECTED] > Subject: Re: SSL and vhosts > > > Keith, > > Perhaps it would be better to say "Name-based VHosts will not work > correctly or as expected".. > If you search the archives, you will find this has been > brought up many > times and some very good explanations.. > > Basically, the securing of the channel between browser and > server is done > BEFORE any HTTP request is sent to the server - so it is > impossible for the > server to know which name-based VHost you actually want (it > will use the > certificate for the first NBVH) > However, after the channel is secured, then the HTTP request > is sent, and > the server can identify which NBVH you want and reply appropriately.. > > Naturally, it is impossible for the certificate of the first > NBVH to match > more than one NBVH, so users access any other NBVH will always get a > certificate/server name mismatch.. > > Only option for it to work correctly is to use different IP/Port > combinations for each SSL-required VHost > > Rgds > Jeff > > ----- Original Message ----- > From: "Hunt,Keith A" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Saturday, April 06, 2002 3:21 AM > Subject: RE: SSL and vhosts > > > > > > Well, that all depends on what one is trying to accomplish > -- this case > is for a known, limited, internal user population. As I > said, the mismatch > between host names and cert names is expected at this point. > Heck, the > cert I am using doesn't match the box at all, let alone the > vhost name. > This is still a test machine. My next step would be to see > if separate > certs could be used for separate vhosts and eliminate the > mismatched name > problem. I haven't decided whether that is even very important for my > purposes. > > > > What is perplexing to me is not the mismatched names issue, > but rather > why this works at all when everything I have read says it > won't. That is, > it won't work at all in the sense that the encrypted > connection cannot be > established because of the sequence things are done in the handshake. > > > <snipped> > > > > -----Original Message----- > > > > From: Hunt,Keith A [mailto:[EMAIL PROTECTED]] > > > > Sent: Friday, April 05, 2002 8:20 AM > > > > To: [EMAIL PROTECTED] > > > > Subject: SSL and vhosts > > > > > > > > > > > > > > > > Please pardon me if this is a dumb question. I have read > > > that SSL and > > > > name-based vhosts cannot be done, yet I set it up and it > > > > seems to be working > > > > OK, apart from the expected complaints about mismatched host > > > > name and server > > > > certificate. Am I missing something? I am running Apache > > > > 1.3.23 and modssl > > > > 2.8.7. on Linux > > > > > > > > > > > > Keith Hunt 330.972.2968 [EMAIL PROTECTED] > > > > Internet & Server Systems > > > > The University of Akron > > > > ______________________________________________________________________ > Apache Interface to OpenSSL (mod_ssl) www.modssl.org > User Support Mailing List [EMAIL PROTECTED] > Automated List Manager [EMAIL PROTECTED] > ______________________________________________________________________ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
