Hi Zisis, Finally able to introduce “SLProxyCheckPeerCN off” in Apache conf file and now “Proxy error” issue has been resolved. Link to Tomcat webserver is now redirecting properly, BUT with some breakage. After a while we got “Connection got reset” error on UI. Again checked error log and found following new messages:
------------------- [Tue Nov 20 22:18:52.356772 2012] [core:notice] [pid 2511] AH00052: child pid 2544 exit signal Segmentation fault (11) [Tue Nov 20 22:18:53.363481 2012] [core:notice] [pid 2511] AH00052: child pid 2526 exit signal Segmentation fault (11) ------------------- Can you help in understanding the probable cause of this exception? Thanks, Pravesh -----Original Message----- From: Zisis Lianas [mailto:zisis.lia...@consol.de] Sent: Tuesday, November 20, 2012 5:33 PM To: dev@httpd.apache.org Subject: Re: Apache 2.4.3 issue related to SLProxyCheckPeerCN directive Hi Pravesh, this is the expected behaviour of SSLProxyCheckPeerCN. When set to "on" (default), the certificate CN of the backend server has to match the configured BalancerMember's name. In your case, your BalancerMember seems to be "https://15.146.153.101/"; (so the name is "15.146.153.101"), which has configured an SSL certificate with "CN=y". This constellation can't work. Normally "SSLProxyCheckPeerCN off" should solve your issue - what do you mean with 'is not helping much in our case'? What is the error message when turning SSLProxyCheckPeerCN off? Perhaps you can also post the relevant part of your configuration. The links you posted are not really applicable for this configuration issue. Please also consider that this is more an users-issue than dev (-> users mailinglist). Regards, Zisis ----- Original Message ----- > From: "Pravesh R Rai (STSD)" <pravesh....@hp.com> > To: dev@httpd.apache.org > Sent: Tuesday, November 20, 2012 12:17:13 PM > Subject: Apache 2.4.3 issue related to SLProxyCheckPeerCN directive > > Hi All, > > While trying to use Apache 2.4.3, we are getting following error > messages (in error_log), when trying to access a link to another > application running on Tomcat web server: > > ------------------ > [ssl:info] [pid 3264] [remote 127.0.0.1:1188] AH02005: SSL Proxy: > Peer certificate CN mismatch: Certificate CN: y Requested hostname: > 15.146.153.101 > [ssl:info] [pid 3264] [remote 127.0.0.1:1188] AH01998: Connection > closed to child 0 with abortive shutdown (server localhost:2381) > [proxy_http:error] [pid 3264] (502)Unknown error 502: [client > 16.154.173.74:52712] AH01084: pass request body failed to > 127.0.0.1:1188 (localhost), referer: > https://15.146.153.101:2381/chplinkstrt.php?chppath=Tools%3A%3AService > guard&chppage=Serviceguard%20Manager&chpurl=/sgmgr/main/main.do&chptar > get=undefined [proxy:error] [pid 3264] [client 16.154.173.74:52712] > AH00898: Error during SSL Handshake with remote server returned by > /sgmgr/main/main.do, referer: > https://15.146.153.101:2381/chplinkstrt.php?chppath=Tools%3A%3AService > guard&chppage=Serviceguard%20Manager&chpurl=/sgmgr/main/main.do&chptar > get=undefined [proxy_http:error] [pid 3264] [client > 16.154.173.74:52712] AH01097: > pass request body failed to 127.0.0.1:1188 (localhost) from > 16.154.173.74 (), referer: https://15.146.153.101:2381/chpl > ------------------ > > Also found that, the same bug is reported at some Apache & Bugzilla > sites: > > https://issues.apache.org/bugzilla/show_bug.cgi?id=53006 > http://mail-archives.apache.org/mod_mbox/httpd-bugs/201203.mbox/%3Cbug > -53006-7...@https.issues.apache.org/bugzilla/%3E > http://osdir.com/ml/bugs-httpd/2012-03/msg00324.html > > but none of those points to the right direction. After going through > Apache-2.4.3 docs/forum: > > http://apache-http-server.18135.n6.nabble.com/SSLProxyCheckPeerCN-Prox > yPreserveHost-issue-td4999947.html > http://httpd.apache.org/docs/2.4/upgrading.html#misc > http://httpd.apache.org/docs/trunk/mod/mod_ssl.html > > found that, it is observed only with Apache-2.4.3 & is due to one > directive "SLProxyCheckPeerCN", which is now "on" by default. But even > setting this to "off" is not helping much in our case. > > Can anybody please provide some clue about this behavior? > > Regards, > Pravesh >
