Description of problem: We have a site that with RHEL 5.4 (httpd and mod_ssl 2.2.3-31) prompted the user for a client certificate due to a "SSLVerifyClient require" statement. When upgrading to RHEL 5.5 (httpd and mod_ssl 2.2.3-43), it stops working with IE, and with Firefox, it works randomly, maybe depending on the browser version. Currently we have restored the backup for 5.4 to keep the environment working, but we'd like to upgrade to 5.5 because this also affects other systems. There's nothing in logs when using IE (we didn't try hard debugging because we couldn't stand without working). How reproducible: Always Steps to Reproduce: 1. Set SSLVerifyClient require in apache config 2. Browse with IE 3. Actual results: IE fails to authenticate, unlike firefox (but not always firefox succeeds). Expected results: Any browser should be asked for the client certificate Additional info: We have set these SSL options, according to examples: SSLOptions +FakeBasicAuth +ExportCertData +StrictRequire SSLCipherSuite ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP SetEnvIf User-Agent ".*MSIE.*" \ nokeepalive ssl-unclean-shutdown \ downgrade-1.0 force-response-1.0 but no luck at all
According to some investigation with httpd developers, it looks like there's a relationship with https://issues.apache.org/bugzilla/show_bug.cgi?id=44073 If this fixes the problem, it looks that the old httpd version supplied with RHEL needs a big upgrade (it's for 2.2.6), and it would be the only solution.
Oscar, I'd recommend you contact Red Hat Support in the first instance where you need help troubleshooting a problem like this. The upstream bug you reference is not present in the 5.5 httpd package, and the code paths in question would not get executed in a configuration as you indicate. If you are placing "SSLVerifyClient require" in Directory or Location context, and this problem only occurs with 5.5 and is browser-dependent, then it is highly likely that the issue is due to the secure renegotiation fixes, see: https://access.redhat.com/kb/docs/DOC-20491 for more information. If using "SSLInsecureRenegotiation on" makes the problem go away, that will confirm that hypothesis. See the above kbase entry and: http://httpd.apache.org/docs/2.2/mod/mod_ssl.html#sslinsecurerenegotiation for more information.
Hi, Joe. Your suggestion fixed the problem. Thank you very much.
OK. Please be sure to understand the security implications from using that directive, as described in the kbase article. I'm closing this bug.