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ávra <vavra@xxxxxx>
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
<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.
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ávra <vavra@xxxxxx>
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
<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.
