I don't really understand what can be wrong - your config looks OK and
if the logs and docroots are accurate, I don't see how it can be going
into the wrong VH. Therefore, you must be mistaken about the certificate
files.

Are you sure you don't have symlinks or something funny which could
allow one server to see the other's certs in place of its own?

When you say "gets the wrong cert" do you mean that you get a browser
warning "cert does not match FQDN"?

rgds,

Owen Boyle

>-----Original Message-----
>From: Alex Tang [mailto:[EMAIL PROTECTED]]
>Sent: Dienstag, 10. Dezember 2002 09:57
>To: [EMAIL PROTECTED]
>Cc: [EMAIL PROTECTED]
>Subject: Re: Problem with IP/Port Based (NOT Name Based) virtual hosts.
>
>
>Hi there.  Thanks for the help.  I have some followup comments 
>inline...
>
>
>On Tue, Dec 10, 2002 at 09:04:35AM +0100, Boyle Owen wrote:
>> You must be the first guy to figure this out from the docs! Well done
>> :-)
>
>Ha.  Thanks. :)
>
>> >However, I'm trying to setup my server (apache 2.0.43, OpenSSL
>> >0.9.7-beta5, RH Linux 7.3) to do IP or Port based virtual hosts.  
>> >
>> >It seems that the server will only ever use the first cert 
>declared.  
>> >
>> >I have the following in my httpd.conf (well, technically a 
>> >file included by httpd.conf)
>> >
>> >SSLSessionCache         dbm:/var/cache/mod_ssl/scache
>> >SSLSessionCacheTimeout  300
>> >SSLMutex  file:logs/ssl_mutex
>> >SSLRandomSeed startup builtin
>> >SSLRandomSeed connect builtin
>> >
>> ><VirtualHost 192.168.7.31:443>
>> >    ServerName                  A.funkware.com
>> >    ServerAdmin                 [EMAIL PROTECTED]
>> >    ErrorLog                    logs/A/error_log
>> >    CustomLog                   logs/A/access_log combined
>> >
>> >    SSLEngine on
>> >    SSLCertificateFile          /usr/local/etc/A.Cert
>> >    SSLCertificateKeyFile       /usr/local/etc/A.key
>> >
>> >    DocumentRoot                /webdocs/A
>> >
>> >    # other sundry virtual host directory stuff here.
>> ></VirtualHost>
>> 
>> Looks OK...
>> 
>> >
>> ><VirtualHost 192.168.7.33:443>
>> >    AddType                     application/x-x509-ca-cert .crt
>> >    AddType                     application/x-pkcs7-crl    .crl
>> >
>> >
>> >    ServerName                  B.funkware.com
>> >    ServerAdmin                 [EMAIL PROTECTED]
>> >    ErrorLog                    logs/B/error_log2
>> >    CustomLog                   logs/B/access_log2 combined
>> >
>> >    SSLEngine on
>> >    SSLCertificateFile          /etc/httpd/conf/httpd-cert-3443.cert
>> >    SSLCertificateKeyFile       /etc/httpd/conf/httpd-cert-3443.key
>> >
>> >    DocumentRoot                
>> >"/local/private/OpenCA/httpd/htdocs/pub"
>> >
>> >    # other sundry virtual host directory stuff here.
>> >
>> ></VirtualHost>
>> 
>> Looks OK too...  > 
>> 
>> >Like i said, when i startup the server, the first cert 
>(A.Cert) is used
>> >for both virtual hosts.  Does this seutp look correct?  Is 
>> >there something
>> >I missed?  
>> >
>> >Here are a couple more tidbits of info that i've learned...I 
>> >don't know if
>> >any of it is useful though...
>> >
>> >  * All the certs and keys are valid.  I've verified it 
>using OpenSSL.
>> >  * When I get the root page for  both virtual hosts, i get 
>the proper
>> >    page for each server.
>> 
>> What exactly do you mean here... Do you mean that:
>> 
>> https://A.funkware.com/ -> /webdocs/A
>> https://B.funkware.com/ -> /local/private/OpenCA/httpd/htdocs/pub
>> 
>> or do you mean via HTTP?
>
>Sorry about that.  I should have been more clear.  Your assumption was
>correct:
>
>    https://A.funkware.com/ -> /webdocs/A
>    https://B.funkware.com/ -> /local/private/OpenCA/httpd/htdocs/pub
>
>This part of the VirtualHost information is being properly 
>read and used.
>
>
>> >  * If i change the second "SSLCertificateFile" to a bogus file or
>> >    something that doesn't exist, the server will not startup (as
>> >    expected).  However, the second cert is still not used.
>> 
>> As you say, this is normal - missing files or directories 
>cause apache
>> to abort during startup, long before any network setup is done.
>
>Sure.  I understand.
>
>> >  * If i change the order (putting the VirtualHost 
>declaration for .33
>> >    before .31), the behavior is consistant: the 
>> >httpd-cert-3443.cert is
>> >    used for both servers.
>> 
>> I suspect a DNS or routing problem... I notice you have real ".com"
>> domain names which implies these sites are available on the internet.
>> However, the IP addresses are on the 192.168.0.0 private 
>network. This
>> implies that you have a firewall and/or router with network address
>> translation between the webserver and the web. Are you sure 
>that, after
>> NAT, A.funkware.com resolves to 192.168.7.31 and that B.funkware.com
>> resolves to 192.168.7.33?
>> 
>> I suspect that both FQDNs are resolving to the same internal IP
>> address... 
>
>You are correct again that I am working behind a firewall using the
>192.168.7/24 network.  Unfortunately, I know that the FQDNs 
>are correct (i
>run the DNS).  
>
>For my testing, I am working completely behind the wall, I am 
>running the
>client on a machine at 192.168.7.20, and my netmask on all machines is
>255.255.255.0, hence all machines are on the same subnet.  
>There is no NAT
>being done on my side of the firewall.
>
>Also, i get the same results if i connect using the IP Address 
>instead of
>the hostname.
>
>Here are some more things that I've discovered...
>
>  * The two virtual hosts have their respective error logs going to:
>     A -> logs/A/error_log
>     B -> logs/b/error_log2
>
>    It just so happens that the DNs for both certificates are not the
>    "correct" DNs for the servers:
>
>     A -> CN=*.funkware.com, O=Funkware, c=US
>     B -> CN=newx.funkware.com, O=Funkware, c=US
>
>    I know that either of these certs will work properly when 
>used solo.  
>
>    The thing about the improper CN in the DN is that when the server
>    starts up, the error log will complain that the DN in the cert is
>    improper.  For exmaple, in logs/A/error_log when the "A" 
>cert is used,
>    i see: 
>    
>      [Mon Dec 09 23:04:32 2002] [warn] RSA server certificate
>        CommonName (CN) `*.funkware.com' does NOT match server name!?
>
>    The thing i noticed is that BOTH of the error logs for the two
>    respective servers complain about the same name.  (The CN 
>in the error
>    message for both servers will be the same (either *.funkware.com if
>    the "A" Cert is used, or "newx.funkware.com" if the "B" 
>cert is used).
>
>  * If i use the openssl s_client to connect to the respective machines
>    (either using DNS or using the IP address), the cert is always the
>    same.
>
>Thanks again.  
>
>If there's any more information I can provide, please let me know.
>
>...alex...
>______________________________________________________________________
>Apache Interface to OpenSSL (mod_ssl)                   www.modssl.org
>User Support Mailing List                      [EMAIL PROTECTED]
>Automated List Manager                            [EMAIL PROTECTED]
>

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. 
______________________________________________________________________
Apache Interface to OpenSSL (mod_ssl)                   www.modssl.org
User Support Mailing List                      [EMAIL PROTECTED]
Automated List Manager                            [EMAIL PROTECTED]

Reply via email to