[JBoss JIRA] (JGRP-2300) DNS_PING in AWS ECS cannot cluster with dynamic port mappings
by Bela Ban (Jira)
[ https://issues.jboss.org/browse/JGRP-2300?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-2300:
---------------------------
Fix Version/s: 4.0.16
> DNS_PING in AWS ECS cannot cluster with dynamic port mappings
> -------------------------------------------------------------
>
> Key: JGRP-2300
> URL: https://issues.jboss.org/browse/JGRP-2300
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 4.0.16
> Environment: AWS ECS Cluster with DNS based service discovery using jboss/keycloak:latest containers
> Reporter: Eric Thompson
> Assignee: Bela Ban
> Priority: Critical
> Fix For: 4.0.16
>
>
> When running an ECS cluster with jboss/keycloak:latest containers dynamic port mapping of all ports is required to allow more than one container to run per EC2 instance. Using SRV based service discovery records will allow each node to find the rest of the nodes, but when a discovery request is sent the receiving node sees the sender as IP:7600 instead of the dynamic port. It then sees this as a "new" node and tries to send discovery requests to it. And somehow it is also getting node IDs and trying to send requests to those!
> See the following log, there are only 4 actual nodes and the each have a different 5 digit port number:
> {code}
> ### Service discovery with dynamic port mapping
> 2018-10-10 20:17:44,178 DEBUG [org.jgroups.protocols.dns.DNS_PING] (thread-240,ejb,17081c624290) Performing discovery of the following hosts [10.42.3.44:7600, 10.42.3.56:32949, 10.42.3.56:32951, 10.42.3.44:32954, c5b479b7b6d5, 10.42.3.44:32952, 10.42.3.56:7600, 17081c624290, 63976b7fae70, 557cbd7891a2]
> 2018-10-10 20:17:44,178 DEBUG [org.jgroups.protocols.dns.DNS_PING] (thread-240,ejb,17081c624290) 17081c624290: sending discovery request to 10.42.3.44:7600
> 2018-10-10 20:17:44,179 DEBUG [org.jgroups.protocols.dns.DNS_PING] (thread-240,ejb,17081c624290) 17081c624290: sending discovery request to 10.42.3.56:32949
> 2018-10-10 20:17:44,179 DEBUG [org.jgroups.protocols.dns.DNS_PING] (thread-240,ejb,17081c624290) 17081c624290: sending discovery request to 10.42.3.56:32951
> 2018-10-10 20:17:44,180 DEBUG [org.jgroups.protocols.dns.DNS_PING] (thread-240,ejb,17081c624290) 17081c624290: sending discovery request to 10.42.3.44:32954
> 2018-10-10 20:17:44,181 DEBUG [org.jgroups.protocols.dns.DNS_PING] (thread-240,ejb,17081c624290) 17081c624290: sending discovery request to c5b479b7b6d5
> 2018-10-10 20:17:44,181 DEBUG [org.jgroups.protocols.dns.DNS_PING] (thread-240,ejb,17081c624290) 17081c624290: sending discovery request to 10.42.3.44:32952
> 2018-10-10 20:17:44,181 DEBUG [org.jgroups.protocols.dns.DNS_PING] (thread-240,ejb,17081c624290) 17081c624290: sending discovery request to 10.42.3.56:7600
> 2018-10-10 20:17:44,182 DEBUG [org.jgroups.protocols.dns.DNS_PING] (thread-237,ejb,17081c624290) Received discovery from: 17081c624290, IP: 10.42.3.56:7600
> 2018-10-10 20:17:44,182 DEBUG [org.jgroups.protocols.dns.DNS_PING] (thread-240,ejb,17081c624290) 17081c624290: sending discovery request to 17081c624290
> 2018-10-10 20:17:44,182 DEBUG [org.jgroups.protocols.dns.DNS_PING] (thread-238,ejb,17081c624290) Received discovery from: 17081c624290, IP: 10.42.3.56:7600
> 2018-10-10 20:17:44,182 DEBUG [org.jgroups.protocols.dns.DNS_PING] (thread-240,ejb,17081c624290) 17081c624290: sending discovery request to 63976b7fae70
> 2018-10-10 20:17:44,183 DEBUG [org.jgroups.protocols.dns.DNS_PING] (thread-240,ejb,17081c624290) 17081c624290: sending discovery request to 557cbd7891a2
> 2018-10-10 20:17:44,187 WARN [org.jgroups.protocols.TCP] (TQ-Bundler-7,ejb,17081c624290) JGRP000032: 17081c624290: no physical address for c5b479b7b6d5, dropping message
> {code}
> This code seems to be part of the problem in this case: https://github.com/belaban/JGroups/blob/87d15ec848aa3d482ae792ef152f7e36e...
> See that code uses the incoming address and adds it to the discocvered_hosts, but those addresses are ALWAYS inaccurate in this case.
> Because this is what the recipient of the service discovery request sees (ie: all the ports are the default 7600):
> {code}
> 2018-10-10 20:35:15,229 DEBUG [org.jgroups.protocols.dns.DNS_PING] (thread-350,ejb,17081c624290) Received discovery from: 63976b7fae70, IP: 10.42.3.44:7600
> 2018-10-10 20:35:15,231 DEBUG [org.jgroups.protocols.dns.DNS_PING] (thread-350,ejb,17081c624290) Received discovery from: 63976b7fae70, IP: 10.42.3.44:7600
> 2018-10-10 20:35:15,232 DEBUG [org.jgroups.protocols.dns.DNS_PING] (thread-397,ejb,17081c624290) Received discovery from: 63976b7fae70, IP: 10.42.3.44:7600
> 2018-10-10 20:35:15,233 DEBUG [org.jgroups.protocols.dns.DNS_PING] (thread-350,ejb,17081c624290) Received discovery from: 63976b7fae70, IP: 10.42.3.44:7600
> 2018-10-10 20:35:17,234 DEBUG [org.jgroups.protocols.dns.DNS_PING] (thread-350,ejb,17081c624290) Received discovery from: 63976b7fae70, IP: 10.42.3.44:7600
> 2018-10-10 20:35:17,236 DEBUG [org.jgroups.protocols.dns.DNS_PING] (thread-350,ejb,17081c624290) Received discovery from: 63976b7fae70, IP: 10.42.3.44:7600
> 2018-10-10 20:35:17,238 DEBUG [org.jgroups.protocols.dns.DNS_PING] (thread-397,ejb,17081c624290) Received discovery from: 63976b7fae70, IP: 10.42.3.44:7600
> 2018-10-10 20:35:17,238 DEBUG [org.jgroups.protocols.dns.DNS_PING] (thread-350,ejb,17081c624290) Received discovery from: 63976b7fae70, IP: 10.42.3.44:7600
> 2018-10-10 20:35:19,239 DEBUG [org.jgroups.protocols.dns.DNS_PING] (thread-350,ejb,17081c624290) Received discovery from: 63976b7fae70, IP: 10.42.3.44:7600
> 2018-10-10 20:35:19,240 DEBUG [org.jgroups.protocols.dns.DNS_PING] (thread-350,ejb,17081c624290) Received discovery from: 63976b7fae70, IP: 10.42.3.44:7600
> 2018-10-10 20:35:19,242 DEBUG [org.jgroups.protocols.dns.DNS_PING] (thread-237,ejb,17081c624290) Received discovery from: 63976b7fae70, IP: 10.42.3.44:7600
> 2018-10-10 20:35:19,243 DEBUG [org.jgroups.protocols.dns.DNS_PING] (thread-350,ejb,17081c624290) Received discovery from: 63976b7fae70, IP: 10.42.3.44:7600
> 2018-10-10 20:35:21,246 DEBUG [org.jgroups.protocols.dns.DNS_PING] (thread-350,ejb,17081c624290) Received discovery from: 63976b7fae70, IP: 10.42.3.44:7600
> 2018-10-10 20:35:21,247 DEBUG [org.jgroups.protocols.dns.DNS_PING] (thread-350,ejb,17081c624290) Received discovery from: 63976b7fae70, IP: 10.42.3.44:7600
> 2018-10-10 20:35:21,253 DEBUG [org.jgroups.protocols.dns.DNS_PING] (thread-237,ejb,17081c624290) Received discovery from: 63976b7fae70, IP: 10.42.3.44:7600
> 2018-10-10 20:35:21,253 DEBUG [org.jgroups.protocols.dns.DNS_PING] (thread-350,ejb,17081c624290) Received discovery from: 63976b7fae70, IP: 10.42.3.44:7600
> 2018-10-10 20:35:23,247 DEBUG [org.jgroups.protocols.dns.DNS_PING] (thread-350,ejb,17081c624290) Received discovery from: 63976b7fae70, IP: 10.42.3.44:7600
> 2018-10-10 20:35:23,249 DEBUG [org.jgroups.protocols.dns.DNS_PING] (thread-350,ejb,17081c624290) Received discovery from: 63976b7fae70, IP: 10.42.3.44:7600
> 2018-10-10 20:35:23,251 DEBUG [org.jgroups.protocols.dns.DNS_PING] (thread-237,ejb,17081c624290) Received discovery from: 63976b7fae70, IP: 10.42.3.44:7600
> 2018-10-10 20:35:23,251 DEBUG [org.jgroups.protocols.dns.DNS_PING] (thread-350,ejb,17081c624290) Received discovery from: 63976b7fae70, IP: 10.42.3.44:7600
> 2018-10-10 20:35:25,252 DEBUG [org.jgroups.protocols.dns.DNS_PING] (thread-237,ejb,17081c624290) Received discovery from: 63976b7fae70, IP: 10.42.3.44:7600
> 2018-10-10 20:35:25,253 DEBUG [org.jgroups.protocols.dns.DNS_PING] (thread-237,ejb,17081c624290) Received discovery from: 63976b7fae70, IP: 10.42.3.44:7600
> 2018-10-10 20:35:25,255 DEBUG [org.jgroups.protocols.dns.DNS_PING] (thread-237,ejb,17081c624290) Received discovery from: 63976b7fae70, IP: 10.42.3.44:7600
> 2018-10-10 20:35:25,256 DEBUG [org.jgroups.protocols.dns.DNS_PING] (thread-237,ejb,17081c624290) Received discovery from: 63976b7fae70, IP: 10.42.3.44:7600
> {code}
> In this state the cluster never seems to work properly and the Keycloak interface breaks in many frustrating ways.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 7 months
[JBoss JIRA] (WFLY-11171) Test in Elytron integration tests rely on the BatchPermission in wildfly-jberet
by Darran Lofthouse (Jira)
[ https://issues.jboss.org/browse/WFLY-11171?page=com.atlassian.jira.plugin... ]
Darran Lofthouse commented on WFLY-11171:
-----------------------------------------
+1 Java permissions should be considered public API as these need to be granted to the relevant identities meaning they also need to be maintained for compatibility.
> Test in Elytron integration tests rely on the BatchPermission in wildfly-jberet
> -------------------------------------------------------------------------------
>
> Key: WFLY-11171
> URL: https://issues.jboss.org/browse/WFLY-11171
> Project: WildFly
> Issue Type: Bug
> Components: Batch, Test Suite
> Reporter: James Perkins
> Assignee: Cheng Fang
> Priority: Major
>
> Tests in the Elytron integration test suite rely on {{org.wildfly.extension.batch.jberet.deployment.BatchPermission}} which is in private module. This permission should likely be moved to a public JBeret API or a new public API should be create within WildFly that exposes this permission. There is a chance this permission may be required for users.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 7 months
[JBoss JIRA] (WFLY-11154) mod_cluster reports "Starting to drain 1 active sessions from (...) in 0 seconds." even when it waits indefinitely
by Radoslav Husar (Jira)
[ https://issues.jboss.org/browse/WFLY-11154?page=com.atlassian.jira.plugin... ]
Radoslav Husar commented on WFLY-11154:
---------------------------------------
The issue will be resolved with the component upgrade, WFLY-11159.
> mod_cluster reports "Starting to drain 1 active sessions from (...) in 0 seconds." even when it waits indefinitely
> ------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-11154
> URL: https://issues.jboss.org/browse/WFLY-11154
> Project: WildFly
> Issue Type: Enhancement
> Components: mod_cluster
> Affects Versions: 14.0.0.Final, 15.0.0.Alpha1
> Reporter: Jan Kašík
> Assignee: Radoslav Husar
> Priority: Optional
>
> When {{stop}} operation with {{waittime=0}} is called on a mod_cluster node, it wait indefinitely until all sessions time out. However, following line appears in log:
> {code}
> INFO [org.jboss.modcluster] (management-handler-thread - 1) MODCLUSTER000046: Starting to drain 1 active sessions from default-host:/karel in 0 seconds.
> {code}
> This could confuse someone looking into the log -- they would then think,that this operation killed sessions even when it didn't.
> Suggestion: Replace this message with more accurate one.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 7 months
[JBoss JIRA] (ELY-1680) IBM, failing KeyStoreSuiteChild.testGetCertificateChainBinary
by Jiri Ondrusek (Jira)
[ https://issues.jboss.org/browse/ELY-1680?page=com.atlassian.jira.plugin.s... ]
Jiri Ondrusek updated ELY-1680:
-------------------------------
Attachment: ldap-keystore-gen.sh
> IBM, failing KeyStoreSuiteChild.testGetCertificateChainBinary
> -------------------------------------------------------------
>
> Key: ELY-1680
> URL: https://issues.jboss.org/browse/ELY-1680
> Project: WildFly Elytron
> Issue Type: Bug
> Components: Testsuite
> Affects Versions: 1.6.1.Final
> Reporter: Martin Choma
> Priority: Major
> Fix For: 1.7.0.CR3
>
> Attachments: ldap-keystore-gen.sh
>
>
> {code}
> [ERROR] testGetCertificateChainBinary(org.wildfly.security.ldap.KeyStoreSuiteChild) Time elapsed: 0.057 s <<< FAILURE!
> org.junit.ComparisonFailure: expected:<CN=[firefly_binary], OU=Elytron, O=Elyt...> but was:<CN=[localhost], OU=Elytron, O=Elyt...>
> at org.wildfly.security.ldap.KeyStoreSuiteChild.testGetCertificateChainBinary(KeyStoreSuiteChild.java:136)
> at org.wildfly.security.ldap.DirContextFactoryRule$1.evaluate(DirContextFactoryRule.java:218)
> {code}
> If I switch order of certificates in chain, then test passes.
> {code}
> diff --git a/src/test/java/org/wildfly/security/ldap/KeyStoreSuiteChild.java b/src/test/java/org/wildfly/security/ldap/KeyStoreSuiteChild.java
> index d8095867a..cda635beb 100644
> --- a/src/test/java/org/wildfly/security/ldap/KeyStoreSuiteChild.java
> +++ b/src/test/java/org/wildfly/security/ldap/KeyStoreSuiteChild.java
> @@ -133,8 +133,8 @@ public class KeyStoreSuiteChild {
> Certificate[] chain = keyStore.getCertificateChain("firefly_binary");
> Assert.assertNotNull(chain);
> Assert.assertEquals(2, chain.length);
> - Assert.assertEquals("CN=firefly_binary, OU=Elytron, O=Elytron, L=Elytron, ST=Elytron, C=UK", ((X509Certificate)chain[0]).getSubjectDN().toString());
> - Assert.assertEquals("CN=localhost, OU=Elytron, O=Elytron, L=Elytron, ST=Elytron, C=UK", ((X509Certificate)chain[1]).getSubjectDN().toString());
> + Assert.assertEquals("CN=firefly_binary, OU=Elytron, O=Elytron, L=Elytron, ST=Elytron, C=UK", ((X509Certificate)chain[1]).getSubjectDN().toString());
> + Assert.assertEquals("CN=localhost, OU=Elytron, O=Elytron, L=Elytron, ST=Elytron, C=UK", ((X509Certificate)chain[0]).getSubjectDN().toString());
> }
> {code}
> -For some reason I want able to debug code with -Dmaven.surefire.debug (Breakpoint was never hit) to find out which calls switch the order.-
> It takes long (5min) for debugger to attach to code.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 7 months
[JBoss JIRA] (ELY-1680) IBM, failing KeyStoreSuiteChild.testGetCertificateChainBinary
by Jiri Ondrusek (Jira)
[ https://issues.jboss.org/browse/ELY-1680?page=com.atlassian.jira.plugin.s... ]
Jiri Ondrusek updated ELY-1680:
-------------------------------
Attachment: (was: server.keystore)
> IBM, failing KeyStoreSuiteChild.testGetCertificateChainBinary
> -------------------------------------------------------------
>
> Key: ELY-1680
> URL: https://issues.jboss.org/browse/ELY-1680
> Project: WildFly Elytron
> Issue Type: Bug
> Components: Testsuite
> Affects Versions: 1.6.1.Final
> Reporter: Martin Choma
> Priority: Major
> Fix For: 1.7.0.CR3
>
> Attachments: ldap-keystore-gen.sh
>
>
> {code}
> [ERROR] testGetCertificateChainBinary(org.wildfly.security.ldap.KeyStoreSuiteChild) Time elapsed: 0.057 s <<< FAILURE!
> org.junit.ComparisonFailure: expected:<CN=[firefly_binary], OU=Elytron, O=Elyt...> but was:<CN=[localhost], OU=Elytron, O=Elyt...>
> at org.wildfly.security.ldap.KeyStoreSuiteChild.testGetCertificateChainBinary(KeyStoreSuiteChild.java:136)
> at org.wildfly.security.ldap.DirContextFactoryRule$1.evaluate(DirContextFactoryRule.java:218)
> {code}
> If I switch order of certificates in chain, then test passes.
> {code}
> diff --git a/src/test/java/org/wildfly/security/ldap/KeyStoreSuiteChild.java b/src/test/java/org/wildfly/security/ldap/KeyStoreSuiteChild.java
> index d8095867a..cda635beb 100644
> --- a/src/test/java/org/wildfly/security/ldap/KeyStoreSuiteChild.java
> +++ b/src/test/java/org/wildfly/security/ldap/KeyStoreSuiteChild.java
> @@ -133,8 +133,8 @@ public class KeyStoreSuiteChild {
> Certificate[] chain = keyStore.getCertificateChain("firefly_binary");
> Assert.assertNotNull(chain);
> Assert.assertEquals(2, chain.length);
> - Assert.assertEquals("CN=firefly_binary, OU=Elytron, O=Elytron, L=Elytron, ST=Elytron, C=UK", ((X509Certificate)chain[0]).getSubjectDN().toString());
> - Assert.assertEquals("CN=localhost, OU=Elytron, O=Elytron, L=Elytron, ST=Elytron, C=UK", ((X509Certificate)chain[1]).getSubjectDN().toString());
> + Assert.assertEquals("CN=firefly_binary, OU=Elytron, O=Elytron, L=Elytron, ST=Elytron, C=UK", ((X509Certificate)chain[1]).getSubjectDN().toString());
> + Assert.assertEquals("CN=localhost, OU=Elytron, O=Elytron, L=Elytron, ST=Elytron, C=UK", ((X509Certificate)chain[0]).getSubjectDN().toString());
> }
> {code}
> -For some reason I want able to debug code with -Dmaven.surefire.debug (Breakpoint was never hit) to find out which calls switch the order.-
> It takes long (5min) for debugger to attach to code.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 7 months
[JBoss JIRA] (ELY-1680) IBM, failing KeyStoreSuiteChild.testGetCertificateChainBinary
by Jiri Ondrusek (Jira)
[ https://issues.jboss.org/browse/ELY-1680?page=com.atlassian.jira.plugin.s... ]
Jiri Ondrusek updated ELY-1680:
-------------------------------
Attachment: (was: server.keystore)
> IBM, failing KeyStoreSuiteChild.testGetCertificateChainBinary
> -------------------------------------------------------------
>
> Key: ELY-1680
> URL: https://issues.jboss.org/browse/ELY-1680
> Project: WildFly Elytron
> Issue Type: Bug
> Components: Testsuite
> Affects Versions: 1.6.1.Final
> Reporter: Martin Choma
> Priority: Major
> Fix For: 1.7.0.CR3
>
> Attachments: ldap-keystore-gen.sh
>
>
> {code}
> [ERROR] testGetCertificateChainBinary(org.wildfly.security.ldap.KeyStoreSuiteChild) Time elapsed: 0.057 s <<< FAILURE!
> org.junit.ComparisonFailure: expected:<CN=[firefly_binary], OU=Elytron, O=Elyt...> but was:<CN=[localhost], OU=Elytron, O=Elyt...>
> at org.wildfly.security.ldap.KeyStoreSuiteChild.testGetCertificateChainBinary(KeyStoreSuiteChild.java:136)
> at org.wildfly.security.ldap.DirContextFactoryRule$1.evaluate(DirContextFactoryRule.java:218)
> {code}
> If I switch order of certificates in chain, then test passes.
> {code}
> diff --git a/src/test/java/org/wildfly/security/ldap/KeyStoreSuiteChild.java b/src/test/java/org/wildfly/security/ldap/KeyStoreSuiteChild.java
> index d8095867a..cda635beb 100644
> --- a/src/test/java/org/wildfly/security/ldap/KeyStoreSuiteChild.java
> +++ b/src/test/java/org/wildfly/security/ldap/KeyStoreSuiteChild.java
> @@ -133,8 +133,8 @@ public class KeyStoreSuiteChild {
> Certificate[] chain = keyStore.getCertificateChain("firefly_binary");
> Assert.assertNotNull(chain);
> Assert.assertEquals(2, chain.length);
> - Assert.assertEquals("CN=firefly_binary, OU=Elytron, O=Elytron, L=Elytron, ST=Elytron, C=UK", ((X509Certificate)chain[0]).getSubjectDN().toString());
> - Assert.assertEquals("CN=localhost, OU=Elytron, O=Elytron, L=Elytron, ST=Elytron, C=UK", ((X509Certificate)chain[1]).getSubjectDN().toString());
> + Assert.assertEquals("CN=firefly_binary, OU=Elytron, O=Elytron, L=Elytron, ST=Elytron, C=UK", ((X509Certificate)chain[1]).getSubjectDN().toString());
> + Assert.assertEquals("CN=localhost, OU=Elytron, O=Elytron, L=Elytron, ST=Elytron, C=UK", ((X509Certificate)chain[0]).getSubjectDN().toString());
> }
> {code}
> -For some reason I want able to debug code with -Dmaven.surefire.debug (Breakpoint was never hit) to find out which calls switch the order.-
> It takes long (5min) for debugger to attach to code.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 7 months
[JBoss JIRA] (ELY-1680) IBM, failing KeyStoreSuiteChild.testGetCertificateChainBinary
by Jiri Ondrusek (Jira)
[ https://issues.jboss.org/browse/ELY-1680?page=com.atlassian.jira.plugin.s... ]
Jiri Ondrusek updated ELY-1680:
-------------------------------
Attachment: server.keystore
> IBM, failing KeyStoreSuiteChild.testGetCertificateChainBinary
> -------------------------------------------------------------
>
> Key: ELY-1680
> URL: https://issues.jboss.org/browse/ELY-1680
> Project: WildFly Elytron
> Issue Type: Bug
> Components: Testsuite
> Affects Versions: 1.6.1.Final
> Reporter: Martin Choma
> Priority: Major
> Fix For: 1.7.0.CR3
>
> Attachments: ldap-keystore-gen.sh
>
>
> {code}
> [ERROR] testGetCertificateChainBinary(org.wildfly.security.ldap.KeyStoreSuiteChild) Time elapsed: 0.057 s <<< FAILURE!
> org.junit.ComparisonFailure: expected:<CN=[firefly_binary], OU=Elytron, O=Elyt...> but was:<CN=[localhost], OU=Elytron, O=Elyt...>
> at org.wildfly.security.ldap.KeyStoreSuiteChild.testGetCertificateChainBinary(KeyStoreSuiteChild.java:136)
> at org.wildfly.security.ldap.DirContextFactoryRule$1.evaluate(DirContextFactoryRule.java:218)
> {code}
> If I switch order of certificates in chain, then test passes.
> {code}
> diff --git a/src/test/java/org/wildfly/security/ldap/KeyStoreSuiteChild.java b/src/test/java/org/wildfly/security/ldap/KeyStoreSuiteChild.java
> index d8095867a..cda635beb 100644
> --- a/src/test/java/org/wildfly/security/ldap/KeyStoreSuiteChild.java
> +++ b/src/test/java/org/wildfly/security/ldap/KeyStoreSuiteChild.java
> @@ -133,8 +133,8 @@ public class KeyStoreSuiteChild {
> Certificate[] chain = keyStore.getCertificateChain("firefly_binary");
> Assert.assertNotNull(chain);
> Assert.assertEquals(2, chain.length);
> - Assert.assertEquals("CN=firefly_binary, OU=Elytron, O=Elytron, L=Elytron, ST=Elytron, C=UK", ((X509Certificate)chain[0]).getSubjectDN().toString());
> - Assert.assertEquals("CN=localhost, OU=Elytron, O=Elytron, L=Elytron, ST=Elytron, C=UK", ((X509Certificate)chain[1]).getSubjectDN().toString());
> + Assert.assertEquals("CN=firefly_binary, OU=Elytron, O=Elytron, L=Elytron, ST=Elytron, C=UK", ((X509Certificate)chain[1]).getSubjectDN().toString());
> + Assert.assertEquals("CN=localhost, OU=Elytron, O=Elytron, L=Elytron, ST=Elytron, C=UK", ((X509Certificate)chain[0]).getSubjectDN().toString());
> }
> {code}
> -For some reason I want able to debug code with -Dmaven.surefire.debug (Breakpoint was never hit) to find out which calls switch the order.-
> It takes long (5min) for debugger to attach to code.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 7 months
[JBoss JIRA] (ELY-1680) IBM, failing KeyStoreSuiteChild.testGetCertificateChainBinary
by Jiri Ondrusek (Jira)
[ https://issues.jboss.org/browse/ELY-1680?page=com.atlassian.jira.plugin.s... ]
Jiri Ondrusek updated ELY-1680:
-------------------------------
Attachment: server.keystore
> IBM, failing KeyStoreSuiteChild.testGetCertificateChainBinary
> -------------------------------------------------------------
>
> Key: ELY-1680
> URL: https://issues.jboss.org/browse/ELY-1680
> Project: WildFly Elytron
> Issue Type: Bug
> Components: Testsuite
> Affects Versions: 1.6.1.Final
> Reporter: Martin Choma
> Priority: Major
> Fix For: 1.7.0.CR3
>
> Attachments: ldap-keystore-gen.sh
>
>
> {code}
> [ERROR] testGetCertificateChainBinary(org.wildfly.security.ldap.KeyStoreSuiteChild) Time elapsed: 0.057 s <<< FAILURE!
> org.junit.ComparisonFailure: expected:<CN=[firefly_binary], OU=Elytron, O=Elyt...> but was:<CN=[localhost], OU=Elytron, O=Elyt...>
> at org.wildfly.security.ldap.KeyStoreSuiteChild.testGetCertificateChainBinary(KeyStoreSuiteChild.java:136)
> at org.wildfly.security.ldap.DirContextFactoryRule$1.evaluate(DirContextFactoryRule.java:218)
> {code}
> If I switch order of certificates in chain, then test passes.
> {code}
> diff --git a/src/test/java/org/wildfly/security/ldap/KeyStoreSuiteChild.java b/src/test/java/org/wildfly/security/ldap/KeyStoreSuiteChild.java
> index d8095867a..cda635beb 100644
> --- a/src/test/java/org/wildfly/security/ldap/KeyStoreSuiteChild.java
> +++ b/src/test/java/org/wildfly/security/ldap/KeyStoreSuiteChild.java
> @@ -133,8 +133,8 @@ public class KeyStoreSuiteChild {
> Certificate[] chain = keyStore.getCertificateChain("firefly_binary");
> Assert.assertNotNull(chain);
> Assert.assertEquals(2, chain.length);
> - Assert.assertEquals("CN=firefly_binary, OU=Elytron, O=Elytron, L=Elytron, ST=Elytron, C=UK", ((X509Certificate)chain[0]).getSubjectDN().toString());
> - Assert.assertEquals("CN=localhost, OU=Elytron, O=Elytron, L=Elytron, ST=Elytron, C=UK", ((X509Certificate)chain[1]).getSubjectDN().toString());
> + Assert.assertEquals("CN=firefly_binary, OU=Elytron, O=Elytron, L=Elytron, ST=Elytron, C=UK", ((X509Certificate)chain[1]).getSubjectDN().toString());
> + Assert.assertEquals("CN=localhost, OU=Elytron, O=Elytron, L=Elytron, ST=Elytron, C=UK", ((X509Certificate)chain[0]).getSubjectDN().toString());
> }
> {code}
> -For some reason I want able to debug code with -Dmaven.surefire.debug (Breakpoint was never hit) to find out which calls switch the order.-
> It takes long (5min) for debugger to attach to code.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 7 months
[JBoss JIRA] (ELY-1680) IBM, failing KeyStoreSuiteChild.testGetCertificateChainBinary
by Jiri Ondrusek (Jira)
[ https://issues.jboss.org/browse/ELY-1680?page=com.atlassian.jira.plugin.s... ]
Jiri Ondrusek commented on ELY-1680:
------------------------------------
[~fjuma] I've looked into my backup from fixing ELY-1616 and here are some commands :
keytool -exportcert -keystore server.keystore.jks -storepass secret -alias localhost -file ca.crt
keytool -exportcert -keystore server.truststore.jks -storepass secret -alias client -file client.crt
openssl x509 -in ca.crt -inform der -outform pem -out ca.pem
openssl x509 -in client.crt -inform der -outform pem -out client.pem
./ldap-keystore-gen.sh client.pem ca.pem server.keystore.jks > example.ldif
(ldap-keystore-gen.sh is attached)
I suppose that test ldiffs were generate with similar commands, probably with different name then in my example.
[~fjuma] I can look into this issue - may be it will help. If you agree, please let me know.
> IBM, failing KeyStoreSuiteChild.testGetCertificateChainBinary
> -------------------------------------------------------------
>
> Key: ELY-1680
> URL: https://issues.jboss.org/browse/ELY-1680
> Project: WildFly Elytron
> Issue Type: Bug
> Components: Testsuite
> Affects Versions: 1.6.1.Final
> Reporter: Martin Choma
> Priority: Major
> Fix For: 1.7.0.CR3
>
> Attachments: ldap-keystore-gen.sh
>
>
> {code}
> [ERROR] testGetCertificateChainBinary(org.wildfly.security.ldap.KeyStoreSuiteChild) Time elapsed: 0.057 s <<< FAILURE!
> org.junit.ComparisonFailure: expected:<CN=[firefly_binary], OU=Elytron, O=Elyt...> but was:<CN=[localhost], OU=Elytron, O=Elyt...>
> at org.wildfly.security.ldap.KeyStoreSuiteChild.testGetCertificateChainBinary(KeyStoreSuiteChild.java:136)
> at org.wildfly.security.ldap.DirContextFactoryRule$1.evaluate(DirContextFactoryRule.java:218)
> {code}
> If I switch order of certificates in chain, then test passes.
> {code}
> diff --git a/src/test/java/org/wildfly/security/ldap/KeyStoreSuiteChild.java b/src/test/java/org/wildfly/security/ldap/KeyStoreSuiteChild.java
> index d8095867a..cda635beb 100644
> --- a/src/test/java/org/wildfly/security/ldap/KeyStoreSuiteChild.java
> +++ b/src/test/java/org/wildfly/security/ldap/KeyStoreSuiteChild.java
> @@ -133,8 +133,8 @@ public class KeyStoreSuiteChild {
> Certificate[] chain = keyStore.getCertificateChain("firefly_binary");
> Assert.assertNotNull(chain);
> Assert.assertEquals(2, chain.length);
> - Assert.assertEquals("CN=firefly_binary, OU=Elytron, O=Elytron, L=Elytron, ST=Elytron, C=UK", ((X509Certificate)chain[0]).getSubjectDN().toString());
> - Assert.assertEquals("CN=localhost, OU=Elytron, O=Elytron, L=Elytron, ST=Elytron, C=UK", ((X509Certificate)chain[1]).getSubjectDN().toString());
> + Assert.assertEquals("CN=firefly_binary, OU=Elytron, O=Elytron, L=Elytron, ST=Elytron, C=UK", ((X509Certificate)chain[1]).getSubjectDN().toString());
> + Assert.assertEquals("CN=localhost, OU=Elytron, O=Elytron, L=Elytron, ST=Elytron, C=UK", ((X509Certificate)chain[0]).getSubjectDN().toString());
> }
> {code}
> -For some reason I want able to debug code with -Dmaven.surefire.debug (Breakpoint was never hit) to find out which calls switch the order.-
> It takes long (5min) for debugger to attach to code.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 7 months