March 2019 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-11912) Component upgrade of Narayana to 5.8.4.Final

by Thomas Jenkinson (Jira)

[ https://issues.jboss.org/browse/WFLY-11912?page=com.atlassian.jira.plugin... ] Thomas Jenkinson commented on WFLY-11912: ----------------------------------------- [~ochaloup] sorry I missed this one > Component upgrade of Narayana to 5.8.4.Final > -------------------------------------------- > > Key: WFLY-11912 > URL: https://issues.jboss.org/browse/WFLY-11912 > Project: WildFly > Issue Type: Component Upgrade > Components: Transactions > Affects Versions: 16.0.0.Final > Reporter: Ondrej Chaloupka > Assignee: Ondrej Chaloupka > Priority: Major > -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 7 months

1
0
0 / 0

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

by Sebastian Laskawiec (Jira)

[ https://issues.jboss.org/browse/WFLY-11007?page=com.atlassian.jira.plugin... ] Sebastian Laskawiec edited comment on WFLY-11007 at 3/28/19 10:55 AM: ---------------------------------------------------------------------- Unfortunately I'm having some difficulties extracting the reproducer. Even when I export the list of CA Certificates, it works without any problems when using {{docker run -v...}} options. So there must be something that OpenShift does extra in this use case. I guess the only way to reproduce it locally is to use {{oc cluster up}}. I also updated the steps to reproduce to make it a bit easier for you [~iankko][~mchoma]. ==== Update ==== Ha! I managed to create a reproducer for you based on {{docker run}} command: https://github.com/slaskawi/WFLY-11007 was (Author: sebastian.laskawiec): Unfortunately I'm having some difficulties extracting the reproducer. Even when I export the list of CA Certificates, it works without any problems when using {{docker run -v...}} options. So there must be something that OpenShift does extra in this use case. I guess the only way to reproduce it locally is to use {{oc cluster up}}. I also updated the steps to reproduce to make it a bit easier for you [~iankko][~mchoma]. > 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 Laskawiec > Assignee: Stuart Douglas > Priority: Major > > 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.12.1#712002)

6 years, 7 months

1
0
0 / 0

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

by Martin Choma (Jira)

[ https://issues.jboss.org/browse/WFLY-11007?page=com.atlassian.jira.plugin... ] Martin Choma commented on WFLY-11007: ------------------------------------- I have followed your reproducer on OCP 3.11 and I don't see this error: {code} curl -vk https://10.128.0.37:8443/auth * About to connect() to 10.128.0.37 port 8443 (#0) * Trying 10.128.0.37... * Connected to 10.128.0.37 (10.128.0.37) port 8443 (#0) * Initializing NSS with certpath: sql:/etc/pki/nssdb * skipping SSL peer certificate verification * NSS: client certificate not found (nickname not specified) * SSL connection using TLS_RSA_WITH_AES_256_CBC_SHA256 * Server certificate: * subject: CN=keycloak.default.svc * start date: Mar 28 14:49:47 2019 GMT * expire date: Mar 27 14:49:48 2021 GMT * common name: keycloak.default.svc * issuer: CN=openshift-service-serving-signer@1553780535 > GET /auth HTTP/1.1 > User-Agent: curl/7.29.0 > Host: 10.128.0.37:8443 > Accept: */* > < HTTP/1.1 303 See Other < Connection: keep-alive < Location: https://10.128.0.37:8443/auth/ < Content-Length: 0 < Date: Thu, 28 Mar 2019 14:51:45 GMT < * Connection #0 to host 10.128.0.37 left intact {code} > 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 Laskawiec > Assignee: Stuart Douglas > Priority: Major > > 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.12.1#712002)

6 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-11679) Remove org.jboss.metadata module

by Simon Priadka (Jira)

[ https://issues.jboss.org/browse/WFLY-11679?page=com.atlassian.jira.plugin... ] Simon Priadka commented on WFLY-11679: -------------------------------------- Hi [~brian.stansberry],[~yersan] I have found out, that the *keycloak-wildlfy-subsystem* adapter depends on the *org.jboss.metadata* module. Adapters depending on this module can be found at [this search|https://github.com/keycloak/keycloak/search?l=XML&q=org.jboss.meta...]. > Remove org.jboss.metadata module > -------------------------------- > > Key: WFLY-11679 > URL: https://issues.jboss.org/browse/WFLY-11679 > Project: WildFly > Issue Type: Sub-task > Components: Class Loading, Clustering > Reporter: Brian Stansberry > Assignee: Yeray Borges > Priority: Minor > Fix For: 17.0.0.Beta1 > > > Not urgent, just something I noticed when looking at https://github.com/wildfly/wildfly/pull/12014/. > The org.jboss.metadata module just depends on and exports a bunch of other ones. It's jboss-api=private and It's only use within Wildfly is org.wildfly.extension.clustering.singleton which could presumably depend directly on what it needs. > We'd want to check some with dependent projects in case they use it and do any removal fairly early in a release cycle. -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-11918) Keycloak adapter broken because of missing org.jboss.metadata module

by Simon Priadka (Jira)

Simon Priadka created WFLY-11918: ------------------------------------ Summary: Keycloak adapter broken because of missing org.jboss.metadata module Key: WFLY-11918 URL: https://issues.jboss.org/browse/WFLY-11918 Project: WildFly Issue Type: Bug Affects Versions: 17.0.0.Beta1 Reporter: Simon Priadka Assignee: Brian Stansberry When trying to install keycloak-wildfly-subsystem described in [this guide|https://www.keycloak.org/docs/3.0/getting_started/topics/secure-jbo...], the install fails because of: {code:java} { "outcome" => "failed", "failure-description" => "WFLYCTL0158: Operation handler failed: org.jboss.modules.ModuleLoadError: org.jboss.metadata", "rolled-back" => true } {code} -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-11912) Component upgrade of Narayana to 5.8.4.Final

by Ondrej Chaloupka (Jira)

[ https://issues.jboss.org/browse/WFLY-11912?page=com.atlassian.jira.plugin... ] Ondrej Chaloupka closed WFLY-11912. ----------------------------------- Resolution: Duplicate Issue WFLY-11917 > Component upgrade of Narayana to 5.8.4.Final > -------------------------------------------- > > Key: WFLY-11912 > URL: https://issues.jboss.org/browse/WFLY-11912 > Project: WildFly > Issue Type: Component Upgrade > Components: Transactions > Affects Versions: 16.0.0.Final > Reporter: Ondrej Chaloupka > Assignee: Ondrej Chaloupka > Priority: Major > -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-11917) Upgrade Narayana to 5.9.5.Final

by Thomas Jenkinson (Jira)

[ https://issues.jboss.org/browse/WFLY-11917?page=com.atlassian.jira.plugin... ] Thomas Jenkinson commented on WFLY-11917: ----------------------------------------- PR will be like this: https://github.com/wildfly/wildfly/compare/master...jbosstm:WFLY-11917?ex... > Upgrade Narayana to 5.9.5.Final > ------------------------------- > > Key: WFLY-11917 > URL: https://issues.jboss.org/browse/WFLY-11917 > Project: WildFly > Issue Type: Component Upgrade > Components: Transactions > Reporter: Thomas Jenkinson > Assignee: Thomas Jenkinson > Priority: Major > > https://issues.jboss.org/projects/JBTM/versions/12340965#release-report-t... -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 7 months

1
0
0 / 0

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

by Sebastian Laskawiec (Jira)

[ https://issues.jboss.org/browse/WFLY-11007?page=com.atlassian.jira.plugin... ] Sebastian Laskawiec edited comment on WFLY-11007 at 3/28/19 10:42 AM: ---------------------------------------------------------------------- Unfortunately I'm having some difficulties extracting the reproducer. Even when I export the list of CA Certificates, it works without any problems when using {{docker run -v...}} options. So there must be something that OpenShift does extra in this use case. I guess the only way to reproduce it locally is to use {{oc cluster up}}. I also updated the steps to reproduce to make it a bit easier for you [~iankko][~mchoma]. was (Author: sebastian.laskawiec): Unfortunately I'm having some difficulties extracting the reproducer. Even when I export the list of CA Certificates, it works without any problems when using {{docker run -v...}} options. So there must be something that OpenShift does extra in this use case. I guess the only way to reproduce it locally is to use {{oc cluster up}}. > 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 Laskawiec > Assignee: Stuart Douglas > Priority: Major > > 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.12.1#712002)

6 years, 7 months

1
0
0 / 0

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

by Sebastian Laskawiec (Jira)

[ https://issues.jboss.org/browse/WFLY-11007?page=com.atlassian.jira.plugin... ] Sebastian Laskawiec commented on WFLY-11007: -------------------------------------------- Unfortunately I'm having some difficulties extracting the reproducer. Even when I export the list of CA Certificates, it works without any problems when using {{docker run -v...}} options. So there must be something that OpenShift does extra in this use case. I guess the only way to reproduce it locally is to use {{oc cluster up}}. > 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 Laskawiec > Assignee: Stuart Douglas > Priority: Major > > 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.12.1#712002)

6 years, 7 months

1
0
0 / 0

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

by Sebastian Laskawiec (Jira)

[ https://issues.jboss.org/browse/WFLY-11007?page=com.atlassian.jira.plugin... ] Sebastian Laskawiec edited comment on WFLY-11007 at 3/28/19 10:39 AM: ---------------------------------------------------------------------- [~mchoma] So far I've checked: - Adding {{-Djsse.SSLEngine.acceptLargeFragments=true}}, didn't help, the error message is the same. - Adding {{-Djsse.enableMFLNExtension=true -Djsse.SSLEngine.acceptLargeFragments=true}}, didn't help either. Let me try to create a reproducer for you. was (Author: sebastian.laskawiec): So far I've checked: - Adding {{-Djsse.SSLEngine.acceptLargeFragments=true}}, didn't help, the error message is the same. - Adding {{-Djsse.enableMFLNExtension=true -Djsse.SSLEngine.acceptLargeFragments=true}}, didn't help either. Let me try to create a reproducer for you. > 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 Laskawiec > Assignee: Stuart Douglas > Priority: Major > > 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.12.1#712002)

6 years, 7 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira March 2019