[JBoss JIRA] (ELY-1630) Ignore any blank lines in between the certificates in the certificate chain returned by an ACME server to avoid parsing issues on IBM JDK
by Farah Juma (JIRA)
[ https://issues.jboss.org/browse/ELY-1630?page=com.atlassian.jira.plugin.s... ]
Farah Juma updated ELY-1630:
----------------------------
Description:
Currently, {{AcmeClientSpiTest#testObtainCertificateChainWithKeySize}} and {{AcmeClientSpiTest#testObtainCertificateChainWithECPublicKey}} fail when run with IBM JDK with the following error:
{code}
org.wildfly.security.x500.cert.acme.AcmeException: ELY10049: Unable to download certificate chain from ACME server
at org.wildfly.security.x500.cert.acme.AcmeClientSpi.getPemCertificateChain(AcmeClientSpi.java:988)
at org.wildfly.security.x500.cert.acme.AcmeClientSpi.obtainCertificateChain(AcmeClientSpi.java:519)
at org.wildfly.security.x500.cert.acme.AcmeClientSpiTest.obtainCertificateChain(AcmeClientSpiTest.java:284)
at org.wildfly.security.x500.cert.acme.AcmeClientSpiTest.testObtainCertificateChainWithKeySize(AcmeClientSpiTest.java:260)
Caused by: java.security.cert.CertificateException: Unable to initialize, java.io.IOException: insufficient data
at com.ibm.security.x509.X509CertImpl.<init>(X509CertImpl.java:268)
at java.security.cert.CertificateFactory.generateCertificates(CertificateFactory.java:448)
at org.wildfly.security.x500.cert.acme.AcmeClientSpi.getPemCertificateChain(AcmeClientSpi.java:984)
... 3 more
{code}
The underlying issue is that the PEM certificate chain returned by the ACME server has a blank line in between the two certificates in the chain. This causes parsing issues on IBM JDK when {{CertificateFactory.generateCertificates()}} is called. To fix this, we can just ignore any blank lines in the chain.
was:
Currently, {{AcmeClientSpiTest#testObtainCertificateChainWithKeySize}} and {{AcmeClientSpiTest#testObtainCertificateChainWithECPublicKey}} fail when run with IBM JDK with the following error:
{code}
org.wildfly.security.x500.cert.acme.AcmeException: ELY10049: Unable to download certificate chain from ACME server
at org.wildfly.security.x500.cert.acme.AcmeClientSpi.getPemCertificateChain(AcmeClientSpi.java:988)
at org.wildfly.security.x500.cert.acme.AcmeClientSpi.obtainCertificateChain(AcmeClientSpi.java:519)
at org.wildfly.security.x500.cert.acme.AcmeClientSpiTest.obtainCertificateChain(AcmeClientSpiTest.java:284)
at org.wildfly.security.x500.cert.acme.AcmeClientSpiTest.testObtainCertificateChainWithKeySize(AcmeClientSpiTest.java:260)
Caused by: java.security.cert.CertificateException: Unable to initialize, java.io.IOException: insufficient data
at com.ibm.security.x509.X509CertImpl.<init>(X509CertImpl.java:268)
at java.security.cert.CertificateFactory.generateCertificates(CertificateFactory.java:448)
at org.wildfly.security.x500.cert.acme.AcmeClientSpi.getPemCertificateChain(AcmeClientSpi.java:984)
... 3 more
{code}
The underlying issue is that the PEM certificate chain returned by the ACME server has a blank line in between the two certificates in the chain. This causes parsing issues on IBM JDK. To fix this, we can just ignore any blank lines in the chain.
> Ignore any blank lines in between the certificates in the certificate chain returned by an ACME server to avoid parsing issues on IBM JDK
> -----------------------------------------------------------------------------------------------------------------------------------------
>
> Key: ELY-1630
> URL: https://issues.jboss.org/browse/ELY-1630
> Project: WildFly Elytron
> Issue Type: Bug
> Components: API / SPI
> Reporter: Farah Juma
> Assignee: Farah Juma
>
> Currently, {{AcmeClientSpiTest#testObtainCertificateChainWithKeySize}} and {{AcmeClientSpiTest#testObtainCertificateChainWithECPublicKey}} fail when run with IBM JDK with the following error:
> {code}
> org.wildfly.security.x500.cert.acme.AcmeException: ELY10049: Unable to download certificate chain from ACME server
> at org.wildfly.security.x500.cert.acme.AcmeClientSpi.getPemCertificateChain(AcmeClientSpi.java:988)
> at org.wildfly.security.x500.cert.acme.AcmeClientSpi.obtainCertificateChain(AcmeClientSpi.java:519)
> at org.wildfly.security.x500.cert.acme.AcmeClientSpiTest.obtainCertificateChain(AcmeClientSpiTest.java:284)
> at org.wildfly.security.x500.cert.acme.AcmeClientSpiTest.testObtainCertificateChainWithKeySize(AcmeClientSpiTest.java:260)
> Caused by: java.security.cert.CertificateException: Unable to initialize, java.io.IOException: insufficient data
> at com.ibm.security.x509.X509CertImpl.<init>(X509CertImpl.java:268)
> at java.security.cert.CertificateFactory.generateCertificates(CertificateFactory.java:448)
> at org.wildfly.security.x500.cert.acme.AcmeClientSpi.getPemCertificateChain(AcmeClientSpi.java:984)
> ... 3 more
> {code}
> The underlying issue is that the PEM certificate chain returned by the ACME server has a blank line in between the two certificates in the chain. This causes parsing issues on IBM JDK when {{CertificateFactory.generateCertificates()}} is called. To fix this, we can just ignore any blank lines in the chain.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 9 months
[JBoss JIRA] (ELY-1630) Ignore any blank lines in between the certificates in the certificate chain returned by an ACME server to avoid parsing issues on IBM JDK
by Farah Juma (JIRA)
Farah Juma created ELY-1630:
-------------------------------
Summary: Ignore any blank lines in between the certificates in the certificate chain returned by an ACME server to avoid parsing issues on IBM JDK
Key: ELY-1630
URL: https://issues.jboss.org/browse/ELY-1630
Project: WildFly Elytron
Issue Type: Bug
Components: API / SPI
Reporter: Farah Juma
Assignee: Farah Juma
Currently, {{AcmeClientSpiTest#testObtainCertificateChainWithKeySize}} and {{AcmeClientSpiTest#testObtainCertificateChainWithECPublicKey}} fail when run with IBM JDK with the following error:
{code}
org.wildfly.security.x500.cert.acme.AcmeException: ELY10049: Unable to download certificate chain from ACME server
at org.wildfly.security.x500.cert.acme.AcmeClientSpi.getPemCertificateChain(AcmeClientSpi.java:988)
at org.wildfly.security.x500.cert.acme.AcmeClientSpi.obtainCertificateChain(AcmeClientSpi.java:519)
at org.wildfly.security.x500.cert.acme.AcmeClientSpiTest.obtainCertificateChain(AcmeClientSpiTest.java:284)
at org.wildfly.security.x500.cert.acme.AcmeClientSpiTest.testObtainCertificateChainWithKeySize(AcmeClientSpiTest.java:260)
Caused by: java.security.cert.CertificateException: Unable to initialize, java.io.IOException: insufficient data
at com.ibm.security.x509.X509CertImpl.<init>(X509CertImpl.java:268)
at java.security.cert.CertificateFactory.generateCertificates(CertificateFactory.java:448)
at org.wildfly.security.x500.cert.acme.AcmeClientSpi.getPemCertificateChain(AcmeClientSpi.java:984)
... 3 more
{code}
The underlying issue is that the PEM certificate chain returned by the ACME server has a blank line in between the two certificates in the chain. This causes parsing issues on IBM JDK. To fix this, we can just ignore any blank lines in the chain.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 9 months
[JBoss JIRA] (WFLY-10822) Provision core as a transitive dependency explicitly
by Alexey Loubyansky (JIRA)
Alexey Loubyansky created WFLY-10822:
----------------------------------------
Summary: Provision core as a transitive dependency explicitly
Key: WFLY-10822
URL: https://issues.jboss.org/browse/WFLY-10822
Project: WildFly
Issue Type: Task
Components: Build System
Reporter: Alexey Loubyansky
Assignee: Alexey Loubyansky
Currently core is installed implicitly as a dependency of wildfly and servlet. We use resolve-local elements in provision goal config for core and servlet feature-packs. Those are shortcuts to avoid the universe-based feature-pack resolver.
If instead of resolve-local elements we use feature-pack/transitive elements we will achieve the same effect avoiding the universe-based resolver and it will also allow us to specify the version of core using a system property.
The only difference will show up in .galleon/provisioning.xml, which will change from (based on build module)
{code:java}
<installation xmlns="urn:jboss:galleon:provisioning:2.0">
<feature-pack location="wildfly@maven(org.jboss.universe:community-universe):current#14.0.0.Beta2-SNAPSHOT">
<packages>
<include name="docs.examples.configs"/>
</packages>
</feature-pack>
</installation>
{code}
to
{code:java}
<installation xmlns="urn:jboss:galleon:provisioning:2.0">
<transitive>
<feature-pack location="wildfly-core@maven(org.jboss.universe:community-universe):current#6.0.0.Alpha5"/>
<feature-pack location="wildfly-servlet@maven(org.jboss.universe:community-universe):current#14.0.0.Beta2-SNAPSHOT"/>
</transitive>
<feature-pack location="wildfly@maven(org.jboss.universe:community-universe):current#14.0.0.Beta2-SNAPSHOT">
<packages>
<include name="docs.examples.configs"/>
</packages>
</feature-pack>
</installation>
{code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 9 months
[JBoss JIRA] (DROOLS-2787) "Data Type" tree-grid table interactions.
by Liz Clayton (JIRA)
[ https://issues.jboss.org/browse/DROOLS-2787?page=com.atlassian.jira.plugi... ]
Liz Clayton resolved DROOLS-2787.
---------------------------------
Resolution: Done
marking as Resolved, verified with PO.
> "Data Type" tree-grid table interactions.
> -----------------------------------------
>
> Key: DROOLS-2787
> URL: https://issues.jboss.org/browse/DROOLS-2787
> Project: Drools
> Issue Type: Story
> Components: DMN Editor
> Reporter: Liz Clayton
> Assignee: Liz Clayton
> Labels: UX, UXTeam, drools-tools
> Attachments: DROOLS-2738.bmpr, Manage1.png, Manage2.png, Screen Shot 2018-07-24 at 3.51.03 PM.png, Screen Shot 2018-07-27 at 11.48.34 AM.png, Screen Shot 2018-07-27 at 12.24.49 PM.png, Screen Shot 2018-07-27 at 12.27.13 PM.png, Screen Shot 2018-08-09 at 2.09.21 PM.png, add_basic.png, treegrid.png, type_definitions.pdf
>
>
> *Background*
> Persona: Business analyst or Rules practitioner
> Use Cases:
> As a user I want to:
> * *Edit* the list of Data Types, using the appropriate type considering the DMN model (eg: in the age line, we need to select "Numeric" in the combobox.)
> * *Add* a new data type, which might be a nested or otherwise complex object as defined by the (ItemDefinition.)
> * *Remove* Data Types from the list of available selections.
> * be prevented from making selections that are not valid or would cause an error.
> * know that when I edit a data type the changes will be updated in the DMN model.
> Functional considerations/ pre conditions:
> * Outside of simple view/select, Data Types list (and options) will be presented as a tree-grid within a modal dialog. Discussed in detail within Epic subtask for the same.
> * Design needs to be consistent with Stunner and PF components, such as: https://www.patternfly.org/pattern-library/widgets/#treegrid-table
> Verification conditions:
> * Scrum team and PO review.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 9 months
[JBoss JIRA] (DROOLS-2774) Select a data type from the DMN canvas
by Liz Clayton (JIRA)
[ https://issues.jboss.org/browse/DROOLS-2774?page=com.atlassian.jira.plugi... ]
Liz Clayton commented on DROOLS-2774:
-------------------------------------
[~karreiro] s'ok to mark this as Resolved?
> Select a data type from the DMN canvas
> ---------------------------------------
>
> Key: DROOLS-2774
> URL: https://issues.jboss.org/browse/DROOLS-2774
> Project: Drools
> Issue Type: Story
> Components: DMN Editor
> Reporter: Liz Clayton
> Assignee: Liz Clayton
> Labels: UX, UXTeam, drools-tools
> Attachments: select.png
>
>
> *Background*
> Persona: Business analyst or Rules practitioner
> Use Cases:
> * From the DMN canvas view - as a user I want to *select* a data type, from a list of available data types, so I can associate it with a DMN node.
> * From the DMN canvas view - as a user I want a *means to* add a desired data type to the list of available data types.
> * From the DMN canvas view - as a user I want a *means to* edit a desired data type from the list of available data types.
> Functional considerations/ pre conditions:
> * Actions will be offered or spawned from right dock properties panel.
> * Design needs to be consistent with Stunner and PF components.
> Verification conditions:
> * Scrum team and PO review.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 9 months
[JBoss JIRA] (DROOLS-2787) "Data Type" tree-grid table interactions.
by Liz Clayton (JIRA)
[ https://issues.jboss.org/browse/DROOLS-2787?page=com.atlassian.jira.plugi... ]
Liz Clayton commented on DROOLS-2787:
-------------------------------------
Links for bootstrap widgets to reference for the enumeration widget:
https://maxfavilli.com/jquery-tag-manager
http://sliptree.github.io/bootstrap-tokenfield/#options
> "Data Type" tree-grid table interactions.
> -----------------------------------------
>
> Key: DROOLS-2787
> URL: https://issues.jboss.org/browse/DROOLS-2787
> Project: Drools
> Issue Type: Story
> Components: DMN Editor
> Reporter: Liz Clayton
> Assignee: Liz Clayton
> Labels: UX, UXTeam, drools-tools
> Attachments: DROOLS-2738.bmpr, Manage1.png, Manage2.png, Screen Shot 2018-07-24 at 3.51.03 PM.png, Screen Shot 2018-07-27 at 11.48.34 AM.png, Screen Shot 2018-07-27 at 12.24.49 PM.png, Screen Shot 2018-07-27 at 12.27.13 PM.png, Screen Shot 2018-08-09 at 2.09.21 PM.png, add_basic.png, treegrid.png, type_definitions.pdf
>
>
> *Background*
> Persona: Business analyst or Rules practitioner
> Use Cases:
> As a user I want to:
> * *Edit* the list of Data Types, using the appropriate type considering the DMN model (eg: in the age line, we need to select "Numeric" in the combobox.)
> * *Add* a new data type, which might be a nested or otherwise complex object as defined by the (ItemDefinition.)
> * *Remove* Data Types from the list of available selections.
> * be prevented from making selections that are not valid or would cause an error.
> * know that when I edit a data type the changes will be updated in the DMN model.
> Functional considerations/ pre conditions:
> * Outside of simple view/select, Data Types list (and options) will be presented as a tree-grid within a modal dialog. Discussed in detail within Epic subtask for the same.
> * Design needs to be consistent with Stunner and PF components, such as: https://www.patternfly.org/pattern-library/widgets/#treegrid-table
> Verification conditions:
> * Scrum team and PO review.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 9 months
[JBoss JIRA] (LOGMGR-200) SSLProtocolException: Connection reset on JDK11
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/LOGMGR-200?page=com.atlassian.jira.plugin... ]
James Perkins commented on LOGMGR-200:
--------------------------------------
Turning on debug logging has turned this up as well:
{code}
javax.net.ssl|DEBUG|01|main|2018-08-09 12:55:33.773 PDT|SSLExtensions.java:148|Ignore unavailable extension: server_name
javax.net.ssl|DEBUG|01|main|2018-08-09 12:55:33.773 PDT|SSLExtensions.java:148|Ignore unavailable extension: max_fragment_length
javax.net.ssl|DEBUG|01|main|2018-08-09 12:55:33.773 PDT|SSLExtensions.java:167|Consumed extension: supported_groups
javax.net.ssl|DEBUG|01|main|2018-08-09 12:55:33.773 PDT|SSLExtensions.java:182|Ignore unavailable extension: server_name
javax.net.ssl|DEBUG|01|main|2018-08-09 12:55:33.774 PDT|SSLExtensions.java:182|Ignore unavailable extension: max_fragment_length
javax.net.ssl|WARNING|01|main|2018-08-09 12:55:33.774 PDT|SSLExtensions.java:190|Ignore impact of unsupported extension: supported_groups
javax.net.ssl|DEBUG|01|main|2018-08-09 12:55:33.774 PDT|SSLExtensions.java:182|Ignore unavailable extension: application_layer_protocol_negotiation
javax.net.ssl|ALL|0F|Thread-0|2018-08-09 12:55:33.775 PDT|X509Authentication.java:241|No X.509 cert selected for EC
javax.net.ssl|WARNING|0F|Thread-0|2018-08-09 12:55:33.775 PDT|CertificateMessage.java:1059|Unavailable authentication scheme: ecdsa_secp256r1_sha256
javax.net.ssl|ALL|0F|Thread-0|2018-08-09 12:55:33.775 PDT|X509Authentication.java:241|No X.509 cert selected for EC
javax.net.ssl|WARNING|0F|Thread-0|2018-08-09 12:55:33.775 PDT|CertificateMessage.java:1059|Unavailable authentication scheme: ecdsa_secp384r1_sha384
javax.net.ssl|ALL|0F|Thread-0|2018-08-09 12:55:33.775 PDT|X509Authentication.java:241|No X.509 cert selected for EC
javax.net.ssl|WARNING|0F|Thread-0|2018-08-09 12:55:33.776 PDT|CertificateMessage.java:1059|Unavailable authentication scheme: ecdsa_secp512r1_sha512
javax.net.ssl|ALL|0F|Thread-0|2018-08-09 12:55:33.776 PDT|X509Authentication.java:241|No X.509 cert selected for RSA
javax.net.ssl|WARNING|0F|Thread-0|2018-08-09 12:55:33.776 PDT|CertificateMessage.java:1059|Unavailable authentication scheme: rsa_pss_rsae_sha256
javax.net.ssl|ALL|0F|Thread-0|2018-08-09 12:55:33.776 PDT|X509Authentication.java:241|No X.509 cert selected for RSA
javax.net.ssl|WARNING|0F|Thread-0|2018-08-09 12:55:33.776 PDT|CertificateMessage.java:1059|Unavailable authentication scheme: rsa_pss_rsae_sha384
javax.net.ssl|ALL|0F|Thread-0|2018-08-09 12:55:33.777 PDT|X509Authentication.java:241|No X.509 cert selected for RSA
javax.net.ssl|WARNING|0F|Thread-0|2018-08-09 12:55:33.777 PDT|CertificateMessage.java:1059|Unavailable authentication scheme: rsa_pss_rsae_sha512
javax.net.ssl|ALL|0F|Thread-0|2018-08-09 12:55:33.777 PDT|X509Authentication.java:241|No X.509 cert selected for RSASSA-PSS
javax.net.ssl|WARNING|0F|Thread-0|2018-08-09 12:55:33.777 PDT|CertificateMessage.java:1059|Unavailable authentication scheme: rsa_pss_pss_sha256
javax.net.ssl|ALL|0F|Thread-0|2018-08-09 12:55:33.777 PDT|X509Authentication.java:241|No X.509 cert selected for RSASSA-PSS
javax.net.ssl|WARNING|0F|Thread-0|2018-08-09 12:55:33.777 PDT|CertificateMessage.java:1059|Unavailable authentication scheme: rsa_pss_pss_sha384
javax.net.ssl|ALL|0F|Thread-0|2018-08-09 12:55:33.778 PDT|X509Authentication.java:241|No X.509 cert selected for RSASSA-PSS
javax.net.ssl|WARNING|0F|Thread-0|2018-08-09 12:55:33.778 PDT|CertificateMessage.java:1059|Unavailable authentication scheme: rsa_pss_pss_sha512
javax.net.ssl|ALL|0F|Thread-0|2018-08-09 12:55:33.778 PDT|X509Authentication.java:241|No X.509 cert selected for RSA
javax.net.ssl|WARNING|0F|Thread-0|2018-08-09 12:55:33.778 PDT|CertificateMessage.java:1059|Unavailable authentication scheme: rsa_pkcs1_sha256
javax.net.ssl|ALL|0F|Thread-0|2018-08-09 12:55:33.778 PDT|X509Authentication.java:241|No X.509 cert selected for RSA
javax.net.ssl|WARNING|0F|Thread-0|2018-08-09 12:55:33.779 PDT|CertificateMessage.java:1059|Unavailable authentication scheme: rsa_pkcs1_sha384
javax.net.ssl|ALL|0F|Thread-0|2018-08-09 12:55:33.779 PDT|X509Authentication.java:241|No X.509 cert selected for RSA
javax.net.ssl|WARNING|0F|Thread-0|2018-08-09 12:55:33.779 PDT|CertificateMessage.java:1059|Unavailable authentication scheme: rsa_pkcs1_sha512
javax.net.ssl|ALL|0F|Thread-0|2018-08-09 12:55:33.779 PDT|X509Authentication.java:241|No X.509 cert selected for EC
javax.net.ssl|WARNING|0F|Thread-0|2018-08-09 12:55:33.779 PDT|CertificateMessage.java:1059|Unavailable authentication scheme: ecdsa_sha1
javax.net.ssl|ALL|0F|Thread-0|2018-08-09 12:55:33.780 PDT|X509Authentication.java:241|No X.509 cert selected for RSA
javax.net.ssl|WARNING|0F|Thread-0|2018-08-09 12:55:33.780 PDT|CertificateMessage.java:1059|Unavailable authentication scheme: rsa_pkcs1_sha1
javax.net.ssl|WARNING|0F|Thread-0|2018-08-09 12:55:33.780 PDT|CertificateMessage.java:1069|No available authentication scheme
javax.net.ssl|ERROR|0F|Thread-0|2018-08-09 12:55:33.782 PDT|TransportContext.java:317|Fatal (HANDSHAKE_FAILURE): No available authentication scheme (
"throwable" : {
javax.net.ssl.SSLHandshakeException: No available authentication scheme
at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:128)
at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:117)
at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:312)
at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:268)
at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:259)
at java.base/sun.security.ssl.CertificateMessage$T13CertificateProducer.onProduceCertificate(CertificateMessage.java:945)
at java.base/sun.security.ssl.CertificateMessage$T13CertificateProducer.produce(CertificateMessage.java:934)
at java.base/sun.security.ssl.SSLHandshake.produce(SSLHandshake.java:429)
at java.base/sun.security.ssl.ClientHello$T13ClientHelloConsumer.goServerHello(ClientHello.java:1189)
at java.base/sun.security.ssl.ClientHello$T13ClientHelloConsumer.consume(ClientHello.java:1125)
at java.base/sun.security.ssl.ClientHello$ClientHelloConsumer.onClientHello(ClientHello.java:831)
at java.base/sun.security.ssl.ClientHello$ClientHelloConsumer.consume(ClientHello.java:792)
at java.base/sun.security.ssl.SSLHandshake.consume(SSLHandshake.java:390)
at java.base/sun.security.ssl.HandshakeContext.dispatch(HandshakeContext.java:445)
at java.base/sun.security.ssl.HandshakeContext.dispatch(HandshakeContext.java:422)
at java.base/sun.security.ssl.TransportContext.dispatch(TransportContext.java:178)
at java.base/sun.security.ssl.SSLTransport.decode(SSLTransport.java:164)
at java.base/sun.security.ssl.SSLSocketImpl.decode(SSLSocketImpl.java:877)
at java.base/sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:810)
at java.base/sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:383)
at java.base/sun.security.ssl.SSLSocketImpl.ensureNegotiated(SSLSocketImpl.java:477)
at java.base/sun.security.ssl.SSLSocketImpl$AppInputStream.read(SSLSocketImpl.java:558)
at java.base/java.io.InputStream.read(InputStream.java:205)
at org.jboss.logmanager.handlers.SimpleServer$TcpServer.run(SimpleServer.java:121)
at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
at java.base/java.lang.Thread.run(Thread.java:834)}
)
{code}
> SSLProtocolException: Connection reset on JDK11
> -----------------------------------------------
>
> Key: LOGMGR-200
> URL: https://issues.jboss.org/browse/LOGMGR-200
> Project: JBoss Log Manager
> Issue Type: Bug
> Affects Versions: 2.1.4.Final
> Reporter: Jan Kalina
> Priority: Blocker
>
> testTlsConnection and other SSL related tests in SocketHandlerTests fails on JDK11:
> {code}
> LogManager error of type FLUSH_FAILURE: Error on flush
> javax.net.ssl.SSLProtocolException: Connection reset
> at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:126)
> at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:325)
> at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:268)
> at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:263)
> at java.base/sun.security.ssl.SSLTransport.decode(SSLTransport.java:137)
> at java.base/sun.security.ssl.SSLSocketImpl.decode(SSLSocketImpl.java:877)
> at java.base/sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:810)
> at java.base/sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:383)
> at java.base/sun.security.ssl.SSLSocketImpl.ensureNegotiated(SSLSocketImpl.java:477)
> at java.base/sun.security.ssl.SSLSocketImpl$AppOutputStream.write(SSLSocketImpl.java:709)
> at org.jboss.logmanager.handlers.TcpOutputStream.write(TcpOutputStream.java:188)
> at org.jboss.logmanager.handlers.UninterruptibleOutputStream.write(UninterruptibleOutputStream.java:84)
> at java.base/sun.nio.cs.StreamEncoder.writeBytes(StreamEncoder.java:233)
> at java.base/sun.nio.cs.StreamEncoder.implFlushBuffer(StreamEncoder.java:312)
> at java.base/sun.nio.cs.StreamEncoder.implFlush(StreamEncoder.java:316)
> at java.base/sun.nio.cs.StreamEncoder.flush(StreamEncoder.java:153)
> at java.base/java.io.OutputStreamWriter.flush(OutputStreamWriter.java:254)
> at org.jboss.logmanager.handlers.SocketHandler.safeFlush(SocketHandler.java:512)
> at org.jboss.logmanager.handlers.SocketHandler.flush(SocketHandler.java:228)
> at org.jboss.logmanager.ExtHandler.doPublish(ExtHandler.java:105)
> at org.jboss.logmanager.handlers.SocketHandler.doPublish(SocketHandler.java:218)
> at org.jboss.logmanager.handlers.SocketHandlerTests.testTlsConnection(SocketHandlerTests.java:59)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:566)
> at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
> at com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:68)
> at com.intellij.rt.execution.junit.IdeaTestRunner$Repeater.startRunnerWithArgs(IdeaTestRunner.java:47)
> at com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:242)
> at com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:70)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:566)
> at com.intellij.rt.execution.application.AppMainV2.main(AppMainV2.java:131)
> Caused by: java.net.SocketException: Connection reset
> at java.base/java.net.SocketInputStream.read(SocketInputStream.java:186)
> at java.base/java.net.SocketInputStream.read(SocketInputStream.java:140)
> at java.base/sun.security.ssl.SSLSocketInputRecord.read(SSLSocketInputRecord.java:464)
> at java.base/sun.security.ssl.SSLSocketInputRecord.decode(SSLSocketInputRecord.java:167)
> at java.base/sun.security.ssl.SSLTransport.decode(SSLTransport.java:108)
> ... 46 more
> java.lang.AssertionError
> at org.junit.Assert.fail(Assert.java:86)
> at org.junit.Assert.assertTrue(Assert.java:41)
> at org.junit.Assert.assertNotNull(Assert.java:712)
> at org.junit.Assert.assertNotNull(Assert.java:722)
> at org.jboss.logmanager.handlers.SocketHandlerTests.testTlsConnection(SocketHandlerTests.java:61)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:566)
> at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
> at com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:68)
> at com.intellij.rt.execution.junit.IdeaTestRunner$Repeater.startRunnerWithArgs(IdeaTestRunner.java:47)
> at com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:242)
> at com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:70)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:566)
> at com.intellij.rt.execution.application.AppMainV2.main(AppMainV2.java:131)
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 9 months
[JBoss JIRA] (ELY-1629) Let's Encrypt: Upcoming ACME v2 Key Rollover breaking change
by Farah Juma (JIRA)
[ https://issues.jboss.org/browse/ELY-1629?page=com.atlassian.jira.plugin.s... ]
Farah Juma commented on ELY-1629:
---------------------------------
[~ccppuu] This is the correct place to report issues with the Elytron ACME client implementation. Thanks very much for the heads up, much appreciated! I'll update our implementation.
Thanks!
> Let's Encrypt: Upcoming ACME v2 Key Rollover breaking change
> ------------------------------------------------------------
>
> Key: ELY-1629
> URL: https://issues.jboss.org/browse/ELY-1629
> Project: WildFly Elytron
> Issue Type: Feature Request
> Reporter: Daniel McCarney
> Assignee: Farah Juma
>
> Hi folks,
> First: Apologies if this isn't the correct repository to open an issue. I'm trying to find the maintainers of the Elytron ACME Client. It looks like most of that code lives in https://github.com/wildfly-security/wildfly-elytron but that repository doesn't allow opening issues and directs to this JIRA instance.
> I wanted to file an issue with the maintainers to provide a heads up about an [upcoming backwards compatibility breaking ACME change|https://community.letsencrypt.org/t/acme-v2-draft-13-compliant-key...] that I think may affect your project based on this code snippet:
> https://github.com/wildfly-security/wildfly-elytron/blob/bfe53b16d2f42ac8...
> While I was preparing the announcement about this change I did some log analysis to see which User Agents were using the Let's Encrypt ACME v2 key change endpoint. `Elytron ACME Client/1.5.1.Final` was one of a small handful of client UAs that are sending production key change requests. Kudos for implementing the specification so thoroughly! Sorry to break your code with a protocol change :-)
> Please let me know if I can provide any guidance from the Let's Encrypt/Boulder side, or if there is a better place to report issues with this ACME client implementation.
> Thanks!
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 9 months