Hello,
Late to the party but I thought I'd mention that I have seen this as
well, with a difference however.
I've seen it on two different servers, both using SNI hosts. It happens
to me a lot when logging into joomla administrator in Firefox. Since I
use no other browser I cannot comment on is it a Firefox bug or not. I
can however state that on both servers, there is a redirect to force
http to https.
My sneaky suspicion was that the redirect is causing the problem but I
am currently unable to get it to fail at the moment. My suspicion
arrives out of the fact I have download manager that does not have the
redirect on it and I just use https instead of http. I cannot recall
that I have ever had it happen when using it, so I was thinking that
when you login in joomla, the script calls http, the redirect forces it
to https and I get a warning about the cert not matching. Viewing the
cert it is the _default_ SSL hosts certificate.
However, that is not the case either since I made a script to do just
that for testing an I get a "sent over unecrypted" warning doing that,
so this is not the case either as I do not get that warning logging into
Joomla.
It could be cgi related since joomla is php and the other times on the
other server it was a perl script. I'm however not sure if it has
happened on static content since, I do not recall it happening but some
days I cannot recall what I did the prior day. It doesn't have a trigger
that I can find to pull and be able to give you a test case for it. It's
a head scratcher since it does not happen every time.
Either the OP is not crazy or we both are crazy. I do not plan on
subscribing to the user list or I would ask the OP about browser/s,
static vs. dynamic content and redirects.
Regards,
Gregg
Kaspar Brand wrote:
On Sun, May 16, 2010 at 3:14 PM, Eric Covener <[email protected]> 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
