when configuring SSLVerifyClient directive from global none to location require, php scripts inside location are no more able to receive post data. Error Method Not Allowed then occurs. error log shows "[error] SSL Re-negotiation in conjunction with POST method not supported!" when SSLVerifyClient is set to 'required' but not when set to 'none' this configuration inside ssl virtualhost section activate the bug : ---- SSLEngine on SSLVerifyClient none SSLVerifyDepth 1 SSLOptions +OptRenegotiate <location /consultation/ > SSLVerifyClient require </location> ---- this configuration does not activate the bug : SSLEngine on SSLVerifyClient require SSLVerifyDepth 1 SSLOptions +OptRenegotiate <location /consultation/ > SSLVerifyClient require </location>
[This is a mass bug update.] This bug reports a problem in an older version of Apache 2. Could you please update to the most recent version and see if you can reproduce this problem. If the bug still exists, please update the bug with the latest version number. If the bug no longer exists, please close the bug report. Sorry for this impersonal response, but we get many more bug reports than our volunteers can keep up with. Thanks for using Apache!
This bug exists also in Apache/2.0.43 (WIN32) mod_ssl/2.8.11 OpenSSL/0.9.6g. This bug appears when runnimg under both Windows NT4.0 and XP(NT5.1).
Addition to last comment: Sorry, it must read Apache/2.0.43 (WIN32) mod_ssl/2.0.43 OpenSSL/0.9.6g
I observe the same bug with Apache 2.0.43 running on Linux 2.4.19 box, but with proprietary script handler.
Also observed on a Linux RedHat 8.0 (2.4.18-17 kernel) box running apache 2.0.43-1, mod_ssl-2.0.43-1 and php 4.2.2-8.
After setting up SSL to require client authentication and importing the certificates into browsers, it works with Netscape 4.79 but not MSIE6 (6.0.2800.1106.xpsp1.020828-1920). The https error file says: [error] SSL handshake failed (server myserver.com:443, client 192.168.1.2) [error] SSL Library Error: 336105671 error:140890C7:lib(20):func(137):reason (199) The first time I also get the spurious SSL handshake interrupt message. Server config: Apache/2.0.43 (Unix) mod_ssl/2.0.43 OpenSSL/0.9.7 PHP/4.3.0 Kernel 2.4.8-26mdk
When configured for client certificate authentication, POST method fails after KeepAlive timeout - if KeepAlive is disabled, POST method always fails. SSLOptions +OptRenegotiate does not fix the problem. Server: Apache/2.0.45 (Unix) mod_ssl/2.0.45 OpenSSL/0.9.7a AIX 4.3.3 I have tested IE 5.5, Netscape 4.8, Netscape 7, and Mozilla 1.3 - All browsers seem to be affected. Log files can be found below. IE 5.5 generates a segfault of the child and a 302 error along with the general symptoms - details of this can be found in the logs below. -------------------------------------------------------------------------------------------------- Configuration excerpts: KeepAlive On KeepAliveTimeout 15 SSLSessionCache dbm:/var/adm/httpd.ssl.cache SSLSessionCacheTimeout 300 SSLMutex file:/var/adm/httpd.ssl.mutex <Directory /docs/clientcert> SSLOptions +StdEnvVars +ExportCertData +OptRenegotiate SSLVerifyClient require SSLVerifyDepth 2 SSLRequire %{SSL_CLIENT_CERT} eq file("<certfile>") \ or %{SSL_CLIENT_CERT} eq file("<certfile>") Order Deny,Allow Deny from all Allow from 1.1.1.1 </Directory> -------------------------------------------------------------------------------------------------- HTML files used for testing: $ cat index.html <HTML> <BODY> Hello client cert <FORM action=index2.html method=post> <INPUT value="Post to index2.html" type=submit> </FORM> </BODY> </HTML> $ cat index2.html <HTML> <BODY> Hello client cert - index2 <FORM action=index.html method=post> <INPUT value="Post to index.html" type=submit> </FORM> </BODY> </HTML> -------------------------------------------------------------------------------------------------- VH access log: 2.2.2.2 - - [07/Apr/2003:14:23:57 -0700] "GET /clientcert/index.html HTTP/1.1" 200 140 "-" "Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312" GET /clientcert/index.html - "HTTP/1.1" (-) 2.2.2.2 - - [07/Apr/2003:14:24:03 -0700] "POST /clientcert/index2.html HTTP/1.1" 200 144 "https://test.domain.com/clientcert/index.html" "Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312" POST /clientcert/index2.html - "HTTP/1.1" (-) 2.2.2.2 - - [07/Apr/2003:14:24:03 -0700] "POST /clientcert/index.html HTTP/1.1" 200 140 "https://test.domain.com/clientcert/index2.html" "Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312" POST /clientcert/index.html - "HTTP/1.1" (-) 2.2.2.2 - - [07/Apr/2003:14:24:04 -0700] "POST /clientcert/index2.html HTTP/1.1" 200 144 "https://test.domain.com/clientcert/index.html" "Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312" POST /clientcert/index2.html - "HTTP/1.1" (-) 2.2.2.2 - - [07/Apr/2003:14:24:05 -0700] "POST /clientcert/index.html HTTP/1.1" 200 140 "https://test.domain.com/clientcert/index2.html" "Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312" POST /clientcert/index.html - "HTTP/1.1" (-) 2.2.2.2 - - [07/Apr/2003:14:24:06 -0700] "POST /clientcert/index2.html HTTP/1.1" 200 144 "https://test.domain.com/clientcert/index.html" "Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312" POST /clientcert/index2.html - "HTTP/1.1" (-) 2.2.2.2 - - [07/Apr/2003:14:24:07 -0700] "POST /clientcert/index.html HTTP/1.1" 200 140 "https://test.domain.com/clientcert/index2.html" "Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312" POST /clientcert/index.html - "HTTP/1.1" (-) 2.2.2.2 - - [07/Apr/2003:14:25:12 -0700] "POST /clientcert/index2.html HTTP/1.1" 405 244 "https://test.domain.com/clientcert/index.html" "Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312" POST /clientcert/index2.html - "HTTP/1.1" (-) VH error log: [Mon Apr 07 14:25:12 2003] [error] SSL Re-negotiation in conjunction with POST method not supported! hint: try SSLOptions +OptRenegotiate -------------------------------------------------------------------------------------------------- With Internet Explorer 5.5: VH access log: 2.2.2.2 - - [07/Apr/2003:15:46:15 -0700] "GET /clientcert/ HTTP/1.1" 302 227 "-" "Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 5.0; T312461)" GET /clientcert/ - "HTTP/1.1" (-) 2.2.2.2 - - [07/Apr/2003:15:46:16 -0700] "GET /clientcert/ HTTP/1.1" 200 140 "-" "Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 5.0; T312461)" GET /clientcert/index.html - "HTTP/1.1" (-) 2.2.2.2 - - [07/Apr/2003:15:46:24 -0700] "POST /clientcert/index2.html HTTP/1.1" 200 144 "https://test.domain.com/clientcert/" "Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 5.0; T312461)" POST /clientcert/index2.html - "HTTP/1.1" (-) 2.2.2.2 - - [07/Apr/2003:15:46:25 -0700] "POST /clientcert/index.html HTTP/1.1" 200 140 "https://test.domain.com/clientcert/index2.html" "Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 5.0; T312461)" POST /clientcert/index.html - "HTTP/1.1" (-) 2.2.2.2 - - [07/Apr/2003:15:46:26 -0700] "POST /clientcert/index2.html HTTP/1.1" 200 144 "https://test.domain.com/clientcert/index.html" "Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 5.0; T312461)" POST /clientcert/index2.html - "HTTP/1.1" (-) 2.2.2.2 - - [07/Apr/2003:15:46:27 -0700] "POST /clientcert/index.html HTTP/1.1" 200 140 "https://test.domain.com/clientcert/index2.html" "Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 5.0; T312461)" POST /clientcert/index.html - "HTTP/1.1" (-) 2.2.2.2 - - [07/Apr/2003:15:46:28 -0700] "POST /clientcert/index2.html HTTP/1.1" 200 144 "https://test.domain.com/clientcert/index.html" "Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 5.0; T312461)" POST /clientcert/index2.html - "HTTP/1.1" (-) 2.2.2.2 - - [07/Apr/2003:15:46:29 -0700] "POST /clientcert/index.html HTTP/1.1" 200 140 "https://test.domain.com/clientcert/index2.html" "Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 5.0; T312461)" POST /clientcert/index.html - "HTTP/1.1" (-) 2.2.2.2 - - [07/Apr/2003:15:46:58 -0700] "POST /clientcert/index2.html HTTP/1.1" 405 244 "https://test.domain.com/clientcert/index.html" "Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 5.0; T312461)" POST /clientcert/index2.html - "HTTP/1.1" (-) VH error log: [Mon Apr 07 15:46:15 2003] [error] Re-negotiation handshake failed: Not accepted by client!? [Mon Apr 07 15:46:58 2003] [error] SSL Re-negotiation in conjunction with POST method not supported! hint: try SSLOptions +OptRenegotiate Server error log: [Mon Apr 07 15:46:16 2003] [notice] child pid 28262 exit signal Segmentation fault (11)
The existance of this "bug" is documented in modules/ssl/ssl_engine_kernel.c line 525. But it would really be nice to reimplement this feature.
Created attachment 9626 [details] diff against httpd-2.0.48
Fixed the problem in the following way: Before the renegotiation is starting the body of the POST request will be readed via ap_get_client_block().(So content-length, chunking etc. is handeld correctly.) The data will be stored in a brigade and an input filter will be added just after the http_header_filter. That input filter has the data from it's ctx. So in any subsequent read call that input filter will be invoked and can return the stored data. P.S. Im not sure if the upload of the diff is ok, so I paste it to be sure *** mod_ssl.h.patched Thu Dec 18 13:11:48 2003 --- mod_ssl.h Thu Dec 18 13:13:19 2003 *************** *** 709,714 **** --- 709,715 ---- void ssl_io_filter_init(conn_rec *, SSL *); void ssl_io_filter_register(apr_pool_t *); long ssl_io_data_cb(BIO *, int, MODSSL_BIO_CB_ARG_TYPE *, int, long, long); + long ssl_io_suck(request_rec *); /* PRNG */ int ssl_rand_seed(server_rec *, apr_pool_t *, ssl_rsctx_t, char *); *** ssl_engine_kernel.c.patched Thu Dec 18 13:11:39 2003 --- ssl_engine_kernel.c Thu Dec 18 13:15:04 2003 *************** *** 583,596 **** * * !! BUT ALL THIS IS STILL NOT RE-IMPLEMENTED FOR APACHE 2.0 !! */ ! if (renegotiate && !renegotiate_quick && (r->method_number == M_POST)) { ap_log_error(APLOG_MARK, APLOG_ERR, 0, r->server, "SSL Re-negotiation in conjunction " "with POST method not supported!\n" "hint: try SSLOptions +OptRenegotiate"); ! return HTTP_METHOD_NOT_ALLOWED; } /* * now do the renegotiation if anything was actually reconfigured --- 583,602 ---- * * !! BUT ALL THIS IS STILL NOT RE-IMPLEMENTED FOR APACHE 2.0 !! */ ! if (renegotiate && !renegotiate_quick && (r->method_number == M_POST)) { ! #ifdef SSL_CONSERVATIVE ap_log_error(APLOG_MARK, APLOG_ERR, 0, r->server, "SSL Re-negotiation in conjunction " "with POST method not supported!\n" "hint: try SSLOptions +OptRenegotiate"); ! return HTTP_METHOD_NOT_ALLOWED; + #else + if( ssl_io_suck(r) != OK) { + return HTTP_METHOD_NOT_ALLOWED; + } } + #endif /* SSL_CONSERVATIVE */ /* * now do the renegotiation if anything was actually reconfigured *** ssl_engine_io.c.patched Thu Dec 18 13:12:02 2003 --- ssl_engine_io.c Thu Dec 18 13:21:31 2003 *************** *** 897,902 **** --- 897,987 ---- } static const char ssl_io_filter[] = "SSL/TLS Filter"; + static const char ssl_buff_filter[] = "SSL/TLS Buffering Filter"; + /* + * reads the buffered data during a POST request with renegotiation + * will be registere at runtime. + * NOTE: we try to buffer the complete body. Use the attribute 'LimitRequestBody' + * preventing DOS attacks. + */ + long ssl_io_suck(request_rec *r) + { + apr_bucket *bucket; + apr_bucket_brigade *bb = apr_brigade_create(r->pool,r->connection->bucket_alloc); + + int readed = 0; + int len = 0; + int toRead= 0; + char *buffer = NULL; + char *pos = NULL; + + if(ap_setup_client_block(r,REQUEST_CHUNKED_DECHUNK) !=OK) { + return HTTP_METHOD_NOT_ALLOWED; + } + + if(!ap_should_client_block(r)) { + return OK; + } + + do { + buffer = apr_pcalloc(r->pool,HUGE_STRING_LEN); + toRead = HUGE_STRING_LEN; + + /* check malloc */ + if(buffer == NULL) { + ap_log_error(APLOG_MARK, APLOG_ERR, 0, r->server, + "SSL Re-negotiation in conjunction " + "with POST (buffering body failed)!\n"); + apr_brigade_destroy(bb); + return HTTP_METHOD_NOT_ALLOWED; + } + + /* fill the bucket */ + pos = buffer; + len = 0; + do { + readed = ap_get_client_block(r,pos,toRead); + + if(readed <=0) { + break; + } + + toRead -= readed; + + /* sanity */ + if(toRead<0) { + return HTTP_METHOD_NOT_ALLOWED; + } + + pos += readed; + len += readed; + } + while(toRead>0); + + /* check last read result */ + if(readed<0) { + ap_log_error(APLOG_MARK, APLOG_ERR, 0, r->server, + "SSL Re-negotiation in conjunction " + "with POST (reading body failed)!\n"); + apr_brigade_destroy(bb); + return HTTP_METHOD_NOT_ALLOWED; + } + + /* check if we have readed everything */ + if(len == 0) { + break; + } + bucket = apr_bucket_pool_create(buffer,len,r->pool,r->connection->bucket_alloc); + + APR_BRIGADE_INSERT_TAIL(bb, bucket); + } + while(1); + + //add the ssl_buff_filter_input + ap_add_input_filter(ssl_buff_filter, bb, r, r->connection); + + return OK; + } /* * Close the SSL part of the socket connection *************** *** 1361,1366 **** --- 1446,1529 ---- return status; } + static apr_status_t ssl_buff_filter_input(ap_filter_t *f, + apr_bucket_brigade *bb, + ap_input_mode_t mode, + apr_read_type_e block, + apr_off_t readbytes) + { + apr_bucket_brigade *aa = f->ctx; + apr_status_t rv; + + if(aa && !APR_BRIGADE_EMPTY(aa)) { + + if(mode == AP_MODE_READBYTES) { + apr_bucket *b; + apr_off_t missing = readbytes; + apr_size_t len; + const char *tmp; + + while (!APR_BRIGADE_EMPTY(aa)) { + b = APR_BRIGADE_FIRST(aa); + + rv = apr_bucket_read(b, &tmp, &len, APR_BLOCK_READ); + if (rv != APR_SUCCESS) { + return rv; + } + + /* consume whole bucket */ + if(missing >= len) { + APR_BUCKET_REMOVE(b); + APR_BRIGADE_INSERT_TAIL(bb,b); + } + /* comsume only a part */ + else{ + rv = apr_bucket_split(b, missing); + if (rv != APR_SUCCESS) { + return rv; + } + + APR_BUCKET_REMOVE(b); + APR_BRIGADE_INSERT_TAIL(bb, b); + break; + } + + missing -= len; + + if (missing = 0) { + break; + } + + if(missing<0) { + return AP_FILTER_ERROR; + } + } + return APR_SUCCESS; + } + else if (mode == AP_MODE_READBYTES) { + apr_bucket_brigade *nb = apr_brigade_create(f->r->pool,f->c->bucket_alloc); + + /* split */ + rv = apr_brigade_split_line(nb,aa,block,readbytes); + if( rv != APR_SUCCESS) { + return rv; + } + + /* concatinate */ + APR_BRIGADE_CONCAT(bb,aa); + + /* remember the rest */ + f->ctx = nb; + + return APR_SUCCESS; + } + + } + + + return ap_pass_brigade(f->next, bb); + } + static void ssl_io_input_add_filter(ssl_filter_ctx_t *filter_ctx, conn_rec *c, SSL *ssl) { *************** *** 1417,1422 **** --- 1580,1586 ---- { ap_register_input_filter (ssl_io_filter, ssl_io_filter_input, NULL, AP_FTYPE_CONNECTION + 5); ap_register_output_filter (ssl_io_filter, ssl_io_filter_output, NULL, AP_FTYPE_CONNECTION + 5); + ap_register_input_filter (ssl_buff_filter, ssl_buff_filter_input, NULL, AP_FTYPE_PROTOCOL - 1); return; }
Just adding the PatchAvailable keyword. Hartmut, to keep bugs in the loop please don't resolve them as fixed until they're reviewed and/or committed at least to one dev-tree. Anyway, thanks for the patch.
Also, this configuration does not activate the bug : SSLEngine on SSLVerifyClient optional SSLOptions +OptRenegotiate <location /location/ > SSLVerifyClient optional SSLVerifyDepth 10 </location>
I was having a similar problem with per-directory SSL authentication with DAV. (Note that the patch posted earlier does not fix the problem for DAV.) I have worked around the problem by having a global "SSLVerifyClient optional" directive. The per-directory "SSLVerifyClient required" is then processed properly. This seems to preserve all of the behavior that I need. Those without a certificate can still access the site via SSL, and the entire site, including the portions using SSL authentication, work for those with proper certificates. This may need no more than clarification in the documentation.
I have attempted usage of all posts in this bug to date. I have used the patch, no dice. I have altered my configurations as noted by the posts mentioning that the bug will not be enabled with a configuration change, again no dice. I have also used several configurations noted in errors by the apache software and nothing works. I always get "SSL Re-negotiation in conjunction with POST method not supported!" when the SSL is renegotiated and the next method is a POST instead of a GET. I find it hard to swallow ("because I am a huge fan of Apache and mod_ssl"), that Apache organization would make such a glaring flaw in the 2.0 builds considering all this worked great in the 1.3 builds. My final resolution because I am in a production environment (until Apache org. fixes the problem). Go back to the 1.3 build ASAP.
Hello, I also applied all "remedies" so far mentioned by others (including patching), to no avail, the problem is still alive and healthy. As a consequence, we are considering going back to 1.3 as well. I'm reluctant to go in this direction, but without progress for months now, there seems to be no perspective for 2.0 within environments requiring client certs and the POST method.... BTW: You should remove the "PatchAvailable" keyword. No offense for the creator of the patch, but it simply doesn't work. Regards, Birger
*** Bug 21167 has been marked as a duplicate of this bug. ***
Created attachment 11681 [details] patch for 2.0 to fix #12355
*Experimental* patch attached above for 2.0, this is closer to fixing the issue properly, without buffering the entire request body in memory. (it makes one bogus assumption about the filter interfaces but seems to work OK) This approach also needs careful checking bugs may allow clients to bypass the access control checks.
Created attachment 11736 [details] proposed fix
Second patch attached is the fix I have proposed for this issue, which has no issues that I'm currently aware of, and could do with some wider testing.
*** Bug 18395 has been marked as a duplicate of this bug. ***
Created attachment 11745 [details] proposed fix for 2.0 branch
Proposed patch, rediffed for 2.0, attached above.
Hi, when patching the apache2-2.0.48 source RPM for Mandrake 10 (and rebuilding the binaries), the SSL service crashes immediately upon the use of client certificates: [Sat Jun 05 12:30:50 2004] [notice] LDAP: Built with OpenLDAP LDAP SDK [Sat Jun 05 12:30:50 2004] [notice] Digest: generating secret for digest authentication ... [Sat Jun 05 12:30:50 2004] [notice] Digest: done [Sat Jun 05 12:30:51 2004] [notice] Apache-AdvancedExtranetServer/2.0.48 (Mandrake Linux/6.2.100mdk) mod_ssl/2.0.48 OpenSSL/0.9.7a DAV/2 PHP/4.3.1 configured -- resuming normal operations - service is now working and delivers ordinary pages successfully, including PHP and MySQL_over_PHP operations and SSL (without client certs) - [Sat Jun 05 12:32:21 2004] [notice] child pid 29488 exit signal Segmentation fault (11) - that was the child that dealt the first time with a client certificate - Without the patch (but same source) and without using POST, the site works "perfectly" using client certificates. Birger
*** Bug 29569 has been marked as a duplicate of this bug. ***
Please don't mark bugs as fixed without adding a comment, and please don't mark bugs as fixed if they aren't really fixed!
Have there been any updates on this issue since the last comment filed on July 8th of this year?
No; I'm not really convinced the solution I was working on can be made to be secure. Note that for many configurations, there is a simple workaround: add SSLVerifyClient optional to the SSL vhost config, as well as the "SSLVerifyClient require" in whatever Location/Directory context.
I was reminded privately that the other workaround for this bug is of course to ensure that the first access the browser makes to the SSLVerifyClient-protected location uses a GET request rather than a POST request.
*** Bug 31314 has been marked as a duplicate of this bug. ***
Some general comments; HTTP/1.0 the 'classic' HTTP/1.0 handling -must- buffer the body if the connection will be renegotiated. This should no longer be handled inside the mod_ssl module itself, by itself. With the advent of filters, either apreq2 or another 'client buffer' module must be implemented. The logic looks like; brigade read loop mem_body > max_memory_body ? create tmpfile if tmpfile isnull response 'failure' if total_body > max_buffer_body write body -> tmpfile reopen tmpfile read-only insert tmpfile bucket of tmpfile prior to remaining mem_body buckets. now we have two controls that would prevent DoS attacks present in the original fix proposed (unbounded growth of the body.) Remember, the renegotiation would NOT determine the client certificate is valid until after these resources had been consumed by a nefarious client. I rather like the idea of apreq2 doing this work, and actually, integrating apreq2 as a 'stock' apache module. apreq2 does nothing until some module in the server configuration wants to use its services. HTTP/1.1 + client Expect: 100-continue http://rfc.net/rfc2616.html#s8.2.3 Clients which truly pause for 100-continue could be satisfied with no buffering of the body. Schedule the renegotation prior to sending the 100 CONTINUE response. Finally note that this is not specific to POST, it's generic to all HTTP methods which contain a client body. The headers may be inspected to determine if the client is attempting to push a body with the request.
Isn't there any way to suppress renegotiation ?
Workaround!!! Following configuration works fine (optional for any except with CA certificate, and required to an especific location): SSLEngine on SSLVerifyClient optional_no_ca SSLVerifyDepth 2 SSLOptions +OptRenegotiate <location /any_location/ > SSLVerifyClient require </location> Regards, Bruno Santiago
"SSLVerifyClient optional" seems also safe. Is "SSLOptions +OptRenegotiate" really needed, or is it an optimisation ? Is it totally safe ? The doc states to use this carefully.
(In reply to comment #34) > "SSLVerifyClient optional" seems also safe. > Is "SSLOptions +OptRenegotiate" really needed, or is it an optimisation ? > Is it totally safe ? The doc states to use this carefully. The workaround explained above is not safe at least for apache 2.0.52. " RE: [users@httpd] Bug or Feature : global SSLVerifyClient in <VirtualHost> overrides the same in <Location>? Simple test scenario is : 1. access document root location - "SSLVerifyClient optional" , cancel certificate choice window. 2. access location <Location "/auth"> with "SSLVerifyClient require" - no triggered SSL negotiation - access without certificate granted. Correct should be the following behaviour, but there is no re-negotiation: >SSLVerifyClient is documented as working in directory context, so it should also work in <Location> context. The manual page for mod_ssl does >explicitly say that a SSL renegotiation is triggered if a request for the location is received. config sample: <VirtualHost> SSLVerifyClient optional Alias /auth /htdocs/access <Location "/access"> SSLVerifyClient require SSLOptions +ExportCertData +StdEnvVars +OptRenegotiate SSLVerifyDepth 5 Options None </Location> </VirtualHost> "
Proposed workaround is to add an additional <VirtualHost> and configure in its context SSLVerifyClient require. In my particular case creating webapi virtualhost suppose to fix problems with axis.
The problem mentioned in comment 35 is a separate issue from the bug covered here, and is fixed by: http://svn.apache.org/viewcvs?rev=264800&view=rev
I was told to use something like this: <VirtualHost ...> ... SSLVerifyClient none ... <Location /plop> ... SSLVerifyClient require ... </Location> </VirtualHost> And this seems to work fine. Can someone confirm this is working correctly and I'm not missing some "feature" for this bug ? Thanks
If the bug isn't fixed, the issue is that the Location-specific renegotiation fails on a POST. If you're testing with GET, that's not a useful test.
Created attachment 16491 [details] backport of patch from trunk This is a backport of the patch from the trunk which was committed to fix this issue. Any results from testing are welcome.
Created attachment 16495 [details] patch for 2.0.54 This patch can be applied to 2.0.54.
Now fixed for 2.1.8-beta and later. http://svn.apache.org/viewcvs?rev=290965&view=rev Given sufficient testing of the patch from comment 41, this could get a backport to 2.0.x.
(In reply to comment #41) > This patch can be applied to 2.0.54. The patch can be applied to 2.0.55 aswell, and it allows using the following setup: SSLVerifyClient optional <Location /subversion> DAV svn SVNParentPath /path/to/reps AuthzSVNAccessFile /path/to/accessfile SSLVerifyClient require SSLUserName SSL_CLIENT_S_DN_CN SSLOptions +StrictRequire </Location> I used Subversion 1.2.3 clients on Linux and Windows for successful testing. It is important to note that with the above configuration, access to the Subversion repository requires a client certificate, while other areas of the server can be accessed without certificates (i.e. webmail via HTTPS). Judging from my tests, this desired behaviour can not be achieved based on vanilla 2.0.55 sources, so I strongly welcome Joe's patch and hope it will be included as a 2.0.x backport in the future.
(In reply to comment #43) > (In reply to comment #41) > > > This patch can be applied to 2.0.54. > > The patch can be applied to 2.0.55 aswell, and it allows using the > following setup: > > SSLVerifyClient optional > <Location /subversion> > DAV svn > SVNParentPath /path/to/reps > AuthzSVNAccessFile /path/to/accessfile > SSLVerifyClient require > SSLUserName SSL_CLIENT_S_DN_CN > SSLOptions +StrictRequire > </Location> > > I used Subversion 1.2.3 clients on Linux and Windows for successful > testing. > > It is important to note that with the above configuration, access to > the Subversion repository requires a client certificate, while other > areas of the server can be accessed without certificates (i.e. webmail > via HTTPS). Judging from my tests, this desired behaviour can not be > achieved based on vanilla 2.0.55 sources, so I strongly welcome Joe's > patch and hope it will be included as a 2.0.x backport in the future. The problem is still not fixed. Was tested for apache 2.0.55 : there is still post method not allowed message described by you and other guys in this topic. After patching apache it still doesn`t work, only the message is different. We tried with apache_2.0.55 with unofficial patch from bugzilla (No.:12355) and got the following messages in logfiles. access_log: 85.115.6.202 - - [17/Mar/2006:13:13:50 +0000] "POST /webservice/services/SessionManagement HTTP/1.0" 403 - "-" "-" error_log with debug level in http.conf: [Fri Mar 17 13:32:54 2006] [debug] ssl_engine_kernel.c(1738): OpenSSL: Handshake: start [Fri Mar 17 13:32:54 2006] [debug] ssl_engine_kernel.c(1746): OpenSSL: Loop: SSL renegotiate ciphers [Fri Mar 17 13:32:54 2006] [debug] ssl_engine_kernel.c(1746): OpenSSL: Loop: SSLv3 write hello request A [Fri Mar 17 13:32:54 2006] [debug] ssl_engine_kernel.c(1746): OpenSSL: Loop: SSLv3 flush data [Fri Mar 17 13:32:54 2006] [debug] ssl_engine_kernel.c(1746): OpenSSL: Loop: SSLv3 write hello request C [Fri Mar 17 13:32:54 2006] [info] Awaiting re-negotiation handshake [Fri Mar 17 13:32:54 2006] [debug] ssl_engine_kernel.c(1738): OpenSSL: Handshake: start [Fri Mar 17 13:32:54 2006] [debug] ssl_engine_kernel.c(1746): OpenSSL: Loop: before accept initializati on [Fri Mar 17 13:32:54 2006] [debug] ssl_engine_io.c(1697): OpenSSL: read 0/5 bytes from BIO#83a24b8 [mem : 842d708] (BIO dump follows) [Fri Mar 17 13:32:54 2006] [debug] ssl_engine_io.c(1644): +-------------------------------------------- -----------------------------+ [Fri Mar 17 13:32:54 2006] [debug] ssl_engine_io.c(1675): +-------------------------------------------- -----------------------------+ [Fri Mar 17 13:32:54 2006] [debug] ssl_engine_kernel.c(1770): OpenSSL: Exit: failed in SSLv3 read clien t hello B [Fri Mar 17 13:32:54 2006] [error] Re-negotiation handshake failed: Not accepted by client!? [Fri Mar 17 13:32:54 2006] [debug] ssl_engine_io.c(1488): [client 85.115.6.202] read from buffered SSL brigade, mode 0, 8192 bytes [Fri Mar 17 13:32:54 2006] [debug] ssl_engine_io.c(1550): [client 85.115.6.202] buffered SSL brigade no w exhausted; removing filter [Fri Mar 17 13:33:07 2006] [debug] ssl_engine_io.c(1708): OpenSSL: I/O error, 5 bytes expected to read on BIO#83a24b8 [mem: 842d708] [Fri Mar 17 13:33:07 2006] [info] (70007)The timeout specified has expired: SSL input filter read faile d. [Fri Mar 17 13:33:07 2006] [debug] ssl_engine_kernel.c(1756): OpenSSL: Write: SSL negotiation finished successfully [Fri Mar 17 13:33:07 2006] [info] Connection to child 2 closed with standard shutdown(server drecord.de .something.com:443, client 85.115.6.202) -------------------------------------------------------------------------------- P.S. We have additional virtualhost configured that is responsible for certificate authentication and session management with axis, there it works perfectly. So the problem occures only for <location> that doesn`t have a globaly set <SSLVerifyClient> to optional or required P.P.S. <SSLVerifyClient> optional in a global context fix the problem , but this solution is not acceptable because it enforce the browser to show the popup with installed certificates.(sure it is a browser issue and probably could be configured on the client side, but this is not the way it should work in productive env.) Regards, Yefym
If you have any problems using this patch, please upgrade to 2.2.0 instead, and file bugs giving the error_log output from 2.2.0.
*** Bug 39154 has been marked as a duplicate of this bug. ***
*** Bug 39243 has been marked as a duplicate of this bug. ***
*** Bug 39705 has been marked as a duplicate of this bug. ***
I couldn't understand why this bug is not fix by Apache team since the release of Apache2. I really need this features to be enabled as what we have in mod_ssl for version for apache1.3.x.
It is fixed in 2.2.x, but has not been backported to 2.0.x yet. There is a patch against 2.0.54 attached to this report for those who need to fix this immediately for 2.0.x.
First this IS fixed in 2.2.0. Backports aren't discussed on Bugzilla, this issue has been raised in our 2.0.x STATUS file. And given a more accurate name.
this bug is always present with Apache/2.2.4. You can't mixed SSLVerifyClient optinal and SSLVerifyClient requierd part To allow some Location for non SSL valid Client. NOT WORKING ======== ------------------------ SSLVerifyClient optional SSLVerifyDepth 1 SSLOptions +OptRenegotiate <Location /Album> SSLRequireSSL SSLVerifyClient require SSLCACertificateFile conf/ssl.crt/Root_Certificat.crt SSLCACertificatePath conf/ssl.crt SSLRequire (%{SSL_CLIENT_S_DN_OU} eq "Portable" || %{SSL_CLIENT_S_DN_OU} eq "Personnal") SSLVerifyDepth 3 #FIX ANOTHER BUG SetEnv REMOTE_USER ${SSL_CLIENT_S_DN_CN} SSLUserName SSL_CLIENT_S_DN_CN </location> WORKING == ---------
Sorry ... I forgot to say .. that the bug is only with php. CGI perl work fine ..
It's working fine when the certificat private key is <= 512. 2048b not working 1024b not working. But I don't understand why If it's can help coders.
(In reply to comment #54 and previous ones) > It's working fine when the certificat private key is <= 512. > 2048b not working > 1024b not working. > But I don't understand why > > If it's can help coders. > This looks like an unrelated problem, could you open a new issue for it? Thanks.
(In reply to comment #52) > this bug is always present with Apache/2.2.4. > > You can't mixed SSLVerifyClient optinal and SSLVerifyClient requierd part > To allow some Location for non SSL valid Client. > This was fixed in Apache 2.0.55, changelog: *) SECURITY: CVE-2005-2700 (cve.mitre.org) mod_ssl: Fix a security issue where "SSLVerifyClient" was not enforced in per-location context if "SSLVerifyClient optional" was configured in the vhost configuration. [Joe Orton]
*** Bug 42625 has been marked as a duplicate of this bug. ***
Backported to 2.0.x as r536373 (http://svn.apache.org/viewvc?view=rev&revision=536373)