https://issues.apache.org/bugzilla/show_bug.cgi?id=49731
--- Comment #4 from Dave Longley <[email protected]> 2010-08-10 15:12:08 EDT --- (In reply to comment #3) > (In reply to comment #2) > > > The problem seems to persist in version 2.2.16. I have two site > > configurations > > where one uses 'SSLClientVerify optional_no_ca' and another uses > > 'SSLClientVerify none'. When using a TLS client (one that prints out the SNI > > hostname that it is sending the server), I receive a CertificateRequest for > > Are you sure that your httpd 2.2.16 was compiled against a SNI capable openssl > and that it is running against one? E.g RHEL 4 / 5 provided openssl packages > are NOT SNI capable. Yes. I am printing out the data sent to the server and it includes the SNI entry. > > > both sites. The content served does (correctly) depend on the hostname > > provided, so the virtual host option is functioning correctly. > > > > I will try to confirm this using two vanilla configurations and add them to > > this bug (and reopen it if confirmed). Perhaps that will reveal it is only a > > configuration issue. I assume Apache 2.2.16 is the latest version you're > > referring to of 2.2? I can find tarballs for 2.3.6 but I didn't think that > > you > > meant Apache 2.3. > > Yes, I meant the latest 2.2. I have confirmed that this is fixed in the latest version of Apache. In the quick test I ran before my last comment I didn't specify the host+port in the command line options for openssl s_client. They must be specified in addition to the -servername option, it will not default in the way one might think (but this is an openssl issue). After creating vanilla configurations and running everything through it all worked correctly with both the 'SSLVerifyClient require' and 'SSLVerifyClient optional_no_ca' options combined with 'SSLVerifyClient none' for the other host. This is why it's good to confirm :). Everything works now with Apache 2.2.16. Thanks! -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
