From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040323 Description of problem: The following VirtualHost configuration does exist in our system: <VirtualHost 62.154.147.165:443> # # Globale Sicherheitseinstellungen # # TRACE/TRACK method RewriteEngine On RewriteCond %{REQUEST_METHOD} ^(TRACE|TRACK) RewriteRule .* - [F] # Access to CVS files <Files ~ "Entries|Entries.Log|Repository|Root"> Order allow,deny Deny from all </Files> ServerAdmin support DocumentRoot /export/data/kunden/www4.chamaeleon.de ServerName secure.chamaeleon.de CustomLog /var/log/httpd/secure.chamaeleon.de/access.log common_upload ErrorLog /var/log/httpd/secure.chamaeleon.de/error.log ErrorDocument 403 /403-7.htm SSLEngine On SSLCipherSuite ALL:!ADH:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP:+eNULL SSLCertificateFile /etc/httpd/conf/secure.chamaeleon.de/secure.chamaeleon.de.crt SSLCertificateKeyFile /etc/httpd/conf/secure.chamaeleon.de/secure.chamaeleon.de.ohnepwd.key SSLCACertificateFile /etc/httpd/conf/secure.chamaeleon.de/secure.chamaeleon.de.crt <Directory /export/data/kunden/www4.chamaeleon.de/adg/portalmanager> SSLOptions +OptRenegotiate SSLVerifyClient require SSLVerifyDepth 1 </Directory> php_flag register_globals on php_flag file_uploads on AddType application/x-httpd-php .php4 .php3 .phtml .php AddType application/x-httpd-php-source .phps </VirtualHost> The directory "/export/data/kunden/www4.chamaeleon.de/adg/portalmanager" contains the script that works on the form-submitted contents. It is protected by a client certificate and the configuration seems straightforward. After a while of using it we get "Method POST not allowed" when trying to use the script. We found documentation about this problem which is know since Apache-1.3.x. The SSL option "OptRenegotiate", as you can see in the directory clause, does not help. We placed it also before and after the directory clause and also removed it altogether. In any case we were able to reproduce the problem. Ralf Engelschall, the developer of mod_ssl, recommends to upgrade to mod_ssl-2.5.0, which is quite old. It seems that this bug returned somehow to the surface.. After some requests the renegotiation happens and results in the request being forbidden. Please also see the sysreport and the following log snippet from the Apache errorlog: [Wed May 19 15:28:01 2004] [error] Re-negotiation handshake failed: Not accepted by client!? [Wed May 19 15:28:40 2004] [error] SSL Re-negotiation in conjunction with POST method not supported!!hint: try SSLOptions +OptRenegotiate Version-Release number of selected component (if applicable): mod_ssl-2.0.46-32.ent How reproducible: Always Steps to Reproduce: 1. Repeatedly submit form with some arbitrary data until errormessage appears 2. 3. Actual Results: Method POST not allowed Errormessage from Apache. Expected Results: Normal form data handling. Additional info: There's really nothing obviously special about this.
Created attachment 100340 [details] sysreport output of the problematic system Maybe helpful.
Created attachment 100344 [details] sysreport output of the problematic system Maybe helpful.
Thanks for the report. This configuration requires a per-directory SSL renegotiation, since the SSLVerifyClient is placed inside the <Directory> block. Unfortunately, it is a known issue that mod_ssl in httpd 2.0 cannot perform per-directory renegotiations for requests with bodies (such as POST or PUT). mod_ssl for 1.3 handled this by buffering the entire POST body into memory; we are working on a better solution for 2.0. For some sites/configurations, it is acceptable to work around this by putting: SSLVerifyClient optional in the SSL vhost configuration, *outside* a directory block). This prompts the browser to send a client certificate in the initial SSL handshake, if one is available.
Thanks for the help. I added your suggested option and I'm now waiting for the customer triggered interaction. I will report about success here next week at the earliest. Apologies for the 2nd/redundant sysreport.
It was not possible to achieve the desired solution: protecting a directory on a https enabled server with a client certificate. We tried your helpful advice and also rearragend the different options in most thinkable ways. It was possible to access the entire directory without any client certificate or authentication after inserting the statement you suggestet. Everything happened in a quite indeterministic way. Finally we decided to ditch the requirement and protected the access just by IP address. Very ugly, but like that we avoided the bug in httpd. Unfortunately, since this is a production installation, we cannot play around with it anymore or test other configurations. But it seems you already have a way to reproduce this bug.
Sorry to hear you couldn't resolve the problem. For future reference, the configuration which is known to work is, e.g.: <VirtualHost www.example.com:443> SSLEngine On ... SSLVerifyClient optional </Virtual> <Location /private> # Location which requires client certificate protection SSLVerifyClient require </Location> from your comments above it appears you may have omitted the "SSLVerifyClient require" in the location context; apologies if my comments mislead you there.
Experimental test packages are now available which contain the fix for this issue. These packages are unsupported and have not gone through the Red Hat QA process. http://people.redhat.com/jorton/Taroon-httpd/ Any feedback from testing these packages is very welcome.
For tracking this bug against RHEL4, bug 170383 has been filed. Experimental RHEL4 test packages will be referenced from there shortly.
(In reply to comment #17) > Experimental test packages are now available which contain the fix for this > issue. These packages are unsupported and have not gone through the Red Hat QA > process. > > http://people.redhat.com/jorton/Taroon-httpd/ > > Any feedback from testing these packages is very welcome. > I add this very anoying bug, so I just installed these new RPMs. So far, so good... I'll tell you if I hit the problem again. thanks
(In reply to comment #17) > Experimental test packages are now available which contain the fix for this > issue. These packages are unsupported and have not gone through the Red Hat QA > process. > > http://people.redhat.com/jorton/Taroon-httpd/ > > Any feedback from testing these packages is very welcome. > I had this very anoying bug, so I've just installed these new RPMs. So far, so good... I'll tell you if I hit the problem again. thanks
The fix for this issue was included in RHSA-2006-0159. Thanks for the report. http://rhn.redhat.com/errata/RHSA-2006-0159.html