[JBoss JIRA] (WFLY-10736) Server in cluster hangs during start after previous kill
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/WFLY-10736?page=com.atlassian.jira.plugin... ]
Kabir Khan commented on WFLY-10736:
-----------------------------------
[~pferraro] I am able to reproduce the issue using the steps in [~mnovak]'s 'Steps to reproduce' section. I get the following last output in the logs which apparently is where it normally hangs.
{code}
10:39:37,482 INFO [org.jboss.as.ejb3] (MSC service thread 1-4) WFLYEJB0042: Started message driven bean 'mdb' with 'activemq-ra.rar' resource adapter
{code}
where it just hangs.
Using both the workaround and the patched jgroups I end up with the following:
{code}
11:25:10,516 INFO [org.jboss.as] (MSC service thread 1-2) WFLYSRV0050: JBoss EAP CD 7.2.0.CD14 (WildFly Core 6.0.4.Final-redhat-00001) stopped in 34ms
Sep 13, 2018 11:25:10 AM org.jboss.arquillian.container.test.impl.client.container.ClientContainerController kill
INFO: Hard killing of a server instance
{code}
Here it waits for a while, before proceeding with:
{code}
11:26:40,552 Thread-34 INFO [org.jboss.qa.hornetq.tools.ContainerUtils:94] File exists so appending suffix. Printing thread dump for pid: 28850 to file: /Users/kabir/sourcecontrol/temp/eap-tests-hornetq/scripts/server1/jboss-eap/standalone/log/node-1-thread-dump-before-kill-shutdown-sequence.txt
11:26:40,552 Thread-34 INFO [org.jboss.qa.hornetq.tools.ContainerUtils:98] Check if thread dump is supported on this platform: Mac OS X
11:26:40,689 Thread-34 WARN [org.jboss.qa.hornetq.tools.ContainerUtils:146] Print thread dump of process: 28850 was not successful. Return value was 1
{code}
I think [~rhusar] is able to reproduce so he can hopefully provide more details.
> Server in cluster hangs during start after previous kill
> --------------------------------------------------------
>
> Key: WFLY-10736
> URL: https://issues.jboss.org/browse/WFLY-10736
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Reporter: Miroslav Novak
> Assignee: Paul Ferraro
> Priority: Blocker
> Labels: blocker-WF14
> Fix For: 15.0.0.Alpha1
>
> Attachments: Lodh2TestCase.testRemoteJcaInboundOnly-traces.zip, Lodh2TestCase.testRemoteJcaInboundOnly.zip, Lodh2TestCase.testRemoteJcaInboundOnly2.zip, clusterKilTest.zip, logs-traces.zip, logs-traces2.zip, logs-traces3.zip, logs-traces4.zip, logs-with-workaround.zip, node-1-thread-dump-before-kill-shutdown-sequence.txt, server-with-mdb.log, standalone-full-ha-1.xml, standalone-full-ha-2.xml
>
>
> There is regression in JGroups or Infinispan in one of our tests for fault tolerance of JMS bridges. However work on JMS bridge appears to be unrelated. Issue was hit in WF weekly run.
> Test Scenario:
> * There are two servers. InQueue is deployed on Node 1,
> * OutQueue is deployed on Node 2. Both servers are started.
> * Large byte messages are sent to InQueue deployed on Node 1. Bridge between servers/queues transfers messages from node 1 to node 2.
> * Node 1 is killed and started again.
> * All messages are received from OutQueue deployed on Node 2.
> Result:
> Node 1 does not start after kill and hangs. There is following exception logged in node 2:
> {code}
> :26:17,894 INFO [org.infinispan.CLUSTER] (thread-12,ejb,node-2) ISPN100000: Node node-1 joined the cluster
> 09:26:18,520 INFO [org.infinispan.CLUSTER] (thread-12,ejb,node-2) ISPN000094: Received new cluster view for channel ejb: [node-2|7] (2) [node-2, node-1]
> 09:26:18,521 INFO [org.infinispan.CLUSTER] (thread-12,ejb,node-2) ISPN100001: Node node-1 left the cluster
> 09:26:18,521 INFO [org.infinispan.CLUSTER] (thread-12,ejb,node-2) ISPN000094: Received new cluster view for channel ejb: [node-2|7] (2) [node-2, node-1]
> 09:26:18,522 INFO [org.infinispan.CLUSTER] (thread-12,ejb,node-2) ISPN100001: Node node-1 left the cluster
> 09:26:18,522 INFO [org.infinispan.CLUSTER] (thread-12,ejb,node-2) ISPN000094: Received new cluster view for channel ejb: [node-2|7] (2) [node-2, node-1]
> 09:26:18,522 INFO [org.infinispan.CLUSTER] (thread-12,ejb,node-2) ISPN100001: Node node-1 left the cluster
> 09:26:18,522 INFO [org.infinispan.CLUSTER] (thread-12,ejb,node-2) ISPN000094: Received new cluster view for channel ejb: [node-2|7] (2) [node-2, node-1]
> 09:26:18,523 INFO [org.infinispan.CLUSTER] (thread-12,ejb,node-2) ISPN100001: Node node-1 left the cluster
> 09:26:18,868 INFO [org.infinispan.CLUSTER] (remote-thread--p5-t2) ISPN000310: Starting cluster-wide rebalance for cache default, topology CacheTopology{id=17, phase=READ_OLD_WRITE_ALL, rebalanceId=6, currentCH=ReplicatedConsistentHash{ns = 256, owners = (2)[node-2: 122, node-1: 134]}, pendingCH=ReplicatedConsistentHash{ns = 256, owners = (3)[node-2: 84, node-1: 90, node-1: 82]}, unionCH=null, actualMembers=[node-2, node-1, node-1], persistentUUIDs=[12443bfb-e88a-46f3-919e-9213bf38ce19, 2873237f-d881-463f-8a5a-940bf1d764e5, a05ea8af-a83b-42a9-b937-dc2da1cae6d1]}
> 09:26:18,869 INFO [org.infinispan.CLUSTER] (remote-thread--p5-t2) [Context=default][Scope=node-2]ISPN100002: Started rebalance with topology id 17
> 09:26:18,870 INFO [org.infinispan.CLUSTER] (transport-thread--p14-t5) [Context=default][Scope=node-2]ISPN100003: Node node-2 finished rebalance phase with topology id 17
> 09:26:18,981 INFO [org.infinispan.CLUSTER] (remote-thread--p5-t2) [Context=default][Scope=node-1]ISPN100003: Node node-1 finished rebalance phase with topology id 17
> 09:27:18,530 WARN [org.infinispan.topology.ClusterTopologyManagerImpl] (transport-thread--p15-t4) ISPN000197: Error updating cluster member list: org.infinispan.util.concurrent.TimeoutException: ISPN000476: Timed out waiting for responses for request 4 from node-1
> at org.infinispan.remoting.transport.impl.MultiTargetRequest.onTimeout(MultiTargetRequest.java:167)
> at org.infinispan.remoting.transport.AbstractRequest.call(AbstractRequest.java:87)
> at org.infinispan.remoting.transport.AbstractRequest.call(AbstractRequest.java:22)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266) [rt.jar:1.8.0_131]
> at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180) [rt.jar:1.8.0_131]
> at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293) [rt.jar:1.8.0_131]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_131]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_131]
> at java.lang.Thread.run(Thread.java:748) [rt.jar:1.8.0_131]
> Suppressed: java.util.concurrent.ExecutionException: org.infinispan.util.concurrent.TimeoutException: ISPN000476: Timed out waiting for responses for request 4 from node-1
> at java.util.concurrent.CompletableFuture.reportGet(CompletableFuture.java:357) [rt.jar:1.8.0_131]
> at java.util.concurrent.CompletableFuture.get(CompletableFuture.java:1915) [rt.jar:1.8.0_131]
> at org.infinispan.util.concurrent.CompletableFutures.await(CompletableFutures.java:82)
> at org.infinispan.remoting.transport.Transport.invokeRemotely(Transport.java:71)
> at org.infinispan.topology.ClusterTopologyManagerImpl.confirmMembersAvailable(ClusterTopologyManagerImpl.java:540)
> at org.infinispan.topology.ClusterTopologyManagerImpl.updateCacheMembers(ClusterTopologyManagerImpl.java:523)
> at org.infinispan.topology.ClusterTopologyManagerImpl.handleClusterView(ClusterTopologyManagerImpl.java:334)
> at org.infinispan.topology.ClusterTopologyManagerImpl.access$500(ClusterTopologyManagerImpl.java:85)
> at org.infinispan.topology.ClusterTopologyManagerImpl$ClusterViewListener.lambda$handleViewChange$0(ClusterTopologyManagerImpl.java:745)
> at org.infinispan.executors.LimitedExecutor.runTasks(LimitedExecutor.java:144)
> at org.infinispan.executors.LimitedExecutor.access$100(LimitedExecutor.java:33)
> at org.infinispan.executors.LimitedExecutor$Runner.run(LimitedExecutor.java:174)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_131]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_131]
> at org.wildfly.clustering.service.concurrent.ClassLoaderThreadFactory.lambda$newThread$0(ClassLoaderThreadFactory.java:47)
> ... 1 more
> Caused by: org.infinispan.util.concurrent.TimeoutException: ISPN000476: Timed out waiting for responses for request 4 from node-1
> at org.infinispan.remoting.transport.impl.MultiTargetRequest.onTimeout(MultiTargetRequest.java:167)
> at org.infinispan.remoting.transport.AbstractRequest.call(AbstractRequest.java:87)
> at org.infinispan.remoting.transport.AbstractRequest.call(AbstractRequest.java:22)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266) [rt.jar:1.8.0_131]
> at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180) [rt.jar:1.8.0_131]
> at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293) [rt.jar:1.8.0_131]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_131]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_131]
> ... 1 more
> [CIRCULAR REFERENCE:java.util.concurrent.ExecutionException: org.infinispan.util.concurrent.TimeoutException: ISPN000476: Timed out waiting for responses for request 4 from node-1]
> 09:27:18,530 WARN [org.infinispan.topology.ClusterTopologyManagerImpl] (transport-thread--p16-t4) ISPN000197: Error updating cluster member list: org.infinispan.util.concurrent.TimeoutException: ISPN000476: Timed out waiting for responses for request 4 from node-1
> at org.infinispan.remoting.transport.impl.MultiTargetRequest.onTimeout(MultiTargetRequest.java:167)
> at org.infinispan.remoting.transport.AbstractRequest.call(AbstractRequest.java:87)
> at org.infinispan.remoting.transport.AbstractRequest.call(AbstractRequest.java:22)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266) [rt.jar:1.8.0_131]
> at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180) [rt.jar:1.8.0_131]
> at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293) [rt.jar:1.8.0_131]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_131]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_131]
> at java.lang.Thread.run(Thread.java:748) [rt.jar:1.8.0_131]
> Suppressed: java.util.concurrent.ExecutionException: org.infinispan.util.concurrent.TimeoutException: ISPN000476: Timed out waiting for responses for request 4 from node-1
> at java.util.concurrent.CompletableFuture.reportGet(CompletableFuture.java:357) [rt.jar:1.8.0_131]
> at java.util.concurrent.CompletableFuture.get(CompletableFuture.java:1915) [rt.jar:1.8.0_131]
> at org.infinispan.util.concurrent.CompletableFutures.await(CompletableFutures.java:82)
> at org.infinispan.remoting.transport.Transport.invokeRemotely(Transport.java:71)
> at org.infinispan.topology.ClusterTopologyManagerImpl.confirmMembersAvailable(ClusterTopologyManagerImpl.java:540)
> at org.infinispan.topology.ClusterTopologyManagerImpl.updateCacheMembers(ClusterTopologyManagerImpl.java:523)
> at org.infinispan.topology.ClusterTopologyManagerImpl.handleClusterView(ClusterTopologyManagerImpl.java:334)
> at org.infinispan.topology.ClusterTopologyManagerImpl.access$500(ClusterTopologyManagerImpl.java:85)
> at org.infinispan.topology.ClusterTopologyManagerImpl$ClusterViewListener.lambda$handleViewChange$0(ClusterTopologyManagerImpl.java:745)
> at org.infinispan.executors.LimitedExecutor.runTasks(LimitedExecutor.java:144)
> at org.infinispan.executors.LimitedExecutor.access$100(LimitedExecutor.java:33)
> at org.infinispan.executors.LimitedExecutor$Runner.run(LimitedExecutor.java:174)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_131]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_131]
> at org.wildfly.clustering.service.concurrent.ClassLoaderThreadFactory.lambda$newThread$0(ClassLoaderThreadFactory.java:47)
> ... 1 more
> Caused by: org.infinispan.util.concurrent.TimeoutException: ISPN000476: Timed out waiting for responses for request 4 from node-1
> at org.infinispan.remoting.transport.impl.MultiTargetRequest.onTimeout(MultiTargetRequest.java:167)
> at org.infinispan.remoting.transport.AbstractRequest.call(AbstractRequest.java:87)
> at org.infinispan.remoting.transport.AbstractRequest.call(AbstractRequest.java:22)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266) [rt.jar:1.8.0_131]
> at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180) [rt.jar:1.8.0_131]
> at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293) [rt.jar:1.8.0_131]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_131]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_131]
> ... 1 more
> [CIRCULAR REFERENCE:java.util.concurrent.ExecutionException: org.infinispan.util.concurrent.TimeoutException: ISPN000476: Timed out waiting for responses for request 4 from node-1]
> {code}
> There is default JGroups udp stack configured which is used by Infinispan. Both of the servers (jgroups udp) are bound to 127.0.0.1. Node 2 has port offset 1000.
> Attaching thread dump from node 1 when it hangs during start.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 10 months
[JBoss JIRA] (WFLY-11007) Using OpenShift generated certificates and client auth cause TLS errors
by Jan Lieskovsky (JIRA)
[ https://issues.jboss.org/browse/WFLY-11007?page=com.atlassian.jira.plugin... ]
Jan Lieskovsky commented on WFLY-11007:
---------------------------------------
But how would the client app know, how much of the certificates is "enough yet" and how much of them is "already too much"? Shouldn't the server instead try to send the replies to the client in multiple packets, each of them having proper length of the TLS record field? Didn't investigate the RFC, but I would assume there's something "a continuation packet" or a flag how to notify the client, the list of CAs isn't complete and will continue in the next packet yet.
If there isn't, and the truststore truly needs to be properly truncated by the user sooner than it can be specified as the source for the server, in that case, the server should recognize, the length of the TLS record field doesn't meet the requirement, and should issue a warning / or a request the user to modify the truststore, so the requirement is met.
But this sounds strange to me (see above, how would the app / user know, e.g. 70 certs is good enough yet, but 71 of them is already "too much"? Not counting the fact, since the certs are different, I assume their contribution to the final TLS record field to be different, unless there's exact length contribution to the final field for each of them).
> 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
[JBoss JIRA] (DROOLS-1905) Use of the "%" sign in the title
by Enrique González Martínez (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1905?page=com.atlassian.jira.plugi... ]
Enrique González Martínez commented on DROOLS-1905:
---------------------------------------------------
Some background regarding this:
https://issues.jboss.org/browse/GUVNOR-2706
PR: https://github.com/kiegroup/drools/pull/938/files
This was regarding multibye file names in drools. I tried this with 7.0.2 and it is raising the same error either with "100% ok" or "あいうえお".
It fails in both cases when try to open an editor. (The file is created but is not possible to open the editor).
> Use of the "%" sign in the title
> --------------------------------
>
> Key: DROOLS-1905
> URL: https://issues.jboss.org/browse/DROOLS-1905
> Project: Drools
> Issue Type: Bug
> Components: Guided Rule Editor
> Affects Versions: 6.5.0.Final
> Reporter: Petr Farmakovsky
> Assignee: Enrique González Martínez
> Labels: drools-tools
> Attachments: 14-12-2016 19-28-17.gif
>
>
> When you save rules or other objects Drools Workbench allows the use of the "%" sign in the title. Opening of any rule results in an error if there is an object with title containing "%" sign in the repository.
> It is impossible to build and publish the project.
> Error message: URLDecoder: Illegal hex characters in escape (%) pattern - For input string: "s."
> !14-12-2016 19-28-17.gif!
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 10 months
[JBoss JIRA] (WFLY-11007) Using OpenShift generated certificates and client auth cause TLS errors
by Jan Lieskovsky (JIRA)
[ https://issues.jboss.org/browse/WFLY-11007?page=com.atlassian.jira.plugin... ]
Jan Lieskovsky commented on WFLY-11007:
---------------------------------------
{noformat}
Of course, I could trim the list down manually (by using keytool) or even remove /etc/pki/ca-trust/extracted/java/cacerts altogether but I guess this is a valid situation we have here and it's the WF that should be monitoring the length of the payload it sends (especially if there's a limit set by the RFC).
It is worth to mention that this happen only on client auth turned on. Only in this case, the server sends a list of CAs.
{noformat}
Given the above research, IMHO this is EAP server bug. Of course, one can say, if you want to get it working, don't use that much certificates. But since this might be valid usecase / need, IMHO the server should be updated to send the list of CA certs in such chunks, it won't overflow the TLS field length (like split them in more subsequent packets, having the TLS field only as that much long, as required / allowed by the RFC).
[~dlofthouse] WDYT -^?
{noformat}
I hope this answers your questions Jan Lieskovsky and Darran Lofthouse
{noformat}
[~sebastian.laskawiec] Hey Seb, yes it does! Thank you for your investigation!
> 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
[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:
--------------------------------------------
{quote}
Adding Darran to the Cc-list yet. Per this ticket it happens when the server has a very long list of trusted CAs, the TLS record might overflow the maximum allowed 16384 (2^14) length, required by RFC 5246 section 6.2.1. What's not clear to me yet, if the current behaviour is the OpenShift's service certificate secrets service's fault, or JBoss EAP server's fault.
{quote}
I think the problem is with such a long list of CAs sent by default. The {{$JRE_HOME/lib/security}} contains a link to system CAs (1)
(1) Here's how can you get it from the community image (but the same applies for the product):
{code}
Terminal 1:
docker run jboss/keycloak:master
Terminal 2:
docker exec -it <sha1 obtained by docker ps> bash
[jboss@47ef14ab7df2 ~]$ ls -la /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.181-3.b13.el7_5.x86_64/jre/lib/security/cacerts
lrwxrwxrwx. 1 root root 41 Aug 21 16:45 /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.181-3.b13.el7_5.x86_64/jre/lib/security/cacerts -> ../../../../../../../etc/pki/java/cacerts
[jboss@47ef14ab7df2 ~]$ ls -la /etc/pki/java/cacerts
lrwxrwxrwx. 1 root root 40 Aug 4 22:04 /etc/pki/java/cacerts -> /etc/pki/ca-trust/extracted/java/cacerts
all available commands
[jboss@47ef14ab7df2 ~]$ keytool -list -keystore /etc/pki/ca-trust/extracted/java/cacerts
Enter keystore password: <whatever>
***************** WARNING WARNING WARNING *****************
* The integrity of the information stored in your keystore *
* has NOT been verified! In order to verify its integrity, *
* you must provide your keystore password. *
***************** WARNING WARNING WARNING *****************
Keystore type: jks
Keystore provider: SUN
Your keystore contains 133 entries
digicertassuredidrootca, Aug 4, 2018, trustedCertEntry,
Certificate fingerprint (SHA1): 05:63:B8:63:0D:62:D7:5A:BB:C8:AB:1E:4B:DF:B5:A8:99:B2:4D:43
trktrustelektroniksertifikahizmetsalaycsh5, Aug 4, 2018, trustedCertEntry,
Certificate fingerprint (SHA1): C4:18:F6:4D:46:D1:DF:00:3D:27:30:13:72:43:A9:12:11:C6:75:FB
affirmtrustcommercial, Aug 4, 2018, trustedCertEntry,
Certificate fingerprint (SHA1): F9:B5:B6:32:45:5F:9C:BE:EC:57:5F:80:DC:E9:6E:2C:C7:B2:78:B7
t-telesecglobalrootclass3, Aug 4, 2018, trustedCertEntry,
Certificate fingerprint (SHA1): 55:A6:72:3E:CB:F2:EC:CD:C3:23:74:70:19:9D:2A:BE:11:E3:81:D1
certinomis-rootca, Aug 4, 2018, trustedCertEntry,
Certificate fingerprint (SHA1): 9D:70:BB:01:A5:A4:A0:18:11:2E:F7:1C:01:B9:32:C5:34:E7:88:A8
t-telesecglobalrootclass2, Aug 4, 2018, trustedCertEntry,
Certificate fingerprint (SHA1): 59:0D:2D:7D:88:4F:40:2E:61:7E:A5:62:32:17:65:CF:17:D8:94:E9
comodoecccertificationauthority, Aug 4, 2018, trustedCertEntry,
Certificate fingerprint (SHA1): 9F:74:4E:9F:2B:4D:BA:EC:0F:31:2C:50:B6:56:3B:8E:2D:93:C3:11
swisssignsilverca-g2, Aug 4, 2018, trustedCertEntry,
Certificate fingerprint (SHA1): 9B:AA:E5:9F:56:EE:21:CB:43:5A:BE:25:93:DF:A7:F0:40:D1:1D:CB
cadisigrootr2, Aug 4, 2018, trustedCertEntry,
Certificate fingerprint (SHA1): B5:61:EB:EA:A4:DE:E4:25:4B:69:1A:98:A5:57:47:C2:34:C7:D9:71
securetrustca, Aug 4, 2018, trustedCertEntry,
Certificate fingerprint (SHA1): 87:82:C6:C3:04:35:3B:CF:D2:96:92:D2:59:3E:7D:44:D9:34:FF:11
accvraiz1, Aug 4, 2018, trustedCertEntry,
Certificate fingerprint (SHA1): 93:05:7A:88:15:C6:4F:CE:88:2F:FA:91:16:52:28:78:BC:53:64:17
staatdernederlandenrootca-g3, Aug 4, 2018, trustedCertEntry,
Certificate fingerprint (SHA1): D8:EB:6B:41:51:92:59:E0:F3:E7:85:00:C0:3D:B6:88:97:C9:EE:FC
staatdernederlandenrootca-g2, Aug 4, 2018, trustedCertEntry,
Certificate fingerprint (SHA1): 59:AF:82:79:91:86:C7:B4:75:07:CB:CF:03:57:46:EB:04:DD:B7:16
entrustrootcertificationauthority, Aug 4, 2018, trustedCertEntry,
Certificate fingerprint (SHA1): B3:1E:B1:B7:40:E3:6C:84:02:DA:DC:37:D4:4D:F5:D4:67:49:52:F9
identrustpublicsectorrootca1, Aug 4, 2018, trustedCertEntry,
Certificate fingerprint (SHA1): BA:29:41:60:77:98:3F:F4:F3:EF:F2:31:05:3B:2E:EA:6D:4D:45:FD
entrust.netpremium2048secureserverca, Aug 4, 2018, trustedCertEntry,
Certificate fingerprint (SHA1): 50:30:06:09:1D:97:D4:F5:AE:39:F7:CB:E7:92:7D:7D:65:2D:34:31
secureglobalca, Aug 4, 2018, trustedCertEntry,
Certificate fingerprint (SHA1): 3A:44:73:5A:E5:81:90:1F:24:86:61:46:1E:3B:9C:C4:5F:F5:3A:1B
opentrustrootcag3, Aug 4, 2018, trustedCertEntry,
Certificate fingerprint (SHA1): 6E:26:64:F3:56:BF:34:55:BF:D1:93:3F:7C:01:DE:D8:13:DA:8A:A6
netlockarany(classgold)ftanstvny, Aug 4, 2018, trustedCertEntry,
Certificate fingerprint (SHA1): 06:08:3F:59:3F:15:A1:04:A0:69:A4:6B:A9:03:D0:06:B7:97:09:91
eecertificationcentrerootca, Aug 4, 2018, trustedCertEntry,
Certificate fingerprint (SHA1): C9:A8:B9:E7:55:80:5E:58:E3:53:77:A7:25:EB:AF:C3:7B:27:CC:D7
teliasonerarootcav1, Aug 4, 2018, trustedCertEntry,
Certificate fingerprint (SHA1): 43:13:BB:96:F1:D5:86:9B:C1:4E:6A:92:F6:CF:F6:34:69:87:82:37
opentrustrootcag2, Aug 4, 2018, trustedCertEntry,
Certificate fingerprint (SHA1): 79:5F:88:60:C5:AB:7C:3D:92:E6:CB:F4:8D:E1:45:CD:11:EF:60:0B
autoridaddecertificacionfirmaprofesionalcifa62634068, Aug 4, 2018, trustedCertEntry,
Certificate fingerprint (SHA1): AE:C5:FB:3F:C8:E1:BF:C4:E5:4F:03:07:5A:9A:E8:00:B7:F7:B6:FA
opentrustrootcag1, Aug 4, 2018, trustedCertEntry,
Certificate fingerprint (SHA1): 79:91:E8:34:F7:E2:EE:DD:08:95:01:52:E9:55:2D:14:E9:58:D5:7E
acraizfnmt-rcm, Aug 4, 2018, trustedCertEntry,
Certificate fingerprint (SHA1): EC:50:35:07:B2:15:C4:95:62:19:E2:A8:9A:5B:42:99:2C:4C:2C:20
gdcatrustauthr5root, Aug 4, 2018, trustedCertEntry,
Certificate fingerprint (SHA1): 0F:36:38:5B:81:1A:25:C3:9B:31:4E:83:CA:E9:34:66:70:CC:74:B4
izenpe.com, Aug 4, 2018, trustedCertEntry,
Certificate fingerprint (SHA1): 2F:78:3D:25:52:18:A7:4A:65:39:71:B5:2C:A2:9C:45:15:6F:E9:19
e-tugracertificationauthority, Aug 4, 2018, trustedCertEntry,
Certificate fingerprint (SHA1): 51:C6:E7:08:49:06:6E:F3:92:D4:5C:A0:0D:6D:A3:62:8F:C3:52:39
quovadisrootca3, Aug 4, 2018, trustedCertEntry,
Certificate fingerprint (SHA1): 1F:49:14:F7:D8:74:95:1D:DD:AE:02:C0:BE:FD:3A:2D:82:75:51:85
quovadisrootca2, Aug 4, 2018, trustedCertEntry,
Certificate fingerprint (SHA1): CA:3A:FB:CF:12:40:36:4B:44:B2:16:20:88:80:48:39:19:93:7C:F7
entrustrootcertificationauthority-ec1, Aug 4, 2018, trustedCertEntry,
Certificate fingerprint (SHA1): 20:D8:06:40:DF:9B:25:F5:12:25:3A:11:EA:F7:59:8A:EB:14:B5:47
oistewisekeyglobalrootgbca, Aug 4, 2018, trustedCertEntry,
Certificate fingerprint (SHA1): 0F:F9:40:76:18:D3:D7:6A:4B:98:F0:A8:35:9E:0C:FD:27:AC:CC:ED
addtrustexternalroot, Aug 4, 2018, trustedCertEntry,
Certificate fingerprint (SHA1): 02:FA:F3:E2:91:43:54:68:60:78:57:69:4D:F5:E4:5B:68:85:18:68
digicertglobalrootg3, Aug 4, 2018, trustedCertEntry,
Certificate fingerprint (SHA1): 7E:04:DE:89:6A:3E:66:6D:00:E6:87:D3:3F:FA:D9:3B:E8:3D:34:9E
swisssigngoldca-g2, Aug 4, 2018, trustedCertEntry,
Certificate fingerprint (SHA1): D8:C5:38:8A:B7:30:1B:1B:6E:D4:7A:E6:45:25:3A:6F:9F:1A:27:61
comodoaaaservicesroot, Aug 4, 2018, trustedCertEntry,
Certificate fingerprint (SHA1): D1:EB:23:A4:6D:17:D6:8F:D9:25:64:C2:F1:F1:60:17:64:D8:E3:49
digicertglobalrootg2, Aug 4, 2018, trustedCertEntry,
Certificate fingerprint (SHA1): DF:3C:24:F9:BF:D6:66:76:1B:26:80:73:FE:06:D1:CC:8D:4F:82:A4
oistewisekeyglobalrootgaca, Aug 4, 2018, trustedCertEntry,
Certificate fingerprint (SHA1): 59:22:A1:E1:5A:EA:16:35:21:F8:98:39:6A:46:46:B0:44:1B:0F:A9
dstrootcax3, Aug 4, 2018, trustedCertEntry,
Certificate fingerprint (SHA1): DA:C9:02:4F:54:D8:F6:DF:94:93:5F:B1:73:26:38:CA:6A:D7:7C:13
certigna, Aug 4, 2018, trustedCertEntry,
Certificate fingerprint (SHA1): B1:2E:13:63:45:86:A4:6F:1A:B2:60:68:37:58:2D:C4:AC:FD:94:97
digicerthighassuranceevrootca, Aug 4, 2018, trustedCertEntry,
Certificate fingerprint (SHA1): 5F:B7:EE:06:33:E2:59:DB:AD:0C:4C:9A:E6:D3:8F:1A:61:C7:DC:25
chambersofcommerceroot-2008, Aug 4, 2018, trustedCertEntry,
Certificate fingerprint (SHA1): 78:6A:74:AC:76:AB:14:7F:9C:6A:30:50:BA:9E:A8:7E:FE:9A:CE:3C
soneraclass2rootca, Aug 4, 2018, trustedCertEntry,
Certificate fingerprint (SHA1): 37:F7:6D:E6:07:7C:90:C5:B1:3E:93:1A:B7:41:10:B4:F2:E4:9A:27
usertrustrsacertificationauthority, Aug 4, 2018, trustedCertEntry,
Certificate fingerprint (SHA1): 2B:8F:1B:57:33:0D:BB:A2:D0:7A:6C:51:F7:0E:E9:0D:DA:B9:AD:8E
geotrustuniversalca, Aug 4, 2018, trustedCertEntry,
Certificate fingerprint (SHA1): E6:21:F3:35:43:79:05:9A:4B:68:30:9D:8A:2F:74:22:15:87:EC:79
certsignrootca, Aug 4, 2018, trustedCertEntry,
Certificate fingerprint (SHA1): FA:B7:EE:36:97:26:62:FB:2D:B0:2A:F6:BF:03:FD:E8:7C:4B:2F:9B
amazonrootca4, Aug 4, 2018, trustedCertEntry,
Certificate fingerprint (SHA1): F6:10:84:07:D6:F8:BB:67:98:0C:C2:E2:44:C2:EB:AE:1C:EF:63:BE
amazonrootca3, Aug 4, 2018, trustedCertEntry,
Certificate fingerprint (SHA1): 0D:44:DD:8C:3C:8C:1A:1A:58:75:64:81:E9:0F:2E:2A:FF:B3:D2:6E
amazonrootca2, Aug 4, 2018, trustedCertEntry,
Certificate fingerprint (SHA1): 5A:8C:EF:45:D7:A6:98:59:76:7A:8C:8B:44:96:B5:78:CF:47:4B:1A
verisignuniversalrootcertificationauthority, Aug 4, 2018, trustedCertEntry,
Certificate fingerprint (SHA1): 36:79:CA:35:66:87:72:30:4D:30:A5:FB:87:3B:0F:A7:7B:B7:0D:54
trustcorrootcertca-2, Aug 4, 2018, trustedCertEntry,
Certificate fingerprint (SHA1): B8:BE:6D:CB:56:F1:55:B9:63:D4:12:CA:4E:06:34:C7:94:B2:1C:C0
amazonrootca1, Aug 4, 2018, trustedCertEntry,
Certificate fingerprint (SHA1): 8D:A7:F9:65:EC:5E:FC:37:91:0F:1C:6E:59:FD:C1:CC:6A:6E:DE:16
trustcorrootcertca-1, Aug 4, 2018, trustedCertEntry,
Certificate fingerprint (SHA1): FF:BD:CD:E7:82:C8:43:5E:3C:6F:26:86:5C:CA:A8:3A:45:5B:C3:0A
ssl.comrootcertificationauthorityecc, Aug 4, 2018, trustedCertEntry,
Certificate fingerprint (SHA1): C3:19:7C:39:24:E6:54:AF:1B:C4:AB:20:95:7A:E2:C3:0E:13:02:6A
ssl.comrootcertificationauthorityrsa, Aug 4, 2018, trustedCertEntry,
Certificate fingerprint (SHA1): B7:AB:33:08:D1:EA:44:77:BA:14:80:12:5A:6F:BD:A9:36:49:0C:BB
d-trustrootclass3ca2ev2009, Aug 4, 2018, trustedCertEntry,
Certificate fingerprint (SHA1): 96:C9:1B:0B:95:B4:10:98:42:FA:D0:D8:22:79:FE:60:FA:B9:16:83
networksolutionscertificateauthority, Aug 4, 2018, trustedCertEntry,
Certificate fingerprint (SHA1): 74:F8:A3:C3:EF:E7:B3:90:06:4B:83:90:3C:21:64:60:20:E5:DF:CE
affirmtrustnetworking, Aug 4, 2018, trustedCertEntry,
Certificate fingerprint (SHA1): 29:36:21:02:8B:20:ED:02:F5:66:C5:32:D1:D6:ED:90:9F:45:00:2F
deutschetelekomrootca2, Aug 4, 2018, trustedCertEntry,
Certificate fingerprint (SHA1): 85:A4:08:C0:9C:19:3E:5D:51:58:7D:CD:D6:13:30:FD:8C:DE:37:BF
globalsigneccrootca-r5, Aug 4, 2018, trustedCertEntry,
Certificate fingerprint (SHA1): 1F:24:C6:30:CD:A4:18:EF:20:69:FF:AD:4F:DD:5F:46:3A:1B:69:AA
globalsigneccrootca-r4, Aug 4, 2018, trustedCertEntry,
Certificate fingerprint (SHA1): 69:69:56:2E:40:80:F4:24:A1:E7:19:9F:14:BA:F3:EE:58:AB:6A:BB
szafirrootca2, Aug 4, 2018, trustedCertEntry,
Certificate fingerprint (SHA1): E2:52:FA:95:3F:ED:DB:24:60:BD:6E:28:F3:9C:CC:CF:5E:B3:3F:DE
globalsignrootca-r3, Aug 4, 2018, trustedCertEntry,
Certificate fingerprint (SHA1): D6:9B:56:11:48:F0:1C:77:C5:45:78:C1:09:26:DF:5B:85:69:76:AD
globalsignrootca-r2, Aug 4, 2018, trustedCertEntry,
Certificate fingerprint (SHA1): 75:E0:AB:B6:13:85:12:27:1C:04:F8:5F:DD:DE:38:E4:B7:24:2E:FE
buypassclass3rootca, Aug 4, 2018, trustedCertEntry,
Certificate fingerprint (SHA1): DA:FA:F7:FA:66:84:EC:06:8F:14:50:BD:C7:C2:81:A5:BC:A9:64:57
comodorsacertificationauthority, Aug 4, 2018, trustedCertEntry,
Certificate fingerprint (SHA1): AF:E5:D2:44:A8:D1:19:42:30:FF:47:9F:E2:F8:97:BB:CD:7A:8C:B4
securitycommunicationrootca2, Aug 4, 2018, trustedCertEntry,
Certificate fingerprint (SHA1): 5F:3B:8C:F2:F8:10:B3:7D:78:B4:CE:EC:19:19:C3:73:34:B9:C7:74
starfieldclass2ca, Aug 4, 2018, trustedCertEntry,
Certificate fingerprint (SHA1): AD:7E:1C:28:B0:64:EF:8F:60:03:40:20:14:C3:D0:E3:37:0E:B5:8A
actalisauthenticationrootca, Aug 4, 2018, trustedCertEntry,
Certificate fingerprint (SHA1): F3:73:B3:87:06:5A:28:84:8A:F2:F3:4A:CE:19:2B:DD:C7:8E:9C:AC
cfcaevroot, Aug 4, 2018, trustedCertEntry,
Certificate fingerprint (SHA1): E2:B8:29:4B:55:84:AB:6B:58:C2:90:46:6C:AC:3F:B8:39:8F:84:83
digicerttrustedrootg4, Aug 4, 2018, trustedCertEntry,
Certificate fingerprint (SHA1): DD:FB:16:CD:49:31:C9:73:A2:03:7D:3F:C8:3A:4D:7D:77:5D:05:E4
certumtrustednetworkca2, Aug 4, 2018, trustedCertEntry,
Certificate fingerprint (SHA1): D3:DD:48:3E:2B:BF:4C:05:E8:AF:10:F5:FA:76:26:CF:D3:DC:30:92
entrustrootcertificationauthority-g2, Aug 4, 2018, trustedCertEntry,
Certificate fingerprint (SHA1): 8C:F4:27:FD:79:0C:3A:D1:66:06:8D:E8:1E:57:EF:BB:93:22:72:D4
taiwangrca, Aug 4, 2018, trustedCertEntry,
Certificate fingerprint (SHA1): F4:8B:11:BF:DE:AB:BE:94:54:20:71:E6:41:DE:6B:BE:88:2B:40:B9
hellenicacademicandresearchinstitutionseccrootca2015, Aug 4, 2018, trustedCertEntry,
Certificate fingerprint (SHA1): 9F:F1:71:8D:92:D5:9A:F3:7D:74:97:B4:BC:6F:84:68:0B:BA:B6:66
twcarootcertificationauthority, Aug 4, 2018, trustedCertEntry,
Certificate fingerprint (SHA1): CF:9E:87:6D:D3:EB:FC:42:26:97:A3:B5:A3:7A:A0:76:A9:06:23:48
certplusrootcag2, Aug 4, 2018, trustedCertEntry,
Certificate fingerprint (SHA1): 4F:65:8E:1F:E9:06:D8:28:02:E9:54:47:41:C9:54:25:5D:69:CC:1A
twcaglobalrootca, Aug 4, 2018, trustedCertEntry,
Certificate fingerprint (SHA1): 9C:BB:48:53:F6:A4:F6:D3:52:A4:E8:32:52:55:60:13:F5:AD:AF:65
certplusrootcag1, Aug 4, 2018, trustedCertEntry,
Certificate fingerprint (SHA1): 22:FD:D0:B7:FD:A2:4E:0D:AC:49:2C:A0:AC:A6:7B:6A:1F:E3:F7:66
geotrustuniversalca2, Aug 4, 2018, trustedCertEntry,
Certificate fingerprint (SHA1): 37:9A:19:7B:41:85:45:35:0C:A6:03:69:F3:3C:2E:AF:47:4F:20:79
thawteprimaryrootca-g3, Aug 4, 2018, trustedCertEntry,
Certificate fingerprint (SHA1): F1:8B:53:8D:1B:E9:03:B6:A6:F0:56:43:5B:17:15:89:CA:F3:6B:F2
thawteprimaryrootca-g2, Aug 4, 2018, trustedCertEntry,
Certificate fingerprint (SHA1): AA:DB:BC:22:23:8F:C4:01:A1:27:BB:38:DD:F4:1D:DB:08:9E:F0:12
baltimorecybertrustroot, Aug 4, 2018, trustedCertEntry,
Certificate fingerprint (SHA1): D4:DE:20:D0:5E:66:FC:53:FE:1A:50:88:2C:78:DB:28:52:CA:E4:74
buypassclass2rootca, Aug 4, 2018, trustedCertEntry,
Certificate fingerprint (SHA1): 49:0A:75:74:DE:87:0A:47:FE:58:EE:F6:C7:6B:EB:C6:0B:12:40:99
digicertassuredidrootg3, Aug 4, 2018, trustedCertEntry,
Certificate fingerprint (SHA1): F5:17:A2:4F:9A:48:C6:C9:F8:A2:00:26:9F:DC:0F:48:2C:AB:30:89
certumtrustednetworkca, Aug 4, 2018, trustedCertEntry,
Certificate fingerprint (SHA1): 07:E0:32:E0:20:B7:2C:3F:19:2F:06:28:A2:59:3A:19:A7:0F:06:9E
geotrustprimarycertificationauthority-g3, Aug 4, 2018, trustedCertEntry,
Certificate fingerprint (SHA1): 03:9E:ED:B8:0B:E7:A0:3C:69:53:89:3B:20:D2:D9:32:3A:4C:2A:FD
digicertassuredidrootg2, Aug 4, 2018, trustedCertEntry,
Certificate fingerprint (SHA1): A1:4B:48:D9:43:EE:0A:0E:40:90:4F:3C:E0:A4:C0:91:93:51:5D:3F
geotrustprimarycertificationauthority-g2, Aug 4, 2018, trustedCertEntry,
Certificate fingerprint (SHA1): 8D:17:84:D5:37:F3:03:7D:EC:70:FE:57:8B:51:9A:99:E6:10:D7:B0
isrgrootx1, Aug 4, 2018, trustedCertEntry,
Certificate fingerprint (SHA1): CA:BD:2A:79:A1:07:6A:31:F2:1D:25:36:35:CB:03:9D:43:29:A5:E8
ec-acc, Aug 4, 2018, trustedCertEntry,
Certificate fingerprint (SHA1): 28:90:3A:63:5B:52:80:FA:E6:77:4C:0B:6D:A7:D6:BA:A6:4A:F2:E8
ssl.comevrootcertificationauthorityecc, Aug 4, 2018, trustedCertEntry,
Certificate fingerprint (SHA1): 4C:DD:51:A3:D1:F5:20:32:14:B0:C6:C5:32:23:03:91:C7:46:42:6D
certplusclass2primaryca, Aug 4, 2018, trustedCertEntry,
Certificate fingerprint (SHA1): 74:20:74:41:72:9C:DD:92:EC:79:31:D8:23:10:8D:C2:81:92:E2:BB
globalchambersignroot-2008, Aug 4, 2018, trustedCertEntry,
Certificate fingerprint (SHA1): 4A:BD:EE:EC:95:0D:35:9C:89:AE:C7:52:A1:2C:5B:29:F6:D6:AA:0C
digicertglobalrootca, Aug 4, 2018, trustedCertEntry,
Certificate fingerprint (SHA1): A8:98:5D:3A:65:E5:E5:C4:B2:D7:D6:6D:40:C6:DD:2F:B1:9C:54:36
d-trustrootclass3ca22009, Aug 4, 2018, trustedCertEntry,
Certificate fingerprint (SHA1): 58:E8:AB:B0:36:15:33:FB:80:F7:9B:1B:6D:29:D3:FF:8D:5F:00:F0
starfieldservicesrootcertificateauthority-g2, Aug 4, 2018, trustedCertEntry,
Certificate fingerprint (SHA1): 92:5A:8F:8D:2C:6D:04:E0:66:5F:59:6A:FF:22:D8:63:E8:25:6F:3F
thawteprimaryrootca, Aug 4, 2018, trustedCertEntry,
Certificate fingerprint (SHA1): 91:C6:D6:EE:3E:8A:C8:63:84:E5:48:C2:99:29:5C:75:6C:81:7B:81
atostrustedroot2011, Aug 4, 2018, trustedCertEntry,
Certificate fingerprint (SHA1): 2B:B1:F5:3E:55:0C:1D:C5:F1:D4:E6:B7:6A:46:4B:55:06:02:AC:21
luxtrustglobalroot2, Aug 4, 2018, trustedCertEntry,
Certificate fingerprint (SHA1): 1E:0E:56:19:0A:D1:8B:25:98:B2:04:44:FF:66:8A:04:17:99:5F:3F
geotrustglobalca, Aug 4, 2018, trustedCertEntry,
Certificate fingerprint (SHA1): DE:28:F4:A4:FF:E5:B9:2F:A3:C5:03:D1:A3:49:A7:F9:96:2A:82:12
visaecommerceroot, Aug 4, 2018, trustedCertEntry,
Certificate fingerprint (SHA1): 70:17:9B:86:8C:00:A4:FA:60:91:52:22:3F:9F:3E:32:BD:E0:05:62
quovadisrootca, Aug 4, 2018, trustedCertEntry,
Certificate fingerprint (SHA1): DE:3F:40:BD:50:93:D3:9B:6C:60:F6:DA:BC:07:62:01:00:89:76:C9
identrustcommercialrootca1, Aug 4, 2018, trustedCertEntry,
Certificate fingerprint (SHA1): DF:71:7E:AA:4A:D9:4E:C9:55:84:99:60:2D:48:DE:5F:BC:F0:3A:25
staatdernederlandenevrootca, Aug 4, 2018, trustedCertEntry,
Certificate fingerprint (SHA1): 76:E2:7E:C1:4F:DB:82:C1:C0:A6:75:B5:05:BE:3D:29:B4:ED:DB:BB
tubitakkamusmsslkoksertifikasi-surum1, Aug 4, 2018, trustedCertEntry,
Certificate fingerprint (SHA1): 31:43:64:9B:EC:CE:27:EC:ED:3A:3F:0B:8F:0D:E4:E8:91:DD:EE:CA
trustcoreca-1, Aug 4, 2018, trustedCertEntry,
Certificate fingerprint (SHA1): 58:D1:DF:95:95:67:6B:63:C0:F0:5B:1C:17:4D:8B:84:0B:C8:78:BD
securitycommunicationrootca, Aug 4, 2018, trustedCertEntry,
Certificate fingerprint (SHA1): 36:B1:2B:49:F9:81:9E:D7:4C:9E:BC:38:0F:C6:56:8F:5D:AC:B2:F7
comodocertificationauthority, Aug 4, 2018, trustedCertEntry,
Certificate fingerprint (SHA1): 66:31:BF:9E:F7:4F:9E:B6:C9:D5:A6:0C:BA:6A:BE:D1:F7:BD:EF:7B
verisignclass3publicprimarycertificationauthority-g5, Aug 4, 2018, trustedCertEntry,
Certificate fingerprint (SHA1): 4E:B6:D5:78:49:9B:1C:CF:5F:58:1E:AD:56:BE:3D:9B:67:44:A5:E5
xrampglobalcaroot, Aug 4, 2018, trustedCertEntry,
Certificate fingerprint (SHA1): B8:01:86:D1:EB:9C:86:A5:41:04:CF:30:54:F3:4C:52:B7:E5:58:C6
verisignclass3publicprimarycertificationauthority-g4, Aug 4, 2018, trustedCertEntry,
Certificate fingerprint (SHA1): 22:D5:D8:DF:8F:02:31:D1:8D:F7:9D:B7:CF:8A:2D:64:C9:3F:6C:3A
quovadisrootca3g3, Aug 4, 2018, trustedCertEntry,
Certificate fingerprint (SHA1): 48:12:BD:92:3C:A8:C4:39:06:E7:30:6D:27:96:E6:A4:CF:22:2E:7D
verisignclass3publicprimarycertificationauthority-g3, Aug 4, 2018, trustedCertEntry,
Certificate fingerprint (SHA1): 13:2D:0D:45:53:4B:69:97:CD:B2:D5:C3:39:E2:55:76:60:9B:5C:C6
securesignrootca11, Aug 4, 2018, trustedCertEntry,
Certificate fingerprint (SHA1): 3B:C4:9F:48:F8:F3:73:A0:9C:1E:BD:F8:5B:B1:C3:65:C7:D8:11:B3
affirmtrustpremium, Aug 4, 2018, trustedCertEntry,
Certificate fingerprint (SHA1): D8:A6:33:2C:E0:03:6F:B1:85:F6:63:4F:7D:6A:06:65:26:32:28:27
globalsignrootca, Aug 4, 2018, trustedCertEntry,
Certificate fingerprint (SHA1): B1:BC:96:8B:D4:F4:9D:62:2A:A8:9A:81:F2:15:01:52:A4:1D:82:9C
quovadisrootca2g3, Aug 4, 2018, trustedCertEntry,
Certificate fingerprint (SHA1): 09:3C:61:F3:8B:8B:DC:7D:55:DF:75:38:02:05:00:E1:25:F5:C8:36
geotrustprimarycertificationauthority, Aug 4, 2018, trustedCertEntry,
Certificate fingerprint (SHA1): 32:3C:11:8E:1B:F7:B8:B6:52:54:E2:E2:10:0D:D6:02:90:37:F0:96
affirmtrustpremiumecc, Aug 4, 2018, trustedCertEntry,
Certificate fingerprint (SHA1): B8:23:6B:00:2F:1D:16:86:53:01:55:6C:11:A4:37:CA:EB:FF:C3:BB
quovadisrootca1g3, Aug 4, 2018, trustedCertEntry,
Certificate fingerprint (SHA1): 1B:8E:EA:57:96:29:1A:C9:39:EA:B8:0A:81:1A:73:73:C0:93:79:67
hongkongpostrootca1, Aug 4, 2018, trustedCertEntry,
Certificate fingerprint (SHA1): D6:DA:A8:20:8D:09:D2:15:4D:24:B5:2F:CB:34:6E:B2:58:B2:8A:58
usertrustecccertificationauthority, Aug 4, 2018, trustedCertEntry,
Certificate fingerprint (SHA1): D1:CB:CA:5D:B2:D5:2A:7F:69:3B:67:4D:E5:F0:5A:1D:0C:95:7D:F0
cybertrustglobalroot, Aug 4, 2018, trustedCertEntry,
Certificate fingerprint (SHA1): 5F:43:E5:B1:BF:F8:78:8C:AC:1C:C7:CA:4A:9A:C6:22:2B:CC:34:C6
godaddyclass2ca, Aug 4, 2018, trustedCertEntry,
Certificate fingerprint (SHA1): 27:96:BA:E6:3F:18:01:E2:77:26:1B:A0:D7:77:70:02:8F:20:EE:E4
microsece-szignorootca2009, Aug 4, 2018, trustedCertEntry,
Certificate fingerprint (SHA1): 89:DF:74:FE:5C:F4:0F:4A:80:F9:E3:37:7D:54:DA:91:E1:01:31:8E
hellenicacademicandresearchinstitutionsrootca2015, Aug 4, 2018, trustedCertEntry,
Certificate fingerprint (SHA1): 01:0C:06:95:A6:98:19:14:FF:BF:5F:C6:B0:B6:95:EA:29:E9:12:A6
hellenicacademicandresearchinstitutionsrootca2011, Aug 4, 2018, trustedCertEntry,
Certificate fingerprint (SHA1): FE:45:65:9B:79:03:5B:98:A1:61:B5:51:2E:AC:DA:58:09:48:22:4D
godaddyrootcertificateauthority-g2, Aug 4, 2018, trustedCertEntry,
Certificate fingerprint (SHA1): 47:BE:AB:C9:22:EA:E8:0E:78:78:34:62:A7:9F:45:C2:54:FD:E6:8B
trustisfpsrootca, Aug 4, 2018, trustedCertEntry,
Certificate fingerprint (SHA1): 3B:C0:38:0B:33:C3:F6:A6:0C:86:15:22:93:D9:DF:F5:4B:81:C0:04
epkirootcertificationauthority, Aug 4, 2018, trustedCertEntry,
Certificate fingerprint (SHA1): 67:65:0D:F1:7E:8E:7E:5B:82:40:A4:F4:56:4B:CF:E2:3D:69:C6:F0
starfieldrootcertificateauthority-g2, Aug 4, 2018, trustedCertEntry,
Certificate fingerprint (SHA1): B5:1C:06:7C:EE:2B:0C:3D:F8:55:AB:2D:92:F4:FE:39:D4:E7:0F:0E
ssl.comevrootcertificationauthorityrsar2, Aug 4, 2018, trustedCertEntry,
Certificate fingerprint (SHA1): 74:3A:F0:52:9B:D0:32:A0:F4:4A:83:CD:D4:BA:A9:7B:7C:2E:C4:9A
{code}
As you can see the list of Subject DNs provided by the OS is enormous. If you add a handmade certificate to your app, with a short Subject DN, you should be fine. However, OpenShift generated certificates are a bit longer ([see this piece of the logs|https://gist.github.com/slaskawi/b6477fe3cd65890c879cfe6f95359450#fi...]) and you you get an error. Of course, I could trim the list down manually (by using {{keytool}}) or even remove {{/etc/pki/ca-trust/extracted/java/cacerts}} altogether but I guess this is a valid situation we have here and it's the WF that should be monitoring the length of the payload it sends (especially if there's a limit set by the RFC).
It is worth to mention that this happen only on client auth turned on. Only in this case, the server sends a list of CAs.
I hope this answers your questions [~iankko] and [~dlofthouse] :)
> 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