Return-Path: Delivered-To: apmail-httpd-dev-archive@www.apache.org Received: (qmail 6880 invoked from network); 17 May 2010 05:01:46 -0000 Received: from unknown (HELO mail.apache.org) (140.211.11.3) by 140.211.11.9 with SMTP; 17 May 2010 05:01:46 -0000 Received: (qmail 93388 invoked by uid 500); 17 May 2010 05:01:45 -0000 Delivered-To: apmail-httpd-dev-archive@httpd.apache.org Received: (qmail 93097 invoked by uid 500); 17 May 2010 05:01:45 -0000 Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm Precedence: bulk Reply-To: dev@httpd.apache.org list-help: list-unsubscribe: List-Post: List-Id: Delivered-To: mailing list dev@httpd.apache.org Received: (qmail 93089 invoked by uid 99); 17 May 2010 05:01:44 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 17 May 2010 05:01:44 +0000 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: local policy) Received: from [62.75.148.60] (HELO appendix.velox.ch) (62.75.148.60) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 17 May 2010 05:01:37 +0000 Received: from cortex.velox.ch (84-75-163-235.dclient.hispeed.ch [84.75.163.235]) (authenticated bits=0) by appendix.velox.ch (8.14.4/8.14.4/2.0) with ESMTP id o4H51FE5003522 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 17 May 2010 07:01:16 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=velox.ch; s=appendix-177f; t=1274072476; bh=X0c5P7aYoWdrBySnfHRkxv4CBzVOpB01fVTFYuX6224=; h=Message-ID:Date:From:MIME-Version:To:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=Csinb3UNMMfeQRKucIWBQAJ+X2VPPlfZFSYEZV8MSRxeikKYzxGD4qT9mrF+jOcMT TZfGbfdIBa+Z7G5TO8z4oQIgvQtVE2KPMxxVUvBicpTOJaN+pVoZqhRV6Ls1MFGQxa PIEY58UgoOcBKFl2mqnR3NUcbpHi458gTwekkR13QLhmMpePXtEenBlStrSRzlloYa Y8lRqnu0TWG8IbO8E0Fcno+/1+fDShh83T9gnjUcJZQ4s8ZKylJdSufvKCHHt07bHr 5bSoTVdYeimuCtiR/iUWEOo852e9PKefVZ6xxZpS3mO+ryHs75nQOWN7pq1e9fXtug dejHA+VIp1fEA== Message-ID: <4BF0CD98.5090306@velox.ch> DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=velox.ch; s=cortex-8a58; t=1274072475; bh=X0c5P7aYoWdrBySnfHRkxv4CBzVOpB01fVTFYuX6224=; h=Date:From:MIME-Version:To:Subject:References:In-Reply-To: Content-Type:Content-Transfer-Encoding; b=KSYMEyw33Ag+dp1IMAhMClsyw6g8xlL6CkHkqwjx154vqUvSJIDcF3wy+8rX8RMBB 6C7DCtc5EA6auJb0UmPtKfMJvgNA1aqTL6UMQUKRMRnoKqpYiMAGdoj3s8LnYKTNvF PHOCZLG/z32Tagj5TxWGTffHjnDSK8TENoq78XAoQDiMLSNL5xWBisy9kgwJJzQxkI 1E1IFitjtz9X0JoEGBWmSHrZzB62p7tP+0kyiiCIn8jqQEz+ZBazCgWgqcj6Hwbh/U J7dQpnCE4u7vkZJFynM6R9Zo5R8CpJCetl7mOophC5C5pyG1xZCuUMmLmm5ii2XziB XmHQfvxAtdeSQ== Date: Mon, 17 May 2010 07:01:12 +0200 From: Kaspar Brand User-Agent: Thunderbird/3.0 MIME-Version: 1.0 To: dev@httpd.apache.org Subject: Re: [users@httpd] ssl certifikate mismatch References: <4BEDB7D4.9020106@metaways.de> <4BEFDA10.4090807@metaways.de> <4BF03D74.6090507@metaways.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org > On Sun, May 16, 2010 at 3:14 PM, Eric Covener wrote: >> User has a non-NVH on 10.137.1.104:9902 (CN=aaa.de)and insists SNI is >> choosing the SSL configuration from a different VH that (CN=aaa.at) >> comes earlier and b) has a matching servername. I can't reproduce/confirm this behavior with 2.2.15. Did the user doublecheck that the www.aaa.at.crt and www.aaa.de.crt files really have the proper contents? >> I think that 10.137.1.104 was sent, but i'm not sure if any SNI >> hostname was sent. I called it like this: openssl s_client -connect >> 10.137.1.104:9902 openssl s_client doesn't send any SNI extension by default (needs to be specified with -servername, if desired). The code in mod_ssl which possibly switches to a different certificate (through OpenSSL's SSL_set_SSL_CTX) is only reached from ssl_callback_ServerNameIndication(). And this callback is not executed if there's no SNI extension in the ClientHello (at APLOG_DEBUG, mod_ssl will log the outcome of ap_vhost_iterate_given_conn, but my prediction is that the user won't see any such messages if he's using s_client w/o the servername switch). Kaspar