Return-Path: X-Original-To: apmail-httpd-users-archive@www.apache.org Delivered-To: apmail-httpd-users-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 7399D10D83 for ; Wed, 23 Oct 2013 13:37:15 +0000 (UTC) Received: (qmail 22457 invoked by uid 500); 23 Oct 2013 13:36:47 -0000 Delivered-To: apmail-httpd-users-archive@httpd.apache.org Received: (qmail 22397 invoked by uid 500); 23 Oct 2013 13:36:45 -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: List-Id: Delivered-To: mailing list users@httpd.apache.org Received: (qmail 22360 invoked by uid 99); 23 Oct 2013 13:36:43 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 23 Oct 2013 13:36:43 +0000 X-ASF-Spam-Status: No, hits=1.5 required=5.0 tests=HTML_MESSAGE,NORMAL_HTTP_TO_IP,RCVD_IN_DNSWL_LOW,SPF_PASS,WEIRD_PORT X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of mbachmann@google.com designates 209.85.212.42 as permitted sender) Received: from [209.85.212.42] (HELO mail-vb0-f42.google.com) (209.85.212.42) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 23 Oct 2013 13:36:36 +0000 Received: by mail-vb0-f42.google.com with SMTP id e12so496270vbg.15 for ; Wed, 23 Oct 2013 06:36:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=dbcbGmbS75cckbpvcFaFZYLcFyDTzjZJatAcqoMlTB4=; b=PSTl2o0SQ7Ql1toWzyUAMAoU2SIJm63Q1uA0L1fyhXADtklJ9kyN6UhgtYCmbtk3pG 6+EWR12BOVyYzrWYlt7hwA0XhwbHi0/J7Uu+afgh/1JA77m8edHR2iA/FU2d3H+f5Pjm gqOJJXybPNDZKrrdwVAD38jNCghhPK2pwO2C7BcjUFHogpMC24rZiwWdgNL+3F9wRl95 GBLLQptcjYjGdYD8ba0oLtcnYD9eAVnJ87GrGpD5dLcxQAkoFjmRSJl3D2pp8j0BMeWS LC/nZzNFbLR67Q7junjRwrwTGwuGKepM9bDkQS9k9GLXOJTwHHQ/81f8wl6i6LDC6ijn Kjkg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=dbcbGmbS75cckbpvcFaFZYLcFyDTzjZJatAcqoMlTB4=; b=FLubdqpwV4L22HTrflANAibv74HBvPDLQEvxbeCSrg7IB5LMfXvU2SJCpdI3ICEru0 xSzR4596gBWk9e32ZeIvQ8uBpoqyketztEURLSRQ6OWSms36rbUd8z4OLB6GVEhFxyhh bjm3XRic78v0FKrem0PcN6XYGVHLD7vAQF9DrLeTikx4upszPSrkFj/bSXy5Qtdc5PP0 xauenhZ8Ut5zubXtnA1VQ2asE0kKQtT5z/3gqA0MSFsB2BB9NhC9YFAlbK/63SbW/pbX J/w30JgtIn8TFfB8qAd1mSjEEegqeEXV8PWRUhSM50OuGyTvBYUk/pLeVc07RA52kd2y ER8w== X-Gm-Message-State: ALoCoQkqdGugmcIt/pqNfFU3weWMyhHcRh7J/ucDLm8iX4c1TTIA9Q4P4UzGuO84GeWsGumyjloIAAm/CLLmpiHeiuRyolHfrc2DZgwETmpNF6D3q6E/UA5ovNIeWpF2dOatadHQXI7v0x33G3WBK/hVjCe6YtZpdWAeY9eWL8ACiYqA+kOty8lQjc9daxIJ5BVgQWFIRL7BtPSkZXdCEfVQD2vlhKUVkQ== MIME-Version: 1.0 X-Received: by 10.220.199.5 with SMTP id eq5mr1170631vcb.16.1382535375466; Wed, 23 Oct 2013 06:36:15 -0700 (PDT) Received: by 10.52.181.33 with HTTP; Wed, 23 Oct 2013 06:36:15 -0700 (PDT) In-Reply-To: <52677744.2020703@602.cz> References: <5266E50F.3010406@602.cz> <52677744.2020703@602.cz> Date: Wed, 23 Oct 2013 09:36:15 -0400 Message-ID: From: Matthew Bachmann To: users@httpd.apache.org Content-Type: multipart/alternative; boundary=047d7b5db26af1c57704e96899b0 X-Virus-Checked: Checked by ClamAV on apache.org Subject: Re: [users@httpd] wrong certs --047d7b5db26af1c57704e96899b0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Try your same config but use A for the ServerName in both VirtualHost sections. Based on what I've seen, you should then get 1.crt from either port, and never get 2.crt, which seems like a bug. On Wed, Oct 23, 2013 at 3:14 AM, Jan V=E1vra wrote: > Hello, > it is obvious you are using port based virtual host. My question was for > assuring you have configured basics well. > So I suppose you have: > > > Listen *:424 https > > ServerName A > SSLCertificateFile 1.crt > *SSLCertificateKeyFile 1.key* > > #and probably also > SSLCertificateChainFile chain.crt > > > > > I have made a test and it works fine. > I do not use wildcards, I directly specify the IP address. > > Listen 424 https > Listen 444 https > > ServerName A > SSLCertificateFile 1.crt > SSLCertificateKeyFile 1.key > > > > ServerName B > SSLCertificateFile 2.crt > SSLCertificateKeyFile 2.key > > > and in my hosts file there are recors > 192.168.1.211 A > 192.168.1.211 B > > Try to call httpd -S. In my case it shows > VirtualHost configuration: > .... > 192.168.1.211:424 A (1.conf) > 192.168.1.211:444 B (2.conf) > > For A and B I use some real names eg. www.mycompany1.cz, www.mycompany2.c= z > . > > Do you even know about name based virtual https host? > http://wiki.apache.org/httpd/NameBasedSSLVHostsWithSNI > Most clients support this and I use it in production. > > Jan > > The certificates are specified in port based virtual hosts, there is no > NameVirtualHost here. So I would expect the specified certificate to be > served on the corresponding port no matter what host header was passed. > > > On Tue, Oct 22, 2013 at 4:50 PM, Jan V=E1vra wrote: > >> Hello. >> For sure have you not forgotten specifying option SSLCertificateKeyFile >> ? >> What is the url you are using? >> If you use https://localost:424 instead of https://a:424, you can get >> weird results. >> >> I can also try it, if your problem persists. My last several years is >> full of creating and using certificates ;-) >> >> Jan. >> >> >> I two virtual hosts on different ports specify different certificate >>> files, but use the same ServerName, both ports use the same certificate= . >>> Is this expected behavior? >>> >>> >>> With this config: >>> >>> Listen *:424 https >>> >>> ServerName A >>> SSLCertificateFile 1.crt >>> >>> >>> Listen *:444 https >>> >>> ServerName A >>> SSLCertificateFile 2.crt >>> >>> >>> connecting to either 424 or 444, I get cert 1. >>> >>> With this config: >>> >>> Listen *:424 https >>> >>> ServerName A >>> SSLCertificateFile 1.crt >>> >>> >>> Listen *:444 https >>> >>> ServerName B >>> SSLCertificateFile 2.crt >>> >>> >>> connecting to 424 gets me cert 1, and connecting to 444 gets me cert 2. >>> >>> >>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org >> For additional commands, e-mail: users-help@httpd.apache.org >> >> > > --047d7b5db26af1c57704e96899b0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Try your same config but use A for the ServerName in both = VirtualHost sections. =A0Based on what I've seen, you should then get 1= .crt from either port, and never get 2.crt, which seems like a bug.


On Wed, Oct 23, 2013 at 3:14 AM, Jan V= =E1vra <vavra@602.cz> wrote:
=20 =20 =20
Hello,
=A0it is obvious you are using port based virtual host. My question was for assuring you have configured basics well.
=A0So I suppose you have:


Listen *:424 https
<VirtualHost *:424>
ServerName A
SSLCertificateFile 1.crt
SSLCertificateKeyFile 1.key

#and probably also
SSLCertificateChainFile chain.crt

</VirtualHost>


I have made a test and it works fine.
I do not use wildcards, I directly specify the IP address.

Listen 424 https
Listen 444 https
<VirtualHost 192.168.1.211:424>
=A0ServerName A
=A0SSLCertificateFile 1.crt
=A0SSLCertificateKeyFile 1.key
</VirtualHost>

<VirtualHost 192.168.1.211:444>
=A0ServerName B
=A0SSLCertificateFile 2.crt
=A0SSLCertificateKeyFile 2.key
</VirtualHost>

and in my hosts file there are recors
192.168.1.211 A
192.168.1.211 B

Try to call httpd -S. In my case it shows
VirtualHost configuration:
....
192.168.1.211:= 424=A0=A0=A0=A0=A0 A (1.conf)
192.168.1.211:= 444=A0=A0=A0=A0=A0 B (2.conf)

For A and B I use some real names eg. www.mycompany1.cz, www.mycompany2= .cz.

Do you even know about name based virtual https host?
http://wiki.apache.org/httpd/NameBasedSSLVHostsWithSNI<= br> Most clients support this and I use it in production.

Jan

The certificates are specified in port based virtual hosts, there is no NameVirtualHost here. =A0So I would expect the specified certificate to be served on the corresponding port no matter what host header was passed.


On Tue, Oct 22, 2013 at 4:50 PM, Jan V=E1vra <vavra@602.cz> wrote:
Hello.
=A0For sure have you not forgotten specifying option SSLCertificateKeyFile =A0?
=A0What is the url you are using?
=A0If you use https://localost:424 instead of https://= a:424, you can get weird results.

=A0I can also try it, if your problem persists. My last several years is full of creating and using certificates ;-)
=A0Jan.


I two virtual hosts on different ports specify different certificate files, but use the same ServerName, both ports use the same certificate. =A0Is this expected behavior?


With this config:

Listen *:424 https
<VirtualHost *:424>
ServerName A
SSLCertificateFile 1.crt
</VirtualHost>

Listen *:444 https
<VirtualHost *:444>
ServerName A
SSLCertificateFile 2.crt
</VirtualHost>

connecting to either 424 or 444, I get cert 1.

With this config:

Listen *:424 https
<VirtualHost *:424>
ServerName A
SSLCertificateFile 1.crt
</VirtualHost>

Listen *:444 https
<VirtualHost *:444>
ServerName B
SSLCertificateFile 2.crt
</VirtualHost>

connecting to 424 gets me cert 1, and connecting to 444 gets me cert 2.




---------------------------------------------------------------= ------
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org




--047d7b5db26af1c57704e96899b0--