EnableOptions and SSL configuration ----------------------------------- Key: MODCLUSTER-401 URL: https://issues.jboss.org/browse/MODCLUSTER-401 Project: mod_cluster Issue Type: Bug Affects Versions: 1.2.8.Final Reporter: Michal Babacek Assignee: Jean-Frederic Clere As a follow up on MODCLUSTER-400 and a documentation effort for *EnableOptions* logic, I tried to add {{EnableOptions}} to the configuration so as to allow for a "cping/cpong" emulation of the famous AJP feature. With the following {{mod_cluster.conf / httpd.conf}} (standalone-ha.xml being the same as in MODCLUSTER-400's description): {code} +++ Listen 10.16.92.191:2081 +++ MemManagerFile "/hell/workspace/hpws22/apache/cache/mod_cluster" ServerName 10.16.92.191:2081 <IfModule manager_module> Listen 10.16.92.191:8745 LogLevel debug <VirtualHost 10.16.92.191:8745> ServerName 10.16.92.191:8745 <Directory /> Order deny,allow Deny from all Allow from all </Directory> KeepAliveTimeout 60 MaxKeepAliveRequests 0 ServerAdvertise on AdvertiseFrequency 5 ManagerBalancerName qacluster AdvertiseGroup 224.0.3.47:23364 EnableOptions EnableMCPMReceive SSLEngine on SSLProtocol all -SSLv2 -SSLv3 SSLCipherSuite "EECDH+ECDSA+AESGCM EECDH+aRSA+AESGCM EECDH+ECDSA+SHA384 EECDH+ECDSA+SHA256 EECDH+aRSA+SHA384 EECDH+aRSA+SHA256 EECDH+aRSA+RC4 EECDH EDH+aRSA RC4 !aNULL !eNULL !LOW !3DES !MD5 !EXP !PSK !SRP !DSS" SSLHonorCipherOrder on SSLCertificateFile /vault/server.crt SSLCertificateKeyFile /vault/server.key SSLCACertificateFile /vault/myca.crt SSLProxyEngine On SSLVerifyDepth 10 <Location /mcm> SetHandler mod_cluster-manager Order deny,allow Deny from all Allow from all </Location> </VirtualHost> </IfModule> {code} one gets this [^hp-ux_error_log-EnableOptions.zip] log: {code} [debug] mod_proxy_cluster.c(1223): http_cping_cpong: received HTTP/1.1 200 OK [debug] mod_proxy_cluster.c(1223): http_cping_cpong: received Server: Apache-Coyote/1.1 [debug] mod_proxy_cluster.c(1223): http_cping_cpong: received Allow: GET, HEAD, POST, PUT, DELETE, TRACE, OPTIONS [debug] mod_proxy_cluster.c(1223): http_cping_cpong: received Content-Length: 0 [debug] mod_proxy_cluster.c(1223): http_cping_cpong: received Date: Fri, 02 May 2014 17:22:46 GMT [debug] mod_proxy_cluster.c(1223): http_cping_cpong: received Connection: close [debug] mod_proxy_cluster.c(1239): http_cping_cpong: Done [debug] proxy_util.c(2047): proxy: https: has released connection for (10.16.92.191) [debug] mod_manager.c(2666): manager_handler STATUS OK [debug] proxy_util.c(2029): proxy: https: has acquired connection for (10.16.92.191) [debug] proxy_util.c(2085): proxy: connecting https://10.16.92.191:8645/ to 10.16.92.191:8645 [debug] proxy_util.c(2211): proxy: connected / to 10.16.92.191:8645 [debug] proxy_util.c(2462): proxy: https: fam 2 socket created to connect to 10.16.92.191 [debug] mod_proxy_cluster.c(1384): proxy_cluster_try_pingpong: connected to backend [error] [client 10.16.92.191] SSL Proxy requested for 10.16.92.191:2081 but not enabled [Hint: SSLProxyEngine] [error] proxy: https: failed to enable ssl support for 10.16.92.191:8645 (10.16.92.191) [debug] proxy_util.c(2047): proxy: https: has released connection for (10.16.92.191) {code} Why is the JBoss EAP residing on {{10.16.92.191:8645}} trying to request SSL Proxy on the virtual host {{10.16.92.191:2081}}? The result is {{Status: NOTOK}} on mod_cluser manager console. I tried to remove that {{10.16.92.191:2081}}, so as the {{10.16.92.191:8745}} is the only one ([^hp-ux_error_log-EnableOptions-single-vhost.zip]): {code} - Listen 10.16.92.191:2081 - ServerName 10.16.92.191:2081 {code} The result is a funny trial to request a proxy for the boxe's actual hostname and port 80 *no one* (netstat) is even listening on: {code} [debug] mod_proxy_cluster.c(1223): http_cping_cpong: received HTTP/1.1 200 OK [debug] mod_proxy_cluster.c(1223): http_cping_cpong: received Server: Apache-Coyote/1.1 [debug] mod_proxy_cluster.c(1223): http_cping_cpong: received Allow: GET, HEAD, POST, PUT, DELETE, TRACE, OPTIONS [debug] mod_proxy_cluster.c(1223): http_cping_cpong: received Content-Length: 0 [debug] mod_proxy_cluster.c(1223): http_cping_cpong: received Date: Fri, 02 May 2014 17:39:33 GMT [debug] mod_proxy_cluster.c(1223): http_cping_cpong: received Connection: close [debug] mod_proxy_cluster.c(1239): http_cping_cpong: Done [debug] proxy_util.c(2047): proxy: https: has released connection for (10.16.92.191) [debug] mod_manager.c(2666): manager_handler STATUS OK [debug] proxy_util.c(2029): proxy: https: has acquired connection for (10.16.92.191) [debug] proxy_util.c(2085): proxy: connecting https://10.16.92.191:8645/ to 10.16.92.191:8645 [debug] proxy_util.c(2211): proxy: connected / to 10.16.92.191:8645 [debug] proxy_util.c(2462): proxy: https: fam 2 socket created to connect to 10.16.92.191 [debug] mod_proxy_cluster.c(1384): proxy_cluster_try_pingpong: connected to backend [error] [client 10.16.92.191] SSL Proxy requested for eap-perf-hpux-03.mw.lab.eng.bos.redhat.com:80 but not enabled [Hint: SSLProxyEngine] [error] proxy: https: failed to enable ssl support for 10.16.92.191:8645 (10.16.92.191) [debug] proxy_util.c(2047): proxy: https: has released connection for (10.16.92.191) {code} I tried to add: {{RequestHeader set Front-End-Https "On"}} to the configuration without any luck. Finally, I replicated the SSL configuration *outside* the VirtualHost: {code} MemManagerFile "/hell/workspace/hpws22/apache/cache/mod_cluster" Listen 10.16.92.191:2081 ServerName 10.16.92.191:2081 SSLEngine on SSLProtocol all -SSLv2 -SSLv3 SSLCipherSuite "EECDH+ECDSA+AESGCM EECDH+aRSA+AESGCM EECDH+ECDSA+SHA384 EECDH+ECDSA+SHA256 EECDH+aRSA+SHA384 EECDH+aRSA+SHA256 EECDH+aRSA+RC4 EECDH EDH+aRSA RC4 !aNULL !eNULL !LOW !3DES !MD5 !EXP !PSK !S RP !DSS" SSLHonorCipherOrder on SSLCertificateFile /vault/server.crt SSLCertificateKeyFile /vault/server.key SSLCACertificateFile /vault/myca.crt SSLProxyEngine On SSLVerifyDepth 10 <IfModule manager_module> +++ the same as above +++ </IfModule> {code} This configuration fixed the aforementioned {{failed to enable ssl support}} *and* actually helped to workaround the MODCLUSTER-400: (log: [^hp-ux_error_log-EnableOptions-SSL_everywhere.zip]) {code} Fri, May 2, 2014 02:23:44 PM Request URI: /clusterbench/requestinfo Headers: {host=10.16.92.191:8645, user-agent=curl/7.30.0, accept=*/*, cookie=JSESSIONID=2hC9ax9LGYDvQZtH0RXdBimf.jboss-eap-6.3-2, x-forwarded-for=10.16.92.191, x-forwarded-host=10.16.92.191:8745, x-forwarded-server=10.16.92.191, connection=Keep-Alive} Host header: 10.16.92.191:8645 Character encoding: null JVM route: jboss-eap-6.3-2 Session ID: 2hC9ax9LGYDvQZtH0RXdBimf.jboss-eap-6.3-2 Session isNew: false Fri, May 2, 2014 02:23:47 PM Request URI: /clusterbench/requestinfo Headers: {host=10.16.92.191:8645, user-agent=curl/7.30.0, accept=*/*, cookie=JSESSIONID=2hC9ax9LGYDvQZtH0RXdBimf.jboss-eap-6.3-2, x-forwarded-for=10.16.92.191, x-forwarded-host=10.16.92.191:8745, x-forwarded-server=10.16.92.191, connection=Keep-Alive} Host header: 10.16.92.191:8645 Character encoding: null JVM route: jboss-eap-6.3-2 Session ID: 2hC9ax9LGYDvQZtH0RXdBimf.jboss-eap-6.3-2 Session isNew: false -- stop jboss-eap-6.3-2 -- (the same behavior with jvm kill) -- Fri, May 2, 2014 02:23:50 PM Request URI: /clusterbench/requestinfo Headers: {host=10.16.92.191:8544, user-agent=curl/7.30.0, accept=*/*, cookie=JSESSIONID=2hC9ax9LGYDvQZtH0RXdBimf.jboss-eap-6.3-2, x-forwarded-for=10.16.92.191, x-forwarded-host=10.16.92.191:8745, x-forwarded-server=10.16.92.191, connection=Keep-Alive} Host header: 10.16.92.191:8544 Character encoding: null JVM route: jboss-eap-6.3 Session ID: 2hC9ax9LGYDvQZtH0RXdBimf.jboss-eap-6.3 Session isNew: false Fri, May 2, 2014 02:23:53 PM Request URI: /clusterbench/requestinfo Headers: {host=10.16.92.191:8544, user-agent=curl/7.30.0, accept=*/*, cookie=JSESSIONID=2hC9ax9LGYDvQZtH0RXdBimf.jboss-eap-6.3, x-forwarded-for=10.16.92.191, x-forwarded-host=10.16.92.191:8745, x-forwarded-server=10.16.92.191, connection=Keep-Alive} Host header: 10.16.92.191:8544 Character encoding: null JVM route: jboss-eap-6.3 Session ID: 2hC9ax9LGYDvQZtH0RXdBimf.jboss-eap-6.3 Session isNew: false Fri, May 2, 2014 02:23:56 PM Request URI: /clusterbench/requestinfo Headers: {host=10.16.92.191:8544, user-agent=curl/7.30.0, accept=*/*, cookie=JSESSIONID=2hC9ax9LGYDvQZtH0RXdBimf.jboss-eap-6.3, x-forwarded-for=10.16.92.191, x-forwarded-host=10.16.92.191:8745, x-forwarded-server=10.16.92.191, connection=Keep-Alive} Host header: 10.16.92.191:8544 Character encoding: null JVM route: jboss-eap-6.3 Session ID: 2hC9ax9LGYDvQZtH0RXdBimf.jboss-eap-6.3 Session isNew: false {code} Why isn't the {{10.16.92.191:8745}} enough? Is it a configuration error or a ProxyPass/SSL integration bug?