May 2018 - jboss-jira - Jboss List Archives

[JBoss JIRA] (ELY-1587) X500 principal [CN=client] was not decoded - no values of attribute [2.5.4.3]

by David Lloyd (JIRA)

[ https://issues.jboss.org/browse/ELY-1587?page=com.atlassian.jira.plugin.s... ] David Lloyd commented on ELY-1587: ---------------------------------- Rather than testing with a cert, it might be better to test directly using {{X500PrincipalBuilder}} which should allow arbitrary content. Then that could be aggregated into a certificate using {{X509CertificateBuilder}} if we want to add an end-to-end test. > X500 principal [CN=client] was not decoded - no values of attribute [2.5.4.3] > ----------------------------------------------------------------------------- > > Key: ELY-1587 > URL: https://issues.jboss.org/browse/ELY-1587 > Project: WildFly Elytron > Issue Type: Bug > Components: Certificate Authority, X.500 > Affects Versions: 1.3.2.Final > Reporter: Martin Choma > Priority: Critical > Fix For: 1.3.3.CR1 > > > Debugging revealed certificate use {{utf8String}} representation whereas Elytron is expecting {{printableString}} > In rfc 5280 [1] chapter 4.1.2.4. Issuer there is specified value of ssubject/issuer can be of 5 types > {code} > DirectoryString ::= CHOICE { > teletexString TeletexString (SIZE (1..MAX)), > printableString PrintableString (SIZE (1..MAX)), > universalString UniversalString (SIZE (1..MAX)), > utf8String UTF8String (SIZE (1..MAX)), > bmpString BMPString (SIZE (1..MAX)) } > {code} > However Elytron X500 principal decoder [2] can handle only 2 of them PRINTABLE_STRING_TYPE and IA5_STRING_TYPE (not sure which type of rfc does that match) [2] > Definitely missing {{utf8String}} (my case). Also revise for backward compatibility {{teletexString}}, {{bmpString}} and {{universalString}} > [1] https://www.ietf.org/rfc/rfc5280.txt > [2] https://github.com/wildfly-security/wildfly-elytron/blob/32ff7c17965b3eca... -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-10394) Lookup using remote-naming context does not work in WildFly 13

by David Lloyd (JIRA)

[ https://issues.jboss.org/browse/WFLY-10394?page=com.atlassian.jira.plugin... ] David Lloyd commented on WFLY-10394: ------------------------------------ The PR has not yet been merged. > Lookup using remote-naming context does not work in WildFly 13 > -------------------------------------------------------------- > > Key: WFLY-10394 > URL: https://issues.jboss.org/browse/WFLY-10394 > Project: WildFly > Issue Type: Bug > Components: EJB, Naming > Affects Versions: 13.0.0.Beta1 > Reporter: Michal Jurc > Assignee: David Lloyd > Priority: Blocker > > Upon attempting to lookup a remote EJB using {{jboss-ejb-client}} 2 with {{remote-naming}} context, the following exception is produced clientside: > {code} > Exception in thread "main" org.jboss.naming.remote.protocol.NamingIOException: Failed to lookup [Root exception is java.io.IOException: java.lang.ClassNotFoundException: javax.naming.CompositeName from [Module "org.wildfly.extension.io" version 5.0.0.Beta3 from local module loader @490caf5f (finder: local module finder @6337c201 (roots: /home/mjurc/testing/wildfly/build/target/wildfly-13.0.0.Alpha1-SNAPSHOT/modules,/home/mjurc/testing/wildfly/build/target/wildfly-13.0.0.Alpha1-SNAPSHOT/modules/system/layers/base))]] > at org.jboss.naming.remote.client.ClientUtil.namingException(ClientUtil.java:49) > at org.jboss.naming.remote.protocol.v1.Protocol$1.execute(Protocol.java:104) > at org.jboss.naming.remote.protocol.v1.RemoteNamingStoreV1.lookup(RemoteNamingStoreV1.java:95) > at org.jboss.naming.remote.client.HaRemoteNamingStore$1.operation(HaRemoteNamingStore.java:276) > at org.jboss.naming.remote.client.HaRemoteNamingStore.namingOperation(HaRemoteNamingStore.java:137) > at org.jboss.naming.remote.client.HaRemoteNamingStore.lookup(HaRemoteNamingStore.java:272) > at org.jboss.naming.remote.client.RemoteContext.lookupInternal(RemoteContext.java:104) > at org.jboss.naming.remote.client.RemoteContext.lookup(RemoteContext.java:93) > at org.jboss.naming.remote.client.RemoteContext.lookup(RemoteContext.java:146) > at javax.naming.InitialContext.lookup(InitialContext.java:417) > at client.Client.main(Client.java:22) > Caused by: java.io.IOException: java.lang.ClassNotFoundException: javax.naming.CompositeName from [Module "org.wildfly.extension.io" version 5.0.0.Beta3 from local module loader @490caf5f (finder: local module finder @6337c201 (roots: /home/mjurc/testing/wildfly/build/target/wildfly-13.0.0.Alpha1-SNAPSHOT/modules,/home/mjurc/testing/wildfly/build/target/wildfly-13.0.0.Alpha1-SNAPSHOT/modules/system/layers/base))] > at org.wildfly.naming.client.remote.RemoteServerTransport.handleLookup(RemoteServerTransport.java:177) > at org.wildfly.naming.client.remote.RemoteServerTransport$1.handleMessage(RemoteServerTransport.java:106) > at org.jboss.remoting3.remote.RemoteConnectionChannel.lambda$handleMessageData$3(RemoteConnectionChannel.java:430) > at org.jboss.remoting3.EndpointImpl$TrackingExecutor.lambda$execute$0(EndpointImpl.java:926) > at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35) > at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1985) > at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1487) > at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1378) > at java.lang.Thread.run(Thread.java:844) > Caused by: java.lang.ClassNotFoundException: javax.naming.CompositeName from [Module "org.wildfly.extension.io" version 5.0.0.Beta3 from local module loader @490caf5f (finder: local module finder @6337c201 (roots: /home/mjurc/testing/wildfly/build/target/wildfly-13.0.0.Alpha1-SNAPSHOT/modules,/home/mjurc/testing/wildfly/build/target/wildfly-13.0.0.Alpha1-SNAPSHOT/modules/system/layers/base))] > at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:255) > at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:410) > at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:398) > at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:116) > at java.lang.Class.forName0(Native Method) > at java.lang.Class.forName(Class.java:374) > at org.jboss.marshalling.AbstractClassResolver.loadClass(AbstractClassResolver.java:123) > at org.jboss.marshalling.AbstractClassResolver.resolveClass(AbstractClassResolver.java:104) > at org.jboss.marshalling.river.RiverUnmarshaller.doReadClassDescriptor(RiverUnmarshaller.java:1022) > at org.jboss.marshalling.river.RiverUnmarshaller.doReadNewObject(RiverUnmarshaller.java:1351) > at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:272) > at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:205) > at org.jboss.marshalling.AbstractObjectInput.readObject(AbstractObjectInput.java:76) > at org.wildfly.naming.client.remote.RemoteServerTransport.handleLookup(RemoteServerTransport.java:170) > ... 8 more > {code} > This is a regression compared to WildFly 12, therefore I am marking this issue as a blocker. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ELY-1588) Unhandled ignored usage of "clear-text" in credential-store-reference

by Jan Kalina (JIRA)

Jan Kalina created ELY-1588: ------------------------------- Summary: Unhandled ignored usage of "clear-text" in credential-store-reference Key: ELY-1588 URL: https://issues.jboss.org/browse/ELY-1588 Project: WildFly Elytron Issue Type: Enhancement Components: XML Affects Versions: 1.3.2.Final Reporter: Jan Kalina Assignee: Jan Kalina When parsing credential-store reference, it is no warned, nor documented in XSD: * when store defined, clear-text is ignored (As discussed, parse error would be inappropriate - document in xsd only.) * when store defined, alias is required (null will raise assert exception later, when trying to obtain) -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 1 month

1
0
0 / 0

[JBoss JIRA] (DROOLS-2575) Executable model - DRL integration tests fail with the model

by Tibor Zimányi (JIRA)

[ https://issues.jboss.org/browse/DROOLS-2575?page=com.atlassian.jira.plugi... ] Tibor Zimányi updated DROOLS-2575: ---------------------------------- Description: When running DRL integration tests [1] with the executable model, 118 out of 510 test cases fail. PR with tests is here [2]. [1] https://github.com/kiegroup/drools/tree/master/drools-compiler/src/test/j... [2] https://github.com/kiegroup/drools/pull/1912 was: When running DRL integration tests [1] with the executable model, 118 out of 510 test cases fail. I will provide a PR with the tests. [1] https://github.com/kiegroup/drools/tree/master/drools-compiler/src/test/j... > Executable model - DRL integration tests fail with the model > ------------------------------------------------------------ > > Key: DROOLS-2575 > URL: https://issues.jboss.org/browse/DROOLS-2575 > Project: Drools > Issue Type: Bug > Components: core engine > Affects Versions: 7.7.0.Final > Reporter: Tibor Zimányi > Assignee: Mario Fusco > > When running DRL integration tests [1] with the executable model, 118 out of 510 test cases fail. PR with tests is here [2]. > [1] https://github.com/kiegroup/drools/tree/master/drools-compiler/src/test/j... > [2] https://github.com/kiegroup/drools/pull/1912 -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 2 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-2575) Executable model - DRL integration tests fail with the model

by Tibor Zimányi (JIRA)

Tibor Zimányi created DROOLS-2575: ------------------------------------- Summary: Executable model - DRL integration tests fail with the model Key: DROOLS-2575 URL: https://issues.jboss.org/browse/DROOLS-2575 Project: Drools Issue Type: Bug Components: core engine Affects Versions: 7.7.0.Final Reporter: Tibor Zimányi Assignee: Mario Fusco When running DRL integration tests [1] with the executable model, 118 out of 510 test cases fail. I will provide a PR with the tests. [1] https://github.com/kiegroup/drools/tree/master/drools-compiler/src/test/j... -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ELY-1587) X500 principal [CN=client] was not decoded - no values of attribute [2.5.4.3]

by Jan Kalina (JIRA)

[ https://issues.jboss.org/browse/ELY-1587?page=com.atlassian.jira.plugin.s... ] Jan Kalina commented on ELY-1587: --------------------------------- [~mchoma] can you provide testing certificate for reproducing/verifying? thanks! > X500 principal [CN=client] was not decoded - no values of attribute [2.5.4.3] > ----------------------------------------------------------------------------- > > Key: ELY-1587 > URL: https://issues.jboss.org/browse/ELY-1587 > Project: WildFly Elytron > Issue Type: Bug > Components: Certificate Authority, X.500 > Affects Versions: 1.3.2.Final > Reporter: Martin Choma > Priority: Critical > Fix For: 1.3.3.CR1 > > > Debugging revealed certificate use {{utf8String}} representation whereas Elytron is expecting {{printableString}} > In rfc 5280 [1] chapter 4.1.2.4. Issuer there is specified value of ssubject/issuer can be of 5 types > {code} > DirectoryString ::= CHOICE { > teletexString TeletexString (SIZE (1..MAX)), > printableString PrintableString (SIZE (1..MAX)), > universalString UniversalString (SIZE (1..MAX)), > utf8String UTF8String (SIZE (1..MAX)), > bmpString BMPString (SIZE (1..MAX)) } > {code} > However Elytron X500 principal decoder [2] can handle only 2 of them PRINTABLE_STRING_TYPE and IA5_STRING_TYPE (not sure which type of rfc does that match) [2] > Definitely missing {{utf8String}} (my case). Also revise for backward compatibility {{teletexString}}, {{bmpString}} and {{universalString}} > [1] https://www.ietf.org/rfc/rfc5280.txt > [2] https://github.com/wildfly-security/wildfly-elytron/blob/32ff7c17965b3eca... -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JBJCA-1377) use enlistmentTrace instead of disableEnlistment parameter to avoid eager IJ000100

by Stefano Maestri (JIRA)

Stefano Maestri created JBJCA-1377: -------------------------------------- Summary: use enlistmentTrace instead of disableEnlistment parameter to avoid eager IJ000100 Key: JBJCA-1377 URL: https://issues.jboss.org/browse/JBJCA-1377 Project: IronJacamar Issue Type: Bug Reporter: Stefano Maestri Assignee: Stefano Maestri -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-10407) CertificateExpiredException in WS integration tests

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFLY-10407?page=com.atlassian.jira.plugin... ] Darran Lofthouse resolved WFLY-10407. ------------------------------------- Resolution: Duplicate Issue > CertificateExpiredException in WS integration tests > --------------------------------------------------- > > Key: WFLY-10407 > URL: https://issues.jboss.org/browse/WFLY-10407 > Project: WildFly > Issue Type: Bug > Components: Web Services > Reporter: Richard Opalka > Assignee: Rostislav Svoboda > Fix For: 13.0.0.CR1 > > > The following two WS tests started failing: > EJBSignEncryptMultipleClientsTestCase.encryptedAndSignedRequestFromJohn > SignEncryptMultipleClientsTestCase.encryptedAndSignedRequestFromJohn > [ERROR] Tests run: 119, Failures: 0, Errors: 2, Skipped: 0 > The cause is: > Caused by: org.apache.wss4j.common.ext.WSSecurityException: The provided certificate is invalid > Original Exception was java.security.cert.CertificateExpiredException: NotAfter: Fri May 18 12:48:17 CEST 2018 > <------>at org.apache.wss4j.common.crypto.Merlin.verifyTrust(Merlin.java:760) > <------>at org.apache.wss4j.common.crypto.Merlin.verifyTrust(Merlin.java:887) > <------>at org.apache.wss4j.dom.validate.SignatureTrustValidator.verifyTrustInCerts(SignatureTrustValidator.java:109) > <------>at org.apache.wss4j.dom.validate.SignatureTrustValidator.validate(SignatureTrustValidator.java:64) > <------>at org.apache.wss4j.dom.processor.SignatureProcessor.handleToken(SignatureProcessor.java:192) > <------>at org.apache.wss4j.dom.engine.WSSecurityEngine.processSecurityHeader(WSSecurityEngine.java:340) > <------>at org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor.handleMessageInternal(WSS4JInInterceptor.java:285) > <------>... 56 more -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-10415) Upgrade to ironjacamar 1.4.10 Final

by Stefano Maestri (JIRA)

Stefano Maestri created WFLY-10415: -------------------------------------- Summary: Upgrade to ironjacamar 1.4.10 Final Key: WFLY-10415 URL: https://issues.jboss.org/browse/WFLY-10415 Project: WildFly Issue Type: Bug Components: JCA Reporter: Stefano Maestri Assignee: Stefano Maestri -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-10414) Cached-connection-manager DEBUG connection closure could be too eager with enlistment-trace==false

by Stefano Maestri (JIRA)

[ https://issues.jboss.org/browse/WFLY-10414?page=com.atlassian.jira.plugin... ] Stefano Maestri moved JBEAP-14759 to WFLY-10414: ------------------------------------------------ Project: WildFly (was: JBoss Enterprise Application Platform) Key: WFLY-10414 (was: JBEAP-14759) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Component/s: JCA (was: JCA) Affects Version/s: 13.0.0.Beta1 12.0.0.Final (was: 7.1.2.GA) (was: 7.2.0.CD13.GA) > Cached-connection-manager DEBUG connection closure could be too eager with enlistment-trace==false > -------------------------------------------------------------------------------------------------- > > Key: WFLY-10414 > URL: https://issues.jboss.org/browse/WFLY-10414 > Project: WildFly > Issue Type: Bug > Components: JCA > Affects Versions: 13.0.0.Beta1, 12.0.0.Final > Reporter: Stefano Maestri > Assignee: Stefano Maestri > Labels: gss > > There is some corner cases in which IJ isn't able to avoid IJ000100 (closing connection for you) on connection already marked as invalid and firing IJ000100 closing it, even if the connection would be closed as invalid immediately after. It doesn't create problems to the connection pool, but the redundant WARN isn't useful and could be read as connection leak. > It happens only with enlistment-trace=false (which is default since 7.2) set for the involved datasource -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 2 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira May 2018