Red Hat Bugzilla – Bug 101514
mod_ssl from apache is compiled with SSL_CONSERVATIVE (bad)
Last modified: 2007-04-18 12:56:33 EDT
From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030630 Description of problem: mod_ssl from httpd is compiled with -DSSL_CONSERVATIVE which yields erroneous behavior when attempting to negotiate an SSL connection with a client presenting a certificate during a POST operation: http://www.mail-archive.com/modssl-users@modssl.org/msg16177.html http://www.mail-archive.com/modssl-users@modssl.org/msg15667.html Having SSLVerifyClient work with POSTs is absolutely essential in using Apache's httpd as a commercial Web Services provider, since HTTP POSTs are the transportation of choice for protocols like SOAP and REST, and client certificate authentication is necessary for securing those transactions. The results of compiling with SSL_CONSERVATIVE have far-reaching negative effects into SSL POST operations in PHP, FastCGI servers, and just about everything else you can think of. Version-Release number of selected component (if applicable): httpd-2.0.40-21.3 How reproducible: Always Steps to Reproduce: You can see that the operations have been left out of RedHat's version of httpd by doing the following: # This should print out at least one function name strings /etc/httpd/modules/mod_ssl.so | grep suck Actual Results: As it now stands, the appropriate functions are missing from the binary version of httpd, and a POST using SSL will fail if SSLVerifyClient is anything other than "none", resulting in a message in /etc/httpd/logs/ssl_error_log: "SSL Re-negotiation in conjunction with POST method not supported!!hint: t ry SSLOptions +OptRenegotiate" Expected Results: If SSL_CONSERVATIVE was not given as a compile flag to mod_ssl, then an SSL POST with SSLVerifyClient set to "optional_no_ca" should work just as it would with SSLVerifyClient set to "none". Additional info:
Okay, this is actually not a bug for RedHat. SSL_CONSERVATIVE has been removed and its functionality has become part of the standard Apache 2.0 web server. The problem is the functions which fix this behavior have not been rewritten to take advantage of the Apache 2 API. I'm not sure what the appropriate resolved state is, so I'll leave that to someone who knows better, but this is not a RedHat build issue.
This is being tracked upstream as: http://nagoya.apache.org/bugzilla/show_bug.cgi?id=18395 Thanks for the report.