September 2018 - jboss-jira - Jboss List Archives

[JBoss JIRA] (JGRP-2286) VERIFY_SUSPECT can return false positives if member is killed and immediately restarted

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-2286?page=com.atlassian.jira.plugin.... ] Bela Ban updated JGRP-2286: --------------------------- Fix Version/s: 4.0.14 > VERIFY_SUSPECT can return false positives if member is killed and immediately restarted > --------------------------------------------------------------------------------------- > > Key: JGRP-2286 > URL: https://issues.jboss.org/browse/JGRP-2286 > Project: JGroups > Issue Type: Bug > Affects Versions: 4.0.13 > Reporter: Paul Ferraro > Assignee: Paul Ferraro > Fix For: 4.0.14 > > > When a member is killed, it is suspected and VERIFY_SUSPECT attempts to send a message to the member to verify that it has left. If, however, the member is restarted before the VERIFY_SUSPECT sends its message, the newly started member (with same physical address, but different UUID) can receive it and erroneously reply with an I_AM_NOT_DEAD response. This results in a zombie member in the view that will remain until the reincarnated member leaves. > To fix this, we should add the address of the suspected member to the VerifyHeader and validate that the member is us before sending an I_AM_NOT_DEAD response. > Additionally, we can respond with a new MBR_IS_DEAD response on behalf of the suspected member, in the case that the message was receive by the reincarnated member to expedite the removal of the suspected member from the view. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2286) VERIFY_SUSPECT can return false positives if member is killed and immediately restarted

by Paul Ferraro (JIRA)

Paul Ferraro created JGRP-2286: ---------------------------------- Summary: VERIFY_SUSPECT can return false positives if member is killed and immediately restarted Key: JGRP-2286 URL: https://issues.jboss.org/browse/JGRP-2286 Project: JGroups Issue Type: Bug Affects Versions: 4.0.13 Reporter: Paul Ferraro Assignee: Bela Ban When a member is killed, it is suspected and VERIFY_SUSPECT attempts to send a message to the member to verify that it has left. If, however, the member is restarted before the VERIFY_SUSPECT sends its message, the newly started member (with same physical address, but different UUID) can receive it and erroneously reply with an I_AM_NOT_DEAD response. This results in a zombie member in the view that will remain until the reincarnated member leaves. To fix this, we should add the address of the suspected member to the VerifyHeader and validate that the member is us before sending an I_AM_NOT_DEAD response. Additionally, we can respond with a new MBR_IS_DEAD response on behalf of the suspected member, in the case that the message was receive by the reincarnated member to expedite the removal of the suspected member from the view. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2286) VERIFY_SUSPECT can return false positives if member is killed and immediately restarted

by Paul Ferraro (JIRA)

[ https://issues.jboss.org/browse/JGRP-2286?page=com.atlassian.jira.plugin.... ] Paul Ferraro reassigned JGRP-2286: ---------------------------------- Assignee: Paul Ferraro (was: Bela Ban) > VERIFY_SUSPECT can return false positives if member is killed and immediately restarted > --------------------------------------------------------------------------------------- > > Key: JGRP-2286 > URL: https://issues.jboss.org/browse/JGRP-2286 > Project: JGroups > Issue Type: Bug > Affects Versions: 4.0.13 > Reporter: Paul Ferraro > Assignee: Paul Ferraro > > When a member is killed, it is suspected and VERIFY_SUSPECT attempts to send a message to the member to verify that it has left. If, however, the member is restarted before the VERIFY_SUSPECT sends its message, the newly started member (with same physical address, but different UUID) can receive it and erroneously reply with an I_AM_NOT_DEAD response. This results in a zombie member in the view that will remain until the reincarnated member leaves. > To fix this, we should add the address of the suspected member to the VerifyHeader and validate that the member is us before sending an I_AM_NOT_DEAD response. > Additionally, we can respond with a new MBR_IS_DEAD response on behalf of the suspected member, in the case that the message was receive by the reincarnated member to expedite the removal of the suspected member from the view. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 10 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-2689) The ability to hide a Simulation Scenario asset based on a flag

by Toni Rikkola (JIRA)

[ https://issues.jboss.org/browse/DROOLS-2689?page=com.atlassian.jira.plugi... ] Toni Rikkola commented on DROOLS-2689: -------------------------------------- Need to take a look. Sounds like there are several overlapping features. > The ability to hide a Simulation Scenario asset based on a flag > --------------------------------------------------------------- > > Key: DROOLS-2689 > URL: https://issues.jboss.org/browse/DROOLS-2689 > Project: Drools > Issue Type: Story > Components: Scenario Simulation and Testing > Reporter: Juraj Soltes > Assignee: Toni Rikkola > Labels: ScenarioSimulation > > Experimental feature (disabled by default). > If the user wants to enable the Add new Simulation Scenario option she can use a command line parameter to enable it. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-10535) PooledConnectionFactory JNDI aliases are created in the root service container

by ehsavoie Hugonnet (JIRA)

[ https://issues.jboss.org/browse/WFLY-10535?page=com.atlassian.jira.plugin... ] ehsavoie Hugonnet reassigned WFLY-10535: ---------------------------------------- Assignee: ehsavoie Hugonnet (was: Stuart Douglas) > PooledConnectionFactory JNDI aliases are created in the root service container > ------------------------------------------------------------------------------ > > Key: WFLY-10535 > URL: https://issues.jboss.org/browse/WFLY-10535 > Project: WildFly > Issue Type: Bug > Components: JMS > Reporter: Stuart Douglas > Assignee: ehsavoie Hugonnet > > This means they are not covered by the container state monitor -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 10 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-2689) The ability to hide a Simulation Scenario asset based on a flag

by Toni Rikkola (JIRA)

[ https://issues.jboss.org/browse/DROOLS-2689?page=com.atlassian.jira.plugi... ] Toni Rikkola updated DROOLS-2689: --------------------------------- Summary: The ability to hide a Simulation Scenario asset based on a flag (was: The ability to hide an asset based on a flag) > The ability to hide a Simulation Scenario asset based on a flag > --------------------------------------------------------------- > > Key: DROOLS-2689 > URL: https://issues.jboss.org/browse/DROOLS-2689 > Project: Drools > Issue Type: Story > Components: Scenario Simulation and Testing > Reporter: Juraj Soltes > Assignee: Toni Rikkola > Labels: ScenarioSimulation > > Experimental feature (disabled by default). > If the user wants to enable the Add new Simulation Scenario option she can use a command line parameter to enable it. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-11007) Using OpenShift generated certificates and client auth cause TLS errors

by Sebastian Łaskawiec (JIRA)

[ https://issues.jboss.org/browse/WFLY-11007?page=com.atlassian.jira.plugin... ] Sebastian Łaskawiec updated WFLY-11007: --------------------------------------- Issue Type: Bug (was: Feature Request) > Using OpenShift generated certificates and client auth cause TLS errors > ----------------------------------------------------------------------- > > Key: WFLY-11007 > URL: https://issues.jboss.org/browse/WFLY-11007 > Project: WildFly > Issue Type: Bug > Components: Security, Web (Undertow) > Affects Versions: 13.0.0.Final > Reporter: Sebastian Łaskawiec > Assignee: Stuart Douglas > > h2. Summary > It seems that when using OpenShift generated certificates and client auth (with {{want-client-auth="true"}}) the TLS handshake fails with {{RECV TLSv1.2 ALERT: fatal, record_overflow}} message. > h2. Explanation > I'm using {{oc cluster up}} and deploying Keycloak (WF 13 based) on OpenShift local cluster using the (1) template. The service in the the template uses OpenShift generated certificates ({{"service.alpha.openshift.io/serving-cert-secret-name": "keycloak-x509-https-secret"}}). Both files are mounted in the Keycloak pod and translated into keystore and truststore (see the configuration after the transformation (2)). Once the pod is up and running, I'm issuing a {{curl}} command as shown in (3). {{curl}} fails saying that {{* error:1408F092:SSL routines:ssl3_get_record:data length too long}}. The server logs with TLS Handshake debugging turned on might be found here (4). As shown in the link, the server has written {{16384}} bytes. > I also did a test with manually created certificates (5). The result might be found here (6). As shown in the link, we've written {{16050}} bytes instead of {{16384}} and the handshake was successful. > h2. Possible solution > Perhaps we should cut the list CAs transmitted by the server when asking for client auth when it exceeds certain number of bytes. It would be helpful to write a warn message too. > Links: > - (1) Keycloak OCP Template https://gist.github.com/slaskawi/57ed810a7109a02a9d884b61ce2e7f13 > - (2) Transformed configuration https://gist.github.com/slaskawi/92aead6c519b867621129b640b4a3c88 > - (3) curl command https://gist.github.com/slaskawi/3bc32b8e96c2499cb7b48c3c5cb28616 > - (4) https://gist.github.com/slaskawi/b6477fe3cd65890c879cfe6f95359450#file-lo... > - (5) Keycloak and OpenShift integration demo https://github.com/keycloak/openshift-integration/blob/master/install-key... > - (6) https://gist.github.com/slaskawi/7fd87e1f2e6c4faf657d9e8289ed3392#file-lo... -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-11007) Using OpenShift generated certificates and client auth cause TLS errors

by Sebastian Łaskawiec (JIRA)

[ https://issues.jboss.org/browse/WFLY-11007?page=com.atlassian.jira.plugin... ] Sebastian Łaskawiec commented on WFLY-11007: -------------------------------------------- Hey [~swd847], I'm not exactly sure where this ticket belongs. Maybe even better place for is the {{CLOUD}} JIRA project. I don't know.. BTW, [~stianst][~iankko][~luck3y] You might be also interested in this. > Using OpenShift generated certificates and client auth cause TLS errors > ----------------------------------------------------------------------- > > Key: WFLY-11007 > URL: https://issues.jboss.org/browse/WFLY-11007 > Project: WildFly > Issue Type: Feature Request > Components: Security, Web (Undertow) > Affects Versions: 13.0.0.Final > Reporter: Sebastian Łaskawiec > Assignee: Stuart Douglas > > h2. Summary > It seems that when using OpenShift generated certificates and client auth (with {{want-client-auth="true"}}) the TLS handshake fails with {{RECV TLSv1.2 ALERT: fatal, record_overflow}} message. > h2. Explanation > I'm using {{oc cluster up}} and deploying Keycloak (WF 13 based) on OpenShift local cluster using the (1) template. The service in the the template uses OpenShift generated certificates ({{"service.alpha.openshift.io/serving-cert-secret-name": "keycloak-x509-https-secret"}}). Both files are mounted in the Keycloak pod and translated into keystore and truststore (see the configuration after the transformation (2)). Once the pod is up and running, I'm issuing a {{curl}} command as shown in (3). {{curl}} fails saying that {{* error:1408F092:SSL routines:ssl3_get_record:data length too long}}. The server logs with TLS Handshake debugging turned on might be found here (4). As shown in the link, the server has written {{16384}} bytes. > I also did a test with manually created certificates (5). The result might be found here (6). As shown in the link, we've written {{16050}} bytes instead of {{16384}} and the handshake was successful. > h2. Possible solution > Perhaps we should cut the list CAs transmitted by the server when asking for client auth when it exceeds certain number of bytes. It would be helpful to write a warn message too. > Links: > - (1) Keycloak OCP Template https://gist.github.com/slaskawi/57ed810a7109a02a9d884b61ce2e7f13 > - (2) Transformed configuration https://gist.github.com/slaskawi/92aead6c519b867621129b640b4a3c88 > - (3) curl command https://gist.github.com/slaskawi/3bc32b8e96c2499cb7b48c3c5cb28616 > - (4) https://gist.github.com/slaskawi/b6477fe3cd65890c879cfe6f95359450#file-lo... > - (5) Keycloak and OpenShift integration demo https://github.com/keycloak/openshift-integration/blob/master/install-key... > - (6) https://gist.github.com/slaskawi/7fd87e1f2e6c4faf657d9e8289ed3392#file-lo... -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-11007) Using OpenShift generated certificates and client auth cause TLS errors

by Sebastian Łaskawiec (JIRA)

Sebastian Łaskawiec created WFLY-11007: ------------------------------------------ Summary: Using OpenShift generated certificates and client auth cause TLS errors Key: WFLY-11007 URL: https://issues.jboss.org/browse/WFLY-11007 Project: WildFly Issue Type: Feature Request Components: Security, Web (Undertow) Affects Versions: 13.0.0.Final Reporter: Sebastian Łaskawiec Assignee: Stuart Douglas h2. Summary It seems that when using OpenShift generated certificates and client auth (with {{want-client-auth="true"}}) the TLS handshake fails with {{RECV TLSv1.2 ALERT: fatal, record_overflow}} message. h2. Explanation I'm using {{oc cluster up}} and deploying Keycloak (WF 13 based) on OpenShift local cluster using the (1) template. The service in the the template uses OpenShift generated certificates ({{"service.alpha.openshift.io/serving-cert-secret-name": "keycloak-x509-https-secret"}}). Both files are mounted in the Keycloak pod and translated into keystore and truststore (see the configuration after the transformation (2)). Once the pod is up and running, I'm issuing a {{curl}} command as shown in (3). {{curl}} fails saying that {{* error:1408F092:SSL routines:ssl3_get_record:data length too long}}. The server logs with TLS Handshake debugging turned on might be found here (4). As shown in the link, the server has written {{16384}} bytes. I also did a test with manually created certificates (5). The result might be found here (6). As shown in the link, we've written {{16050}} bytes instead of {{16384}} and the handshake was successful. h2. Possible solution Perhaps we should cut the list CAs transmitted by the server when asking for client auth when it exceeds certain number of bytes. It would be helpful to write a warn message too. Links: - (1) Keycloak OCP Template https://gist.github.com/slaskawi/57ed810a7109a02a9d884b61ce2e7f13 - (2) Transformed configuration https://gist.github.com/slaskawi/92aead6c519b867621129b640b4a3c88 - (3) curl command https://gist.github.com/slaskawi/3bc32b8e96c2499cb7b48c3c5cb28616 - (4) https://gist.github.com/slaskawi/b6477fe3cd65890c879cfe6f95359450#file-lo... - (5) Keycloak and OpenShift integration demo https://github.com/keycloak/openshift-integration/blob/master/install-key... - (6) https://gist.github.com/slaskawi/7fd87e1f2e6c4faf657d9e8289ed3392#file-lo... -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-10950) JDK11 basic LdapLoginModuleTestCase: No subject alternative names present

by Jan Kalina (JIRA)

[ https://issues.jboss.org/browse/WFLY-10950?page=com.atlassian.jira.plugin... ] Jan Kalina updated WFLY-10950: ------------------------------ Summary: JDK11 basic LdapLoginModuleTestCase: No subject alternative names present (was: JDK11 basic LdapLoginModuleTestCase failure) > JDK11 basic LdapLoginModuleTestCase: No subject alternative names present > -------------------------------------------------------------------------- > > Key: WFLY-10950 > URL: https://issues.jboss.org/browse/WFLY-10950 > Project: WildFly > Issue Type: Sub-task > Components: Test Suite > Reporter: Jan Kalina > Assignee: Jan Kalina > > {code} > cd testsuite/integration/basic > JAVA_HOME=/opt/jdk-11/ PATH=$JAVA_HOME/bin:$PATH mvn test -Dtest=LdapLoginModuleTestCase#testLdaps -Djavax.net.debug=all > {code} > {code} > javax.net.ssl|ERROR|1D|NioProcessor-5|2018-08-30 12:28:39.055 CEST|TransportContext.java:317|Fatal (CERTIFICATE_UNKNOWN): Received fatal alert: certificate_unknown ( > "throwable" : { > javax.net.ssl.SSLHandshakeException: Received fatal alert: certificate_unknown > at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:128) > at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:117) > at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:312) > at java.base/sun.security.ssl.Alert$AlertConsumer.consume(Alert.java:270) > at java.base/sun.security.ssl.TransportContext.dispatch(TransportContext.java:181) > at java.base/sun.security.ssl.SSLTransport.decode(SSLTransport.java:164) > at java.base/sun.security.ssl.SSLEngineImpl.decode(SSLEngineImpl.java:666) > at java.base/sun.security.ssl.SSLEngineImpl.readRecord(SSLEngineImpl.java:621) > at java.base/sun.security.ssl.SSLEngineImpl.unwrap(SSLEngineImpl.java:438) > at java.base/sun.security.ssl.SSLEngineImpl.unwrap(SSLEngineImpl.java:417) > at java.base/javax.net.ssl.SSLEngine.unwrap(SSLEngine.java:626) > at org.apache.mina.filter.ssl.SslHandler.unwrap(SslHandler.java:754) > {code} > Edit: the backing error is: > {code} > 2018-08-31 15:23:47,788 ERROR [stderr] (default task-1) "throwable" : { > 2018-08-31 15:23:47,788 ERROR [stderr] (default task-1) java.security.cert.CertificateException: No subject alternative names present > 2018-08-31 15:23:47,788 ERROR [stderr] (default task-1) at java.base/sun.security.util.HostnameChecker.matchIP(HostnameChecker.java:137) > 2018-08-31 15:23:47,788 ERROR [stderr] (default task-1) at java.base/sun.security.util.HostnameChecker.match(HostnameChecker.java:96) > 2018-08-31 15:23:47,788 ERROR [stderr] (default task-1) at java.base/sun.security.ssl.X509TrustManagerImpl.checkIdentity(X509TrustManagerImpl.java:463) > 2018-08-31 15:23:47,788 ERROR [stderr] (default task-1) at java.base/sun.security.ssl.X509TrustManagerImpl.checkIdentity(X509TrustManagerImpl.java:434) > 2018-08-31 15:23:47,788 ERROR [stderr] (default task-1) at java.base/sun.security.ssl.X509TrustManagerImpl.checkTrusted(X509TrustManagerImpl.java:233) > 2018-08-31 15:23:47,789 ERROR [stderr] (default task-1) at java.base/sun.security.ssl.X509TrustManagerImpl.checkServerTrusted(X509TrustManagerImpl.java:129) > 2018-08-31 15:23:47,789 ERROR [stderr] (default task-1) at java.base/sun.security.ssl.CertificateMessage$T12CertificateConsumer.checkServerCerts(CertificateMessage.java:626) > 2018-08-31 15:23:47,789 ERROR [stderr] (default task-1) at java.base/sun.security.ssl.CertificateMessage$T12CertificateConsumer.onCertificate(CertificateMessage.java:461) > 2018-08-31 15:23:47,789 ERROR [stderr] (default task-1) at java.base/sun.security.ssl.CertificateMessage$T12CertificateConsumer.consume(CertificateMessage.java:361) > 2018-08-31 15:23:47,789 ERROR [stderr] (default task-1) at java.base/sun.security.ssl.SSLHandshake.consume(SSLHandshake.java:392) > {code} -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 10 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira September 2018