[JBoss JIRA] (WFLY-3106) Infinispan cache statistics cannot be enabled/disabled independently of the cache manager statistics
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/WFLY-3106?page=com.atlassian.jira.plugin.... ]
Radoslav Husar commented on WFLY-3106:
--------------------------------------
Thanks!
> Infinispan cache statistics cannot be enabled/disabled independently of the cache manager statistics
> --------------------------------------------------------------------------------------------------------
>
> Key: WFLY-3106
> URL: https://issues.jboss.org/browse/WFLY-3106
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Clustering
> Affects Versions: 8.0.0.Final
> Reporter: Richard Achmatowicz
> Assignee: Richard Achmatowicz
> Fix For: 8.0.1.Final
>
>
> The Infinispan subsystem allows enabling and disabling the collection of statistics for cache managers and caches via the "statistics-enabled" management API attribute.
> It is possible to set statistics-enabled attributes independently for cache managers and caches in the management API, but when checking the Infinispan MBeans, we see that statistics are either enabled for cache managers and their caches, or disabled for cache managers and caches.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 10 months
[JBoss JIRA] (DROOLS-372) InstantiationError during condition evaluation in Drools 6.0.0.Final
by Robert Spielmann (JIRA)
[ https://issues.jboss.org/browse/DROOLS-372?page=com.atlassian.jira.plugin... ]
Robert Spielmann commented on DROOLS-372:
-----------------------------------------
I'm facing the same problem with Drools 5.5.0.Final since we upgraded from 5.2.0.Final yesterday. Is there a way to fix this without upgrading further?
> InstantiationError during condition evaluation in Drools 6.0.0.Final
> --------------------------------------------------------------------
>
> Key: DROOLS-372
> URL: https://issues.jboss.org/browse/DROOLS-372
> Project: Drools
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 6.0.0.Final
> Environment: reproduced on both jdk 6 and jdk 7
> Reporter: Loic Albertin
> Assignee: Mario Fusco
> Fix For: 6.0.1.Final
>
> Attachments: drools-issue.zip
>
>
> Kindly find bellow the initial discussion from rules-user(a)list.jboss.org
> In addition I attach a sample project that reproduce the error.
> To run it simply type 'mvn clean install exec:java'.
> An interesting thing is that on my environment the issue always appears at the 21st insertion.
> {quote}
> Hi all,
> I'm migrating from an old Drools 5.1 version to 6.0.0.Final. Sometimes (I don't really get under which conditions as sometimes it works), I'm facing an InstantiationError exception when I insert a fact into a stateful kie session. This exception is thrown by a generated class named ConditionEvaluator<UUID> which doesn't help for debugging!
> The inserted object is a basic POJO (named JasmineEventEB) except for an attribute named "value" which accept any "Serializable" object and which is causing the issue.
> The rule condition is quite simple
> $e : JasmineEventEB(probe == "Button:pris" && value == "1")
> In debugging I found that it failed when evaluating the value == "1" part. I can also confirm that the value for the actually inserted JasmineEventEB is a string.
> The stacktrace is:
> {noformat}
> java.lang.InstantiationError: java.io.Serializable
> at ConditionEvaluatorae1a73837e8146bda23004a0450e2e52.evaluate(Unknown Source)
> at org.drools.core.rule.constraint.MvelConstraint.evaluate(MvelConstraint.java:212)
> at org.drools.core.rule.constraint.MvelConstraint.isAllowed(MvelConstraint.java:169)
> at org.drools.core.reteoo.AlphaNode.assertObject(AlphaNode.java:134)
> at org.drools.core.reteoo.CompositeObjectSinkAdapter.doPropagateAssertObject(CompositeObjectSinkAdapter.java:502)
> at org.drools.core.reteoo.CompositeObjectSinkAdapter.propagateAssertObject(CompositeObjectSinkAdapter.java:387)
> at org.drools.core.reteoo.AlphaNode.assertObject(AlphaNode.java:138)
> at org.drools.core.reteoo.CompositeObjectSinkAdapter.doPropagateAssertObject(CompositeObjectSinkAdapter.java:502)
> at org.drools.core.reteoo.CompositeObjectSinkAdapter.propagateAssertObject(CompositeObjectSinkAdapter.java:377)
> at org.drools.core.reteoo.ObjectTypeNode.assertObject(ObjectTypeNode.java:288)
> at org.drools.core.reteoo.EntryPointNode.assertObject(EntryPointNode.java:260)
> at org.drools.core.common.NamedEntryPoint.insert(NamedEntryPoint.java:360)
> at org.drools.core.common.NamedEntryPoint.insert(NamedEntryPoint.java:279)
> at org.drools.core.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:1149)
> at org.drools.core.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:1093)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.insert(StatefulKnowledgeSessionImpl.java:308)
> {noformat}
> I tested both with the java and mvel dialect with the same result.
> Does someone has already encountered this kind of error?
> If you need more details or clarifications please let me know.
> Thanks & regards,
> Loïc
> {quote}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 10 months
[JBoss JIRA] (JBWEB-294) The same JSSE cipher-suite behaves differently with various JDKs
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/JBWEB-294?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration updated JBWEB-294:
------------------------------------------
Bugzilla Update: Perform
Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1075993
> The same JSSE cipher-suite behaves differently with various JDKs
> ----------------------------------------------------------------
>
> Key: JBWEB-294
> URL: https://issues.jboss.org/browse/JBWEB-294
> Project: JBoss Web
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: JBossWeb-7.4.0.GA
> Reporter: Michal Babacek
> Assignee: Remy Maucherat
> Fix For: JBossWeb-7.4.0.GA
>
>
> Hi guys, I believe this is a bug, but correct me if it's just a feature unknown to me.
> I have the following settings:
> h3. Apache HTTP Server (mod_cluster load balancer)
> {code}
> Listen 10.16.92.111:8847
> LogLevel debug
> <VirtualHost 10.16.92.111:8847>
> ServerName 10.16.92.111:8847
> <Directory />
> Order deny,allow
> Deny from all
> Allow from all
> </Directory>
> KeepAliveTimeout 60
> MaxKeepAliveRequests 0
> ServerAdvertise on
> AdvertiseFrequency 5
> ManagerBalancerName qacluster
> AdvertiseGroup 224.0.5.98:60220
> EnableMCPMReceive
> SSLEngine on
> SSLCipherSuite AES128-SHA:ALL:!ADH:!LOW:!MD5:!SSLV2:!NULL
> SSLCertificateFile /mnt/hudson_workspace/proper/server.crt
> SSLCertificateKeyFile /mnt/hudson_workspace/proper/server.key
> SSLCACertificateFile /mnt/hudson_workspace/proper/myca.crt
> #SSLVerifyClient require
> #SSLProxyVerify require
> SSLProxyEngine On
> SSLVerifyDepth 10
> <Location /mcm>
> SetHandler mod_cluster-manager
> Order deny,allow
> Deny from all
> Allow from all
> </Location>
> </VirtualHost>
> {code}
> h3. JBossWeb subsystem
> {code}
> <subsystem xmlns="urn:jboss:domain:web:1.5" native="false">
> <connector name="https" protocol="HTTP/1.1" socket-binding="https"
> scheme="https" enabled="true" secure="true">
> <ssl name="https" ca-certificate-file="/mnt/hudson_workspace/proper/ca-cert.jks"
> certificate-key-file="/mnt/hudson_workspace/proper/client-cert-key.jks"
> certificate-file="/mnt/hudson_workspace/proper/client-cert-key.jks"
> password="tomcat" verify-client="false" key-alias="javaclient"
> cipher-suite="TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384,!TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,!TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,!TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256,!TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256,TLS_DHE_RSA_WITH_AES_256_GCM_SHA384,!TLS_DHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384,TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA,TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA,TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384,TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384,TLS_ECDH_RSA_WITH_AES_256_CBC_SHA,TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA,TLS_DHE_RSA_WITH_AES_256_CBC_SHA256,TLS_DHE_RSA_WITH_AES_256_CBC_SHA,!TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256,!TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256,!TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,!TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA,!TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256,!TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256,!TLS_ECDH_RSA_WITH_AES_128_CBC_SHA,!TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA,!TLS_DHE_RSA_WITH_AES_128_CBC_SHA256,!TLS_DHE_RSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA,TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA,TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA,TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA,TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA,TLS_RSA_WITH_AES_256_GCM_SHA384,TLS_RSA_WITH_AES_256_CBC_SHA256,TLS_RSA_WITH_AES_256_CBC_SHA,!TLS_RSA_WITH_AES_128_GCM_SHA256,!TLS_RSA_WITH_AES_128_CBC_SHA256,!TLS_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_3DES_EDE_CBC_SHA"
> protocol="TLS"/>
> </connector>
> <virtual-server name="default-host" enable-welcome-root="true">
> <alias name="localhost"/>
> <alias name="example.com"/>
> </virtual-server>
> </subsystem>
> {code}
> h3. mod_cluster subsystem
> {code}
> <subsystem xmlns="urn:jboss:domain:modcluster:1.2">
> <mod-cluster-config connector="https" advertise-socket="modcluster">
> <dynamic-load-provider>
> <load-metric type="busyness"/>
> </dynamic-load-provider>
> <ssl ca-certificate-file="/mnt/hudson_workspace/proper/ca-cert.jks"
> certificate-key-file="/mnt/hudson_workspace/proper/client-cert-key.jks"
> password="tomcat" key-alias="javaclient"
> cipher-suite="TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384,!TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,!TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,!TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256,!TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256,TLS_DHE_RSA_WITH_AES_256_GCM_SHA384,!TLS_DHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384,TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA,TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA,TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384,TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384,TLS_ECDH_RSA_WITH_AES_256_CBC_SHA,TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA,TLS_DHE_RSA_WITH_AES_256_CBC_SHA256,TLS_DHE_RSA_WITH_AES_256_CBC_SHA,!TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256,!TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256,!TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,!TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA,!TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256,!TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256,!TLS_ECDH_RSA_WITH_AES_128_CBC_SHA,!TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA,!TLS_DHE_RSA_WITH_AES_128_CBC_SHA256,!TLS_DHE_RSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA,TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA,TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA,TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA,TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA,TLS_RSA_WITH_AES_256_GCM_SHA384,TLS_RSA_WITH_AES_256_CBC_SHA256,TLS_RSA_WITH_AES_256_CBC_SHA,!TLS_RSA_WITH_AES_128_GCM_SHA256,!TLS_RSA_WITH_AES_128_CBC_SHA256,!TLS_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_3DES_EDE_CBC_SHA"
> protocol="TLS"/>
> </mod-cluster-config>
> </subsystem>
> {code}
> h3. Some properties
> {code}
> <system-properties>
> <property name="javax.net.ssl.trustStore" value="/mnt/hudson_workspace/proper/client-cert-key.jks"/>
> <property name="javax.net.ssl.trustStorePassword" value="tomcat"/>
> <property name="jboss.mod_cluster.jvmRoute" value="jboss-eap-6.3"/>
> <property name="jboss.node.name" value="jboss-eap-6.3"/>
> </system-properties>
> {code}
> The test runs several standalone-ha instances, client accesses the AS7 instances directly, then via mod_cluster load balancer. Some of the AS7 instances are being shut down, failover takes place. Client uses client certificate for authentication.
> The result of this test is as follows:
> ||JDK||Arch||Error||Test result||
> |Oracle JDK 1.6|RHEL6 x64|JBWEB002081: No cipher match|(x)|
> |Oracle JDK 1.7|RHEL6 x64|javax.net.ssl.SSLHandshakeException (i)|(x)|
> |Oracle JDK 1.8|RHEL6 x64|javax.net.ssl.SSLHandshakeException (i)|(x)|
> |IBM JDK 1.6|RHEL6 x64|JBWEB002081: No cipher match|(x)|
> |IBM JDK 1.7|RHEL6 x64|JBWEB002081: No cipher match|(x)|
> |OpenJDK 1.7|RHEL6 x64| |(/)|
> |OpenJDK 1.6|RHEL6 x64| |(/)|
> |HP JDK 1.7|HP-UX v11.3|JBWEB002081: No cipher match|(x)|
> h4. (i) javax.net.ssl.SSLHandshakeException
> The funny thing here is that the client can access the AS7 server directly, HTTPS connector is up and running just fine, certificates valid, no problem.
> Yet, the AS7 server fails to do handshake with the Apache HTTP Server instance.
> Please, note that in the aforementioned cipher-suite, some (those leveraging AES-128) methods are prefixed with *!*, so are some methods in the aforementioned Apache HTTP Server configuration.
> {noformat}
> [0m[31m12:58:35,574 ERROR [org.jboss.modcluster] (ContainerBackgroundProcessor[StandardEngine[jboss.web]]) MODCLUSTER000043: Failed to send INFO to 10.16.94.122/10.16.94.122:8847: javax.net.ssl.SSLHandshakeException: Received fatal alert: handshake_failure
> at sun.security.ssl.Alerts.getSSLException(Alerts.java:192) [jsse.jar:1.7.0_45]
> at sun.security.ssl.Alerts.getSSLException(Alerts.java:154) [jsse.jar:1.7.0_45]
> at sun.security.ssl.SSLSocketImpl.recvAlert(SSLSocketImpl.java:1959) [jsse.jar:1.7.0_45]
> at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:1077) [jsse.jar:1.7.0_45]
> at sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1312) [jsse.jar:1.7.0_45]
> at sun.security.ssl.SSLSocketImpl.writeRecord(SSLSocketImpl.java:702) [jsse.jar:1.7.0_45]
> at sun.security.ssl.AppOutputStream.write(AppOutputStream.java:122) [jsse.jar:1.7.0_45]
> at sun.nio.cs.StreamEncoder.writeBytes(StreamEncoder.java:221) [rt.jar:1.7.0_45]
> at sun.nio.cs.StreamEncoder.implFlushBuffer(StreamEncoder.java:291) [rt.jar:1.7.0_45]
> at sun.nio.cs.StreamEncoder.implFlush(StreamEncoder.java:295) [rt.jar:1.7.0_45]
> at sun.nio.cs.StreamEncoder.flush(StreamEncoder.java:141) [rt.jar:1.7.0_45]
> at java.io.OutputStreamWriter.flush(OutputStreamWriter.java:229) [rt.jar:1.7.0_45]
> at java.io.BufferedWriter.flush(BufferedWriter.java:254) [rt.jar:1.7.0_45]
> at org.jboss.modcluster.mcmp.impl.DefaultMCMPHandler.sendRequest(DefaultMCMPHandler.java:494)
> at org.jboss.modcluster.mcmp.impl.DefaultMCMPHandler.sendRequest(DefaultMCMPHandler.java:583)
> at org.jboss.modcluster.mcmp.impl.DefaultMCMPHandler.status(DefaultMCMPHandler.java:370)
> at org.jboss.modcluster.mcmp.impl.DefaultMCMPHandler.status(DefaultMCMPHandler.java:350)
> at org.jboss.modcluster.ModClusterService.status(ModClusterService.java:458)
> at org.jboss.modcluster.container.catalina.CatalinaEventHandlerAdapter.lifecycleEvent(CatalinaEventHandlerAdapter.java:249)
> at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:115) [jbossweb-7.4.0.Beta4.jar:7.4.0.Beta4]
> at org.apache.catalina.core.ContainerBase.backgroundProcess(ContainerBase.java:1323) [jbossweb-7.4.0.Beta4.jar:7.4.0.Beta4]
> at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1588) [jbossweb-7.4.0.Beta4.jar:7.4.0.Beta4]
> at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.run(ContainerBase.java:1574) [jbossweb-7.4.0.Beta4.jar:7.4.0.Beta4]
> at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_45]
> {noformat}
> h3. Question
> How come that some JDKs does not know these JSSE cipher-suite methods, some JDKs do, but fail to do handshake with Apache HTTP Server whereas OpenJDK simply passes with "all green"?
> What is actually a bug? Is it that OpenJDK should fail as well, because the configuration is wrong, or the other JDKs should pass?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 10 months
[JBoss JIRA] (JBWEB-294) The same JSSE cipher-suite behaves differently with various JDKs
by Michal Babacek (JIRA)
[ https://issues.jboss.org/browse/JBWEB-294?page=com.atlassian.jira.plugin.... ]
Michal Babacek commented on JBWEB-294:
--------------------------------------
BTW: Yes, in my [comment|https://issues.jboss.org/browse/JBWEB-292?focusedCommentId=129512...] on the issue [JBWEB-292] I stated "it works", but it is worth mentioning here that it was OpenJDK 1.7 I worked with.
> The same JSSE cipher-suite behaves differently with various JDKs
> ----------------------------------------------------------------
>
> Key: JBWEB-294
> URL: https://issues.jboss.org/browse/JBWEB-294
> Project: JBoss Web
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: JBossWeb-7.4.0.GA
> Reporter: Michal Babacek
> Assignee: Remy Maucherat
> Fix For: JBossWeb-7.4.0.GA
>
>
> Hi guys, I believe this is a bug, but correct me if it's just a feature unknown to me.
> I have the following settings:
> h3. Apache HTTP Server (mod_cluster load balancer)
> {code}
> Listen 10.16.92.111:8847
> LogLevel debug
> <VirtualHost 10.16.92.111:8847>
> ServerName 10.16.92.111:8847
> <Directory />
> Order deny,allow
> Deny from all
> Allow from all
> </Directory>
> KeepAliveTimeout 60
> MaxKeepAliveRequests 0
> ServerAdvertise on
> AdvertiseFrequency 5
> ManagerBalancerName qacluster
> AdvertiseGroup 224.0.5.98:60220
> EnableMCPMReceive
> SSLEngine on
> SSLCipherSuite AES128-SHA:ALL:!ADH:!LOW:!MD5:!SSLV2:!NULL
> SSLCertificateFile /mnt/hudson_workspace/proper/server.crt
> SSLCertificateKeyFile /mnt/hudson_workspace/proper/server.key
> SSLCACertificateFile /mnt/hudson_workspace/proper/myca.crt
> #SSLVerifyClient require
> #SSLProxyVerify require
> SSLProxyEngine On
> SSLVerifyDepth 10
> <Location /mcm>
> SetHandler mod_cluster-manager
> Order deny,allow
> Deny from all
> Allow from all
> </Location>
> </VirtualHost>
> {code}
> h3. JBossWeb subsystem
> {code}
> <subsystem xmlns="urn:jboss:domain:web:1.5" native="false">
> <connector name="https" protocol="HTTP/1.1" socket-binding="https"
> scheme="https" enabled="true" secure="true">
> <ssl name="https" ca-certificate-file="/mnt/hudson_workspace/proper/ca-cert.jks"
> certificate-key-file="/mnt/hudson_workspace/proper/client-cert-key.jks"
> certificate-file="/mnt/hudson_workspace/proper/client-cert-key.jks"
> password="tomcat" verify-client="false" key-alias="javaclient"
> cipher-suite="TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384,!TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,!TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,!TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256,!TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256,TLS_DHE_RSA_WITH_AES_256_GCM_SHA384,!TLS_DHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384,TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA,TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA,TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384,TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384,TLS_ECDH_RSA_WITH_AES_256_CBC_SHA,TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA,TLS_DHE_RSA_WITH_AES_256_CBC_SHA256,TLS_DHE_RSA_WITH_AES_256_CBC_SHA,!TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256,!TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256,!TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,!TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA,!TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256,!TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256,!TLS_ECDH_RSA_WITH_AES_128_CBC_SHA,!TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA,!TLS_DHE_RSA_WITH_AES_128_CBC_SHA256,!TLS_DHE_RSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA,TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA,TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA,TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA,TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA,TLS_RSA_WITH_AES_256_GCM_SHA384,TLS_RSA_WITH_AES_256_CBC_SHA256,TLS_RSA_WITH_AES_256_CBC_SHA,!TLS_RSA_WITH_AES_128_GCM_SHA256,!TLS_RSA_WITH_AES_128_CBC_SHA256,!TLS_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_3DES_EDE_CBC_SHA"
> protocol="TLS"/>
> </connector>
> <virtual-server name="default-host" enable-welcome-root="true">
> <alias name="localhost"/>
> <alias name="example.com"/>
> </virtual-server>
> </subsystem>
> {code}
> h3. mod_cluster subsystem
> {code}
> <subsystem xmlns="urn:jboss:domain:modcluster:1.2">
> <mod-cluster-config connector="https" advertise-socket="modcluster">
> <dynamic-load-provider>
> <load-metric type="busyness"/>
> </dynamic-load-provider>
> <ssl ca-certificate-file="/mnt/hudson_workspace/proper/ca-cert.jks"
> certificate-key-file="/mnt/hudson_workspace/proper/client-cert-key.jks"
> password="tomcat" key-alias="javaclient"
> cipher-suite="TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384,!TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,!TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,!TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256,!TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256,TLS_DHE_RSA_WITH_AES_256_GCM_SHA384,!TLS_DHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384,TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA,TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA,TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384,TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384,TLS_ECDH_RSA_WITH_AES_256_CBC_SHA,TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA,TLS_DHE_RSA_WITH_AES_256_CBC_SHA256,TLS_DHE_RSA_WITH_AES_256_CBC_SHA,!TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256,!TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256,!TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,!TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA,!TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256,!TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256,!TLS_ECDH_RSA_WITH_AES_128_CBC_SHA,!TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA,!TLS_DHE_RSA_WITH_AES_128_CBC_SHA256,!TLS_DHE_RSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA,TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA,TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA,TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA,TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA,TLS_RSA_WITH_AES_256_GCM_SHA384,TLS_RSA_WITH_AES_256_CBC_SHA256,TLS_RSA_WITH_AES_256_CBC_SHA,!TLS_RSA_WITH_AES_128_GCM_SHA256,!TLS_RSA_WITH_AES_128_CBC_SHA256,!TLS_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_3DES_EDE_CBC_SHA"
> protocol="TLS"/>
> </mod-cluster-config>
> </subsystem>
> {code}
> h3. Some properties
> {code}
> <system-properties>
> <property name="javax.net.ssl.trustStore" value="/mnt/hudson_workspace/proper/client-cert-key.jks"/>
> <property name="javax.net.ssl.trustStorePassword" value="tomcat"/>
> <property name="jboss.mod_cluster.jvmRoute" value="jboss-eap-6.3"/>
> <property name="jboss.node.name" value="jboss-eap-6.3"/>
> </system-properties>
> {code}
> The test runs several standalone-ha instances, client accesses the AS7 instances directly, then via mod_cluster load balancer. Some of the AS7 instances are being shut down, failover takes place. Client uses client certificate for authentication.
> The result of this test is as follows:
> ||JDK||Arch||Error||Test result||
> |Oracle JDK 1.6|RHEL6 x64|JBWEB002081: No cipher match|(x)|
> |Oracle JDK 1.7|RHEL6 x64|javax.net.ssl.SSLHandshakeException (i)|(x)|
> |Oracle JDK 1.8|RHEL6 x64|javax.net.ssl.SSLHandshakeException (i)|(x)|
> |IBM JDK 1.6|RHEL6 x64|JBWEB002081: No cipher match|(x)|
> |IBM JDK 1.7|RHEL6 x64|JBWEB002081: No cipher match|(x)|
> |OpenJDK 1.7|RHEL6 x64| |(/)|
> |OpenJDK 1.6|RHEL6 x64| |(/)|
> |HP JDK 1.7|HP-UX v11.3|JBWEB002081: No cipher match|(x)|
> h4. (i) javax.net.ssl.SSLHandshakeException
> The funny thing here is that the client can access the AS7 server directly, HTTPS connector is up and running just fine, certificates valid, no problem.
> Yet, the AS7 server fails to do handshake with the Apache HTTP Server instance.
> Please, note that in the aforementioned cipher-suite, some (those leveraging AES-128) methods are prefixed with *!*, so are some methods in the aforementioned Apache HTTP Server configuration.
> {noformat}
> [0m[31m12:58:35,574 ERROR [org.jboss.modcluster] (ContainerBackgroundProcessor[StandardEngine[jboss.web]]) MODCLUSTER000043: Failed to send INFO to 10.16.94.122/10.16.94.122:8847: javax.net.ssl.SSLHandshakeException: Received fatal alert: handshake_failure
> at sun.security.ssl.Alerts.getSSLException(Alerts.java:192) [jsse.jar:1.7.0_45]
> at sun.security.ssl.Alerts.getSSLException(Alerts.java:154) [jsse.jar:1.7.0_45]
> at sun.security.ssl.SSLSocketImpl.recvAlert(SSLSocketImpl.java:1959) [jsse.jar:1.7.0_45]
> at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:1077) [jsse.jar:1.7.0_45]
> at sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1312) [jsse.jar:1.7.0_45]
> at sun.security.ssl.SSLSocketImpl.writeRecord(SSLSocketImpl.java:702) [jsse.jar:1.7.0_45]
> at sun.security.ssl.AppOutputStream.write(AppOutputStream.java:122) [jsse.jar:1.7.0_45]
> at sun.nio.cs.StreamEncoder.writeBytes(StreamEncoder.java:221) [rt.jar:1.7.0_45]
> at sun.nio.cs.StreamEncoder.implFlushBuffer(StreamEncoder.java:291) [rt.jar:1.7.0_45]
> at sun.nio.cs.StreamEncoder.implFlush(StreamEncoder.java:295) [rt.jar:1.7.0_45]
> at sun.nio.cs.StreamEncoder.flush(StreamEncoder.java:141) [rt.jar:1.7.0_45]
> at java.io.OutputStreamWriter.flush(OutputStreamWriter.java:229) [rt.jar:1.7.0_45]
> at java.io.BufferedWriter.flush(BufferedWriter.java:254) [rt.jar:1.7.0_45]
> at org.jboss.modcluster.mcmp.impl.DefaultMCMPHandler.sendRequest(DefaultMCMPHandler.java:494)
> at org.jboss.modcluster.mcmp.impl.DefaultMCMPHandler.sendRequest(DefaultMCMPHandler.java:583)
> at org.jboss.modcluster.mcmp.impl.DefaultMCMPHandler.status(DefaultMCMPHandler.java:370)
> at org.jboss.modcluster.mcmp.impl.DefaultMCMPHandler.status(DefaultMCMPHandler.java:350)
> at org.jboss.modcluster.ModClusterService.status(ModClusterService.java:458)
> at org.jboss.modcluster.container.catalina.CatalinaEventHandlerAdapter.lifecycleEvent(CatalinaEventHandlerAdapter.java:249)
> at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:115) [jbossweb-7.4.0.Beta4.jar:7.4.0.Beta4]
> at org.apache.catalina.core.ContainerBase.backgroundProcess(ContainerBase.java:1323) [jbossweb-7.4.0.Beta4.jar:7.4.0.Beta4]
> at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1588) [jbossweb-7.4.0.Beta4.jar:7.4.0.Beta4]
> at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.run(ContainerBase.java:1574) [jbossweb-7.4.0.Beta4.jar:7.4.0.Beta4]
> at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_45]
> {noformat}
> h3. Question
> How come that some JDKs does not know these JSSE cipher-suite methods, some JDKs do, but fail to do handshake with Apache HTTP Server whereas OpenJDK simply passes with "all green"?
> What is actually a bug? Is it that OpenJDK should fail as well, because the configuration is wrong, or the other JDKs should pass?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 10 months
[JBoss JIRA] (WFLY-3078) directory-grouping configuration is not getting persisted via CLI when no servers defined
by Emanuel Muckenhuber (JIRA)
[ https://issues.jboss.org/browse/WFLY-3078?page=com.atlassian.jira.plugin.... ]
Emanuel Muckenhuber resolved WFLY-3078.
---------------------------------------
Resolution: Done
> directory-grouping configuration is not getting persisted via CLI when no servers defined
> -----------------------------------------------------------------------------------------
>
> Key: WFLY-3078
> URL: https://issues.jboss.org/browse/WFLY-3078
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Domain Management
> Affects Versions: 8.0.0.Final
> Environment: All Operating System
> Reporter: Jay Kumar SenSharma
> Assignee: Emanuel Muckenhuber
> Fix For: 8.0.1.Final
>
>
> - If none of the servers are defined in "host.xml" (means <servers></servers> empty tag is present) and if the user tries to run the following CLI command to change the "directory-grouping" to "by-type" then the value is not persisted in the configuration file (host.xml) and the <servers></servers> tag is also removed from the host.xml
> {code}
> /host=master/:write-attribute(name=directory-grouping,value=by-type)
> {code}
> - The value of "directory-grouping" is stored "in memory" so this change does not survive the host restart.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 10 months
[JBoss JIRA] (JBWEB-294) The same JSSE cipher-suite behaves differently with various JDKs
by Michal Babacek (JIRA)
[ https://issues.jboss.org/browse/JBWEB-294?page=com.atlassian.jira.plugin.... ]
Michal Babacek commented on JBWEB-294:
--------------------------------------
@[~jfclere]: I guess you might want to comment on it as well. (perhaps tear apart my configuration... :) )
> The same JSSE cipher-suite behaves differently with various JDKs
> ----------------------------------------------------------------
>
> Key: JBWEB-294
> URL: https://issues.jboss.org/browse/JBWEB-294
> Project: JBoss Web
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: JBossWeb-7.4.0.GA
> Reporter: Michal Babacek
> Assignee: Remy Maucherat
> Fix For: JBossWeb-7.4.0.GA
>
>
> Hi guys, I believe this is a bug, but correct me if it's just a feature unknown to me.
> I have the following settings:
> h3. Apache HTTP Server (mod_cluster load balancer)
> {code}
> Listen 10.16.92.111:8847
> LogLevel debug
> <VirtualHost 10.16.92.111:8847>
> ServerName 10.16.92.111:8847
> <Directory />
> Order deny,allow
> Deny from all
> Allow from all
> </Directory>
> KeepAliveTimeout 60
> MaxKeepAliveRequests 0
> ServerAdvertise on
> AdvertiseFrequency 5
> ManagerBalancerName qacluster
> AdvertiseGroup 224.0.5.98:60220
> EnableMCPMReceive
> SSLEngine on
> SSLCipherSuite AES128-SHA:ALL:!ADH:!LOW:!MD5:!SSLV2:!NULL
> SSLCertificateFile /mnt/hudson_workspace/proper/server.crt
> SSLCertificateKeyFile /mnt/hudson_workspace/proper/server.key
> SSLCACertificateFile /mnt/hudson_workspace/proper/myca.crt
> #SSLVerifyClient require
> #SSLProxyVerify require
> SSLProxyEngine On
> SSLVerifyDepth 10
> <Location /mcm>
> SetHandler mod_cluster-manager
> Order deny,allow
> Deny from all
> Allow from all
> </Location>
> </VirtualHost>
> {code}
> h3. JBossWeb subsystem
> {code}
> <subsystem xmlns="urn:jboss:domain:web:1.5" native="false">
> <connector name="https" protocol="HTTP/1.1" socket-binding="https"
> scheme="https" enabled="true" secure="true">
> <ssl name="https" ca-certificate-file="/mnt/hudson_workspace/proper/ca-cert.jks"
> certificate-key-file="/mnt/hudson_workspace/proper/client-cert-key.jks"
> certificate-file="/mnt/hudson_workspace/proper/client-cert-key.jks"
> password="tomcat" verify-client="false" key-alias="javaclient"
> cipher-suite="TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384,!TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,!TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,!TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256,!TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256,TLS_DHE_RSA_WITH_AES_256_GCM_SHA384,!TLS_DHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384,TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA,TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA,TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384,TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384,TLS_ECDH_RSA_WITH_AES_256_CBC_SHA,TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA,TLS_DHE_RSA_WITH_AES_256_CBC_SHA256,TLS_DHE_RSA_WITH_AES_256_CBC_SHA,!TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256,!TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256,!TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,!TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA,!TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256,!TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256,!TLS_ECDH_RSA_WITH_AES_128_CBC_SHA,!TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA,!TLS_DHE_RSA_WITH_AES_128_CBC_SHA256,!TLS_DHE_RSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA,TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA,TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA,TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA,TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA,TLS_RSA_WITH_AES_256_GCM_SHA384,TLS_RSA_WITH_AES_256_CBC_SHA256,TLS_RSA_WITH_AES_256_CBC_SHA,!TLS_RSA_WITH_AES_128_GCM_SHA256,!TLS_RSA_WITH_AES_128_CBC_SHA256,!TLS_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_3DES_EDE_CBC_SHA"
> protocol="TLS"/>
> </connector>
> <virtual-server name="default-host" enable-welcome-root="true">
> <alias name="localhost"/>
> <alias name="example.com"/>
> </virtual-server>
> </subsystem>
> {code}
> h3. mod_cluster subsystem
> {code}
> <subsystem xmlns="urn:jboss:domain:modcluster:1.2">
> <mod-cluster-config connector="https" advertise-socket="modcluster">
> <dynamic-load-provider>
> <load-metric type="busyness"/>
> </dynamic-load-provider>
> <ssl ca-certificate-file="/mnt/hudson_workspace/proper/ca-cert.jks"
> certificate-key-file="/mnt/hudson_workspace/proper/client-cert-key.jks"
> password="tomcat" key-alias="javaclient"
> cipher-suite="TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384,!TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,!TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,!TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256,!TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256,TLS_DHE_RSA_WITH_AES_256_GCM_SHA384,!TLS_DHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384,TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA,TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA,TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384,TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384,TLS_ECDH_RSA_WITH_AES_256_CBC_SHA,TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA,TLS_DHE_RSA_WITH_AES_256_CBC_SHA256,TLS_DHE_RSA_WITH_AES_256_CBC_SHA,!TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256,!TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256,!TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,!TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA,!TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256,!TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256,!TLS_ECDH_RSA_WITH_AES_128_CBC_SHA,!TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA,!TLS_DHE_RSA_WITH_AES_128_CBC_SHA256,!TLS_DHE_RSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA,TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA,TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA,TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA,TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA,TLS_RSA_WITH_AES_256_GCM_SHA384,TLS_RSA_WITH_AES_256_CBC_SHA256,TLS_RSA_WITH_AES_256_CBC_SHA,!TLS_RSA_WITH_AES_128_GCM_SHA256,!TLS_RSA_WITH_AES_128_CBC_SHA256,!TLS_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_3DES_EDE_CBC_SHA"
> protocol="TLS"/>
> </mod-cluster-config>
> </subsystem>
> {code}
> h3. Some properties
> {code}
> <system-properties>
> <property name="javax.net.ssl.trustStore" value="/mnt/hudson_workspace/proper/client-cert-key.jks"/>
> <property name="javax.net.ssl.trustStorePassword" value="tomcat"/>
> <property name="jboss.mod_cluster.jvmRoute" value="jboss-eap-6.3"/>
> <property name="jboss.node.name" value="jboss-eap-6.3"/>
> </system-properties>
> {code}
> The test runs several standalone-ha instances, client accesses the AS7 instances directly, then via mod_cluster load balancer. Some of the AS7 instances are being shut down, failover takes place. Client uses client certificate for authentication.
> The result of this test is as follows:
> ||JDK||Arch||Error||Test result||
> |Oracle JDK 1.6|RHEL6 x64|JBWEB002081: No cipher match|(x)|
> |Oracle JDK 1.7|RHEL6 x64|javax.net.ssl.SSLHandshakeException (i)|(x)|
> |Oracle JDK 1.8|RHEL6 x64|javax.net.ssl.SSLHandshakeException (i)|(x)|
> |IBM JDK 1.6|RHEL6 x64|JBWEB002081: No cipher match|(x)|
> |IBM JDK 1.7|RHEL6 x64|JBWEB002081: No cipher match|(x)|
> |OpenJDK 1.7|RHEL6 x64| |(/)|
> |OpenJDK 1.6|RHEL6 x64| |(/)|
> |HP JDK 1.7|HP-UX v11.3|JBWEB002081: No cipher match|(x)|
> h4. (i) javax.net.ssl.SSLHandshakeException
> The funny thing here is that the client can access the AS7 server directly, HTTPS connector is up and running just fine, certificates valid, no problem.
> Yet, the AS7 server fails to do handshake with the Apache HTTP Server instance.
> Please, note that in the aforementioned cipher-suite, some (those leveraging AES-128) methods are prefixed with *!*, so are some methods in the aforementioned Apache HTTP Server configuration.
> {noformat}
> [0m[31m12:58:35,574 ERROR [org.jboss.modcluster] (ContainerBackgroundProcessor[StandardEngine[jboss.web]]) MODCLUSTER000043: Failed to send INFO to 10.16.94.122/10.16.94.122:8847: javax.net.ssl.SSLHandshakeException: Received fatal alert: handshake_failure
> at sun.security.ssl.Alerts.getSSLException(Alerts.java:192) [jsse.jar:1.7.0_45]
> at sun.security.ssl.Alerts.getSSLException(Alerts.java:154) [jsse.jar:1.7.0_45]
> at sun.security.ssl.SSLSocketImpl.recvAlert(SSLSocketImpl.java:1959) [jsse.jar:1.7.0_45]
> at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:1077) [jsse.jar:1.7.0_45]
> at sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1312) [jsse.jar:1.7.0_45]
> at sun.security.ssl.SSLSocketImpl.writeRecord(SSLSocketImpl.java:702) [jsse.jar:1.7.0_45]
> at sun.security.ssl.AppOutputStream.write(AppOutputStream.java:122) [jsse.jar:1.7.0_45]
> at sun.nio.cs.StreamEncoder.writeBytes(StreamEncoder.java:221) [rt.jar:1.7.0_45]
> at sun.nio.cs.StreamEncoder.implFlushBuffer(StreamEncoder.java:291) [rt.jar:1.7.0_45]
> at sun.nio.cs.StreamEncoder.implFlush(StreamEncoder.java:295) [rt.jar:1.7.0_45]
> at sun.nio.cs.StreamEncoder.flush(StreamEncoder.java:141) [rt.jar:1.7.0_45]
> at java.io.OutputStreamWriter.flush(OutputStreamWriter.java:229) [rt.jar:1.7.0_45]
> at java.io.BufferedWriter.flush(BufferedWriter.java:254) [rt.jar:1.7.0_45]
> at org.jboss.modcluster.mcmp.impl.DefaultMCMPHandler.sendRequest(DefaultMCMPHandler.java:494)
> at org.jboss.modcluster.mcmp.impl.DefaultMCMPHandler.sendRequest(DefaultMCMPHandler.java:583)
> at org.jboss.modcluster.mcmp.impl.DefaultMCMPHandler.status(DefaultMCMPHandler.java:370)
> at org.jboss.modcluster.mcmp.impl.DefaultMCMPHandler.status(DefaultMCMPHandler.java:350)
> at org.jboss.modcluster.ModClusterService.status(ModClusterService.java:458)
> at org.jboss.modcluster.container.catalina.CatalinaEventHandlerAdapter.lifecycleEvent(CatalinaEventHandlerAdapter.java:249)
> at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:115) [jbossweb-7.4.0.Beta4.jar:7.4.0.Beta4]
> at org.apache.catalina.core.ContainerBase.backgroundProcess(ContainerBase.java:1323) [jbossweb-7.4.0.Beta4.jar:7.4.0.Beta4]
> at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1588) [jbossweb-7.4.0.Beta4.jar:7.4.0.Beta4]
> at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.run(ContainerBase.java:1574) [jbossweb-7.4.0.Beta4.jar:7.4.0.Beta4]
> at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_45]
> {noformat}
> h3. Question
> How come that some JDKs does not know these JSSE cipher-suite methods, some JDKs do, but fail to do handshake with Apache HTTP Server whereas OpenJDK simply passes with "all green"?
> What is actually a bug? Is it that OpenJDK should fail as well, because the configuration is wrong, or the other JDKs should pass?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 10 months
[JBoss JIRA] (WFLY-3008) System property substitution does not work in subnet-match
by Emanuel Muckenhuber (JIRA)
[ https://issues.jboss.org/browse/WFLY-3008?page=com.atlassian.jira.plugin.... ]
Emanuel Muckenhuber resolved WFLY-3008.
---------------------------------------
Resolution: Done
> System property substitution does not work in subnet-match
> ----------------------------------------------------------
>
> Key: WFLY-3008
> URL: https://issues.jboss.org/browse/WFLY-3008
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Domain Management
> Affects Versions: 8.0.0.Final
> Reporter: Rich DiCroce
> Assignee: Emanuel Muckenhuber
> Priority: Minor
> Fix For: 8.0.1.Final
>
>
> Specifying a system property in subnet-match when defining an interface causes an exception on startup. Example:
> {code:xml}
> <property name="subnet" value="192.168.0.0/16"/>
> ...
> <interface name="public">
> <subnet-match value="${subnet}"/>
> </interface>
> {code}
> Causes:
> {code}
> 12:36:13,457 ERROR [org.jboss.as.server] (Controller Boot Thread) JBAS015956: Caught exception during boot: org.jboss.as.controller.persistence.ConfigurationPersistenceException: JBAS014676: Failed to parse configuration
> at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:112) [wildfly-controller-8.0.0.Final.jar:8.0.0.Final]
> at org.jboss.as.server.ServerService.boot(ServerService.java:331) [wildfly-server-8.0.0.Final.jar:8.0.0.Final]
> at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:256) [wildfly-controller-8.0.0.Final.jar:8.0.0.Final]
> at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_45]
> Caused by: javax.xml.stream.XMLStreamException: ParseError at [row,col]:[311,46]
> Message: JBAS014693: Invalid 'value' ${subnet} -- must be of the form address/mask
> at org.jboss.as.server.parsing.CommonXml.validateAddressMask(CommonXml.java:605) [wildfly-server-8.0.0.Final.jar:8.0.0.Final]
> at org.jboss.as.server.parsing.CommonXml.parseSimpleInterfaceCriterion(CommonXml.java:587) [wildfly-server-8.0.0.Final.jar:8.0.0.Final]
> at org.jboss.as.server.parsing.CommonXml.parseInterfaceCriteria(CommonXml.java:467) [wildfly-server-8.0.0.Final.jar:8.0.0.Final]
> at org.jboss.as.server.parsing.CommonXml.parseInterfaces(CommonXml.java:644) [wildfly-server-8.0.0.Final.jar:8.0.0.Final]
> at org.jboss.as.server.parsing.StandaloneXml.readServerElement_1_4(StandaloneXml.java:465) [wildfly-server-8.0.0.Final.jar:8.0.0.Final]
> at org.jboss.as.server.parsing.StandaloneXml.readElement(StandaloneXml.java:145) [wildfly-server-8.0.0.Final.jar:8.0.0.Final]
> at org.jboss.as.server.parsing.StandaloneXml.readElement(StandaloneXml.java:107) [wildfly-server-8.0.0.Final.jar:8.0.0.Final]
> at org.jboss.staxmapper.XMLMapperImpl.processNested(XMLMapperImpl.java:110) [staxmapper-1.1.0.Final.jar:1.1.0.Final]
> at org.jboss.staxmapper.XMLMapperImpl.parseDocument(XMLMapperImpl.java:69) [staxmapper-1.1.0.Final.jar:1.1.0.Final]
> at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:104) [wildfly-controller-8.0.0.Final.jar:8.0.0.Final]
> ... 3 more
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 10 months
[JBoss JIRA] (WFLY-3000) Incorrect 'Content-Type' response set after executing an erroneous command
by Emanuel Muckenhuber (JIRA)
[ https://issues.jboss.org/browse/WFLY-3000?page=com.atlassian.jira.plugin.... ]
Emanuel Muckenhuber resolved WFLY-3000.
---------------------------------------
Resolution: Done
> Incorrect 'Content-Type' response set after executing an erroneous command
> --------------------------------------------------------------------------
>
> Key: WFLY-3000
> URL: https://issues.jboss.org/browse/WFLY-3000
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Domain Management
> Affects Versions: 8.0.0.Final
> Reporter: Christos Vasilakis
> Assignee: Emanuel Muckenhuber
> Fix For: 8.0.1.Final
>
>
> The http management interface, upon error, returns an incorrect 'Content-Type' of
> {noformat}
> 'Content-Type: text/plain; charset=utf-8'
> {noformat}
> although JSON response is returned.
> To reproduce, issue from the command line a simple 'read' operation
> {noformat}
> curl --digest -D - http://localhost:9990/management --header "Content-Type: application/json" -d '{"operation":"read-attribute", "name":"foo"}' -u <username>:<password>
> ..
> Content-Type: text/plain; charset=utf-8
> Content-Length: 119
> Date: Sun, 23 Feb 2014 17:27:10 GMT
> {
> "outcome" : "failed",
> "failure-description" : "JBAS014792: Unknown attribute foo",
> "rolled-back" : true
> }
> {noformat}
> The 'Content-Type' should have been set to *'application/json'* instead of *'text/plain'*
> Note: On JBoss AS 7.1.1.Final, the correct type of *'application/json'* is returned for the same operation.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 10 months