[JBoss JIRA] (WFCORE-5133) SNICombinedWithALPNTestCase fails with oracle JDK 8 261
by Jan Stourac (Jira)
[ https://issues.redhat.com/browse/WFCORE-5133?page=com.atlassian.jira.plug... ]
Jan Stourac commented on WFCORE-5133:
-------------------------------------
Just a note here - when test is executed as is, then there is an NPE since no ClientConnection is created:
{code}
[wildfly-core/testsuite/standalone]$ JAVA_HOME=/home/jstourac/jdks/jdk1.8.0_261 mvn install -Dtest=SNICombinedWithALPNTestCase.java -DfailIfNoTests=false
...
[ERROR] testHttpsViaIp(org.jboss.as.test.integration.security.ssl.sni.SNICombinedWithALPNTestCase) Time elapsed: 0.095 s <<< ERROR!
java.lang.NullPointerException
at io.undertow.client.http.HttpClientConnection.handleError(HttpClientConnection.java:444)
at io.undertow.client.http.HttpClientConnection.handleError(HttpClientConnection.java:437)
at io.undertow.client.http.HttpClientConnection.initiateRequest(HttpClientConnection.java:430)
at io.undertow.client.http.HttpClientConnection.sendRequest(HttpClientConnection.java:347)
at org.jboss.as.test.integration.security.ssl.sni.SNICombinedWithALPNTestCase.performSimpleTest(SNICombinedWithALPNTestCase.java:242)
at org.jboss.as.test.integration.security.ssl.sni.SNICombinedWithALPNTestCase.testHttpsViaIp(SNICombinedWithALPNTestCase.java:232)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
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.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.wildfly.core.testrunner.WildflyTestRunner.run(WildflyTestRunner.java:157)
at org.junit.runners.Suite.runChild(Suite.java:128)
at org.junit.runners.Suite.runChild(Suite.java:27)
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.apache.maven.surefire.junitcore.JUnitCore.run(JUnitCore.java:55)
at org.apache.maven.surefire.junitcore.JUnitCoreWrapper.createRequestAndRun(JUnitCoreWrapper.java:137)
at org.apache.maven.surefire.junitcore.JUnitCoreWrapper.executeEager(JUnitCoreWrapper.java:107)
at org.apache.maven.surefire.junitcore.JUnitCoreWrapper.execute(JUnitCoreWrapper.java:83)
at org.apache.maven.surefire.junitcore.JUnitCoreWrapper.execute(JUnitCoreWrapper.java:75)
at org.apache.maven.surefire.junitcore.JUnitCoreProvider.invoke(JUnitCoreProvider.java:158)
at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:384)
at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:345)
at org.apache.maven.surefire.booter.ForkedBooter.execute(ForkedBooter.java:126)
at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:418)
[ERROR] testSimpleViaHostname(org.jboss.as.test.integration.security.ssl.sni.SNICombinedWithALPNTestCase) Time elapsed: 0.01 s <<< ERROR!
java.lang.NullPointerException
at io.undertow.client.http.HttpClientConnection.handleError(HttpClientConnection.java:444)
at io.undertow.client.http.HttpClientConnection.handleError(HttpClientConnection.java:437)
at io.undertow.client.http.HttpClientConnection.initiateRequest(HttpClientConnection.java:430)
at io.undertow.client.http.HttpClientConnection.sendRequest(HttpClientConnection.java:347)
at org.jboss.as.test.integration.security.ssl.sni.SNICombinedWithALPNTestCase.performSimpleTest(SNICombinedWithALPNTestCase.java:242)
at org.jboss.as.test.integration.security.ssl.sni.SNICombinedWithALPNTestCase.testSimpleViaHostname(SNICombinedWithALPNTestCase.java:220)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
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.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.wildfly.core.testrunner.WildflyTestRunner.run(WildflyTestRunner.java:157)
at org.junit.runners.Suite.runChild(Suite.java:128)
at org.junit.runners.Suite.runChild(Suite.java:27)
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.apache.maven.surefire.junitcore.JUnitCore.run(JUnitCore.java:55)
at org.apache.maven.surefire.junitcore.JUnitCoreWrapper.createRequestAndRun(JUnitCoreWrapper.java:137)
at org.apache.maven.surefire.junitcore.JUnitCoreWrapper.executeEager(JUnitCoreWrapper.java:107)
at org.apache.maven.surefire.junitcore.JUnitCoreWrapper.execute(JUnitCoreWrapper.java:83)
at org.apache.maven.surefire.junitcore.JUnitCoreWrapper.execute(JUnitCoreWrapper.java:75)
at org.apache.maven.surefire.junitcore.JUnitCoreProvider.invoke(JUnitCoreProvider.java:158)
at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:384)
at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:345)
at org.apache.maven.surefire.booter.ForkedBooter.execute(ForkedBooter.java:126)
at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:418)
...
{code}
If also '-Dio.undertow.protocols.alpn.jdk8' is defined as mentioned in UNDERTOW-1726 then ClientConnection is created, response is successfully sent, although - HTTP/1.1 protocol is used instead of expected HTTP2:
{code}
[wildfly-core/testsuite/standalone]$ JAVA_HOME=/home/jstourac/jdks/jdk1.8.0_261 mvn install -Dtest=SNICombinedWithALPNTestCase.java -DfailIfNoTests=false -Dio.undertow.protocols.alpn.jdk8
...
[ERROR] testHttpsViaIp(org.jboss.as.test.integration.security.ssl.sni.SNICombinedWithALPNTestCase) Time elapsed: 0.267 s <<< FAILURE!
org.junit.ComparisonFailure: expected:<Response sent:HTTP/[2.0]> but was:<Response sent:HTTP/[1.1]>
at org.junit.Assert.assertEquals(Assert.java:115)
at org.junit.Assert.assertEquals(Assert.java:144)
at org.jboss.as.test.integration.security.ssl.sni.SNICombinedWithALPNTestCase.performSimpleTest(SNICombinedWithALPNTestCase.java:273)
at org.jboss.as.test.integration.security.ssl.sni.SNICombinedWithALPNTestCase.testHttpsViaIp(SNICombinedWithALPNTestCase.java:232)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
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.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.wildfly.core.testrunner.WildflyTestRunner.run(WildflyTestRunner.java:157)
at org.junit.runners.Suite.runChild(Suite.java:128)
at org.junit.runners.Suite.runChild(Suite.java:27)
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.apache.maven.surefire.junitcore.JUnitCore.run(JUnitCore.java:55)
at org.apache.maven.surefire.junitcore.JUnitCoreWrapper.createRequestAndRun(JUnitCoreWrapper.java:137)
at org.apache.maven.surefire.junitcore.JUnitCoreWrapper.executeEager(JUnitCoreWrapper.java:107)
at org.apache.maven.surefire.junitcore.JUnitCoreWrapper.execute(JUnitCoreWrapper.java:83)
at org.apache.maven.surefire.junitcore.JUnitCoreWrapper.execute(JUnitCoreWrapper.java:75)
at org.apache.maven.surefire.junitcore.JUnitCoreProvider.invoke(JUnitCoreProvider.java:158)
at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:384)
at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:345)
at org.apache.maven.surefire.booter.ForkedBooter.execute(ForkedBooter.java:126)
at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:418)
[ERROR] testSimpleViaHostname(org.jboss.as.test.integration.security.ssl.sni.SNICombinedWithALPNTestCase) Time elapsed: 0.045 s <<< FAILURE!
org.junit.ComparisonFailure: expected:<Response sent:HTTP/[2.0]> but was:<Response sent:HTTP/[1.1]>
at org.junit.Assert.assertEquals(Assert.java:115)
at org.junit.Assert.assertEquals(Assert.java:144)
at org.jboss.as.test.integration.security.ssl.sni.SNICombinedWithALPNTestCase.performSimpleTest(SNICombinedWithALPNTestCase.java:273)
at org.jboss.as.test.integration.security.ssl.sni.SNICombinedWithALPNTestCase.testSimpleViaHostname(SNICombinedWithALPNTestCase.java:220)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
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.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.wildfly.core.testrunner.WildflyTestRunner.run(WildflyTestRunner.java:157)
at org.junit.runners.Suite.runChild(Suite.java:128)
at org.junit.runners.Suite.runChild(Suite.java:27)
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.apache.maven.surefire.junitcore.JUnitCore.run(JUnitCore.java:55)
at org.apache.maven.surefire.junitcore.JUnitCoreWrapper.createRequestAndRun(JUnitCoreWrapper.java:137)
at org.apache.maven.surefire.junitcore.JUnitCoreWrapper.executeEager(JUnitCoreWrapper.java:107)
at org.apache.maven.surefire.junitcore.JUnitCoreWrapper.execute(JUnitCoreWrapper.java:83)
at org.apache.maven.surefire.junitcore.JUnitCoreWrapper.execute(JUnitCoreWrapper.java:75)
at org.apache.maven.surefire.junitcore.JUnitCoreProvider.invoke(JUnitCoreProvider.java:158)
at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:384)
at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:345)
at org.apache.maven.surefire.booter.ForkedBooter.execute(ForkedBooter.java:126)
at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:418)
...
{code}
> SNICombinedWithALPNTestCase fails with oracle JDK 8 261
> -------------------------------------------------------
>
> Key: WFCORE-5133
> URL: https://issues.redhat.com/browse/WFCORE-5133
> Project: WildFly Core
> Issue Type: Bug
> Components: Security
> Reporter: Jean Francois Denise
> Assignee: Sonia Zaldana
> Priority: Major
>
> Exception while using oracle JDK 261:
>
> {{at io.undertow.client.http.HttpClientConnection.handleError(HttpClientConnection.java:444)
> at io.undertow.client.http.HttpClientConnection.handleError(HttpClientConnection.java:439)
> at io.undertow.client.http.HttpClientConnection.initiateRequest(HttpClientConnection.java:430)
> at io.undertow.client.http.HttpClientConnection.sendRequest(HttpClientConnection.java:347)
> at org.jboss.as.test.integration.security.ssl.sni.SNICombinedWithALPNTestCase.performSimpleTest(SNICombinedWithALPNTestCase.java:242)
> at org.jboss.as.test.integration.security.ssl.sni.SNICombinedWithALPNTestCase.testSimpleViaHostname(SNICombinedWithALPNTestCase.java:220)}}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 2 months
[JBoss JIRA] (WFLY-13897) infinispan-server instances provisioned by testsuite never shutdown
by Radoslav Husar (Jira)
[ https://issues.redhat.com/browse/WFLY-13897?page=com.atlassian.jira.plugi... ]
Radoslav Husar edited comment on WFLY-13897 at 9/29/20 4:25 PM:
----------------------------------------------------------------
There seem to be couple of problems at play here:
1. The graceful shutdown doesn't work because the client doesn't authenticate, because there is no such configuration - Jira TBA.
2. When graceful shutdown doesn't success, PID is not obtained on JDK8 – fix ISPN-12366.
3. When PID is obtained on JDK11, the kill command is incorrect - fix ISPN-12368.
4. If that is fixed - the kill command only kills the parent process (sh) and not the child process (java = the server) - fix ISPN-12368
was (Author: rhusar):
There seem to be couple of problems at play here:
1. The graceful shutdown doesn't work because the client doesn't authenticate, because there is no such configuration - Jira TBA.
2. When graceful shutdown doesn't success, PID is not obtained on JDK8 – also caused by ISPN-12366.
3. When PID is obtained on JDK11, the kill command is incorrect.
4. If that is fixed - the kill command only kills the parent process (sh) and not the child process (java = the server).
> infinispan-server instances provisioned by testsuite never shutdown
> -------------------------------------------------------------------
>
> Key: WFLY-13897
> URL: https://issues.redhat.com/browse/WFLY-13897
> Project: WildFly
> Issue Type: Bug
> Components: Clustering, Test Suite
> Affects Versions: 21.0.0.Beta1
> Reporter: Paul Ferraro
> Assignee: Radoslav Husar
> Priority: Critical
>
> Running the clustering testsuite locally leaves 9 instances of infinispan-server running. This wreaks havoc on the CI, which will remain running until the VM shuts down.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 2 months
[JBoss JIRA] (ELY-2024) Elytron server-ssl-context allowed protocols
by Sonia Zaldana (Jira)
[ https://issues.redhat.com/browse/ELY-2024?page=com.atlassian.jira.plugin.... ]
Sonia Zaldana updated ELY-2024:
-------------------------------
Description:
When JBoss EAP 7.2.7 is connecting to a third party client that is running on JDK 6 the following exception is logged:
{code:java}
javax.net.ssl.SSLHandshakeException: SSLv2Hello is disabled{code}
As I understand, SSLv2Hello is used in older JDK versions for the initial handshake message where the SSL version that will be used for the rest of the handshake is negotiated.
It is not possible to add SSLv2Hello to the list of protocols in server-ssl-context due to not being a valid value:
{code:java}
[standalone@localhost:9990 /] /subsystem=elytron/server-ssl-context=my-ssl-context:list-add(name=protocols, value=SSLv2Hello, index=0)
{
"outcome" => "failed",
"failure-description" => "WFLYCTL0129: Invalid value SSLv2Hello for protocols; legal values are [\"SSLv2\", \"SSLv3\", \"TLSv1\", \"TLSv1.1\", \"TLSv1.2\", \"TLSv1.3\"]",
"rolled-back" => true
}{code}
According to the undertow read-resource-description below, when server-ssl-context is configured in the Elytron subsystem, protocols must be defined in the server-ssl-context and not in the https connector in Undertow ("Where an SSLContext is references it should be configured with the supported protocols."):
{code:java}
/subsystem=undertow/server=default-server/https-listener=https/:read-resource-description(inherited=false,recursive=true,access-control=none)...
"enabled-protocols" => {
"type" => STRING,
"description" => "Configures SSL protocols",
"expressions-allowed" => true,
"required" => false,
"nillable" => true,
"alternatives" => ["ssl-context"],
"min-length" => 1L,
"max-length" => 2147483647L,
"deprecated" => {
"since" => "4.0.0",
"reason" => "Where an SSLContext is references it should be configured with the supported protocols."
},
"access-type" => "read-write",
"storage" => "configuration",
"restart-required" => "all-services"
},
...{code}
It is possible to add SSLv2Hello to the https connector in Undertow with legacy security as per.
was:
SSLv2Hello is used in older JDK versions for the initial handshake message where the SSL version that will be used for the rest of the handshake is negotiated.
It is not possible to add SSLv2Hello to the list of protocols in server-ssl-context due to not being a valid value:
{code:java}
[standalone@localhost:9990 /] /subsystem=elytron/server-ssl-context=my-ssl-context:list-add(name=protocols, value=SSLv2Hello, index=0)
{
"outcome" => "failed",
"failure-description" => "WFLYCTL0129: Invalid value SSLv2Hello for protocols; legal values are [\"SSLv2\", \"SSLv3\", \"TLSv1\", \"TLSv1.1\", \"TLSv1.2\", \"TLSv1.3\"]",
"rolled-back" => true
}{code}
It is possible to add SSLv2Hello to the https connector in Undertow with legacy security as per.
> Elytron server-ssl-context allowed protocols
> --------------------------------------------
>
> Key: ELY-2024
> URL: https://issues.redhat.com/browse/ELY-2024
> Project: WildFly Elytron
> Issue Type: Feature Request
> Reporter: Sonia Zaldana
> Assignee: Sonia Zaldana
> Priority: Major
>
> When JBoss EAP 7.2.7 is connecting to a third party client that is running on JDK 6 the following exception is logged:
> {code:java}
>
> javax.net.ssl.SSLHandshakeException: SSLv2Hello is disabled{code}
> As I understand, SSLv2Hello is used in older JDK versions for the initial handshake message where the SSL version that will be used for the rest of the handshake is negotiated.
> It is not possible to add SSLv2Hello to the list of protocols in server-ssl-context due to not being a valid value:
> {code:java}
> [standalone@localhost:9990 /] /subsystem=elytron/server-ssl-context=my-ssl-context:list-add(name=protocols, value=SSLv2Hello, index=0)
> {
> "outcome" => "failed",
> "failure-description" => "WFLYCTL0129: Invalid value SSLv2Hello for protocols; legal values are [\"SSLv2\", \"SSLv3\", \"TLSv1\", \"TLSv1.1\", \"TLSv1.2\", \"TLSv1.3\"]",
> "rolled-back" => true
> }{code}
> According to the undertow read-resource-description below, when server-ssl-context is configured in the Elytron subsystem, protocols must be defined in the server-ssl-context and not in the https connector in Undertow ("Where an SSLContext is references it should be configured with the supported protocols."):
> {code:java}
> /subsystem=undertow/server=default-server/https-listener=https/:read-resource-description(inherited=false,recursive=true,access-control=none)...
> "enabled-protocols" => {
> "type" => STRING,
> "description" => "Configures SSL protocols",
> "expressions-allowed" => true,
> "required" => false,
> "nillable" => true,
> "alternatives" => ["ssl-context"],
> "min-length" => 1L,
> "max-length" => 2147483647L,
> "deprecated" => {
> "since" => "4.0.0",
> "reason" => "Where an SSLContext is references it should be configured with the supported protocols."
> },
> "access-type" => "read-write",
> "storage" => "configuration",
> "restart-required" => "all-services"
> },
> ...{code}
> It is possible to add SSLv2Hello to the https connector in Undertow with legacy security as per.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 2 months
[JBoss JIRA] (WFCORE-5145) Elytron server-ssl-context allowed protocols
by Sonia Zaldana (Jira)
[ https://issues.redhat.com/browse/WFCORE-5145?page=com.atlassian.jira.plug... ]
Sonia Zaldana updated WFCORE-5145:
----------------------------------
Description:
When JBoss EAP 7.2.7 is connecting to a third party client that is running on JDK 6 the following exception is logged:
{code:java}
javax.net.ssl.SSLHandshakeException: SSLv2Hello is disabled{code}
As I understand, SSLv2Hello is used in older JDK versions for the initial handshake message where the SSL version that will be used for the rest of the handshake is negotiated.
It is not possible to add SSLv2Hello to the list of protocols in server-ssl-context due to not being a valid value:
{code:java}
[standalone@localhost:9990 /] /subsystem=elytron/server-ssl-context=my-ssl-context:list-add(name=protocols, value=SSLv2Hello, index=0)
{
"outcome" => "failed",
"failure-description" => "WFLYCTL0129: Invalid value SSLv2Hello for protocols; legal values are [\"SSLv2\", \"SSLv3\", \"TLSv1\", \"TLSv1.1\", \"TLSv1.2\", \"TLSv1.3\"]",
"rolled-back" => true
}{code}
According to the undertow read-resource-description below, when server-ssl-context is configured in the Elytron subsystem, protocols must be defined in the server-ssl-context and not in the https connector in Undertow ("Where an SSLContext is references it should be configured with the supported protocols."):
{code:java}
/subsystem=undertow/server=default-server/https-listener=https/:read-resource-description(inherited=false,recursive=true,access-control=none)...
"enabled-protocols" => {
"type" => STRING,
"description" => "Configures SSL protocols",
"expressions-allowed" => true,
"required" => false,
"nillable" => true,
"alternatives" => ["ssl-context"],
"min-length" => 1L,
"max-length" => 2147483647L,
"deprecated" => {
"since" => "4.0.0",
"reason" => "Where an SSLContext is references it should be configured with the supported protocols."
},
"access-type" => "read-write",
"storage" => "configuration",
"restart-required" => "all-services"
},
...{code}
It is possible to add SSLv2Hello to the https connector in Undertow with legacy security as per.
was:
SSLv2Hello is used in older JDK versions for the initial handshake message where the SSL version that will be used for the rest of the handshake is negotiated.
It is not possible to add SSLv2Hello to the list of protocols in server-ssl-context due to not being a valid value:
{code:java}
[standalone@localhost:9990 /] /subsystem=elytron/server-ssl-context=my-ssl-context:list-add(name=protocols, value=SSLv2Hello, index=0)
{
"outcome" => "failed",
"failure-description" => "WFLYCTL0129: Invalid value SSLv2Hello for protocols; legal values are [\"SSLv2\", \"SSLv3\", \"TLSv1\", \"TLSv1.1\", \"TLSv1.2\", \"TLSv1.3\"]",
"rolled-back" => true
}{code}
It is possible to add SSLv2Hello to the https connector in Undertow with legacy security as per.
> Elytron server-ssl-context allowed protocols
> --------------------------------------------
>
> Key: WFCORE-5145
> URL: https://issues.redhat.com/browse/WFCORE-5145
> Project: WildFly Core
> Issue Type: Feature Request
> Reporter: Sonia Zaldana
> Assignee: Sonia Zaldana
> Priority: Major
>
> When JBoss EAP 7.2.7 is connecting to a third party client that is running on JDK 6 the following exception is logged:
> {code:java}
>
> javax.net.ssl.SSLHandshakeException: SSLv2Hello is disabled{code}
> As I understand, SSLv2Hello is used in older JDK versions for the initial handshake message where the SSL version that will be used for the rest of the handshake is negotiated.
> It is not possible to add SSLv2Hello to the list of protocols in server-ssl-context due to not being a valid value:
> {code:java}
> [standalone@localhost:9990 /] /subsystem=elytron/server-ssl-context=my-ssl-context:list-add(name=protocols, value=SSLv2Hello, index=0)
> {
> "outcome" => "failed",
> "failure-description" => "WFLYCTL0129: Invalid value SSLv2Hello for protocols; legal values are [\"SSLv2\", \"SSLv3\", \"TLSv1\", \"TLSv1.1\", \"TLSv1.2\", \"TLSv1.3\"]",
> "rolled-back" => true
> }{code}
> According to the undertow read-resource-description below, when server-ssl-context is configured in the Elytron subsystem, protocols must be defined in the server-ssl-context and not in the https connector in Undertow ("Where an SSLContext is references it should be configured with the supported protocols."):
> {code:java}
> /subsystem=undertow/server=default-server/https-listener=https/:read-resource-description(inherited=false,recursive=true,access-control=none)...
> "enabled-protocols" => {
> "type" => STRING,
> "description" => "Configures SSL protocols",
> "expressions-allowed" => true,
> "required" => false,
> "nillable" => true,
> "alternatives" => ["ssl-context"],
> "min-length" => 1L,
> "max-length" => 2147483647L,
> "deprecated" => {
> "since" => "4.0.0",
> "reason" => "Where an SSLContext is references it should be configured with the supported protocols."
> },
> "access-type" => "read-write",
> "storage" => "configuration",
> "restart-required" => "all-services"
> },
> ...{code}
> It is possible to add SSLv2Hello to the https connector in Undertow with legacy security as per.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 2 months
[JBoss JIRA] (WFLY-13916) Elytron server-ssl-context allowed protocols
by Sonia Zaldana (Jira)
[ https://issues.redhat.com/browse/WFLY-13916?page=com.atlassian.jira.plugi... ]
Sonia Zaldana updated WFLY-13916:
---------------------------------
Description:
When JBoss EAP 7.2.7 is connecting to a third party client that is running on JDK 6 the following exception is logged:
{code:java}
javax.net.ssl.SSLHandshakeException: SSLv2Hello is disabled{code}
As I understand, SSLv2Hello is used in older JDK versions for the initial handshake message where the SSL version that will be used for the rest of the handshake is negotiated.
It is not possible to add SSLv2Hello to the list of protocols in server-ssl-context due to not being a valid value:
{code:java}
[standalone@localhost:9990 /] /subsystem=elytron/server-ssl-context=my-ssl-context:list-add(name=protocols, value=SSLv2Hello, index=0)
{
"outcome" => "failed",
"failure-description" => "WFLYCTL0129: Invalid value SSLv2Hello for protocols; legal values are [\"SSLv2\", \"SSLv3\", \"TLSv1\", \"TLSv1.1\", \"TLSv1.2\", \"TLSv1.3\"]",
"rolled-back" => true
}{code}
According to the undertow read-resource-description below, when server-ssl-context is configured in the Elytron subsystem, protocols must be defined in the server-ssl-context and not in the https connector in Undertow ("Where an SSLContext is references it should be configured with the supported protocols."):
{code:java}
/subsystem=undertow/server=default-server/https-listener=https/:read-resource-description(inherited=false,recursive=true,access-control=none)...
"enabled-protocols" => {
"type" => STRING,
"description" => "Configures SSL protocols",
"expressions-allowed" => true,
"required" => false,
"nillable" => true,
"alternatives" => ["ssl-context"],
"min-length" => 1L,
"max-length" => 2147483647L,
"deprecated" => {
"since" => "4.0.0",
"reason" => "Where an SSLContext is references it should be configured with the supported protocols."
},
"access-type" => "read-write",
"storage" => "configuration",
"restart-required" => "all-services"
},
...{code}
It is possible to add SSLv2Hello to the https connector in Undertow with legacy security as per.
was:
SSLv2Hello is used in older JDK versions for the initial handshake message where the SSL version that will be used for the rest of the handshake is negotiated.
It is not possible to add SSLv2Hello to the list of protocols in server-ssl-context due to not being a valid value:
{code:java}
[standalone@localhost:9990 /] /subsystem=elytron/server-ssl-context=my-ssl-context:list-add(name=protocols, value=SSLv2Hello, index=0)
{
"outcome" => "failed",
"failure-description" => "WFLYCTL0129: Invalid value SSLv2Hello for protocols; legal values are [\"SSLv2\", \"SSLv3\", \"TLSv1\", \"TLSv1.1\", \"TLSv1.2\", \"TLSv1.3\"]",
"rolled-back" => true
}{code}
It is possible to add SSLv2Hello to the https connector in Undertow with legacy security as per.
> Elytron server-ssl-context allowed protocols
> --------------------------------------------
>
> Key: WFLY-13916
> URL: https://issues.redhat.com/browse/WFLY-13916
> Project: WildFly
> Issue Type: Feature Request
> Reporter: Sonia Zaldana
> Assignee: Sonia Zaldana
> Priority: Major
>
> When JBoss EAP 7.2.7 is connecting to a third party client that is running on JDK 6 the following exception is logged:
> {code:java}
>
> javax.net.ssl.SSLHandshakeException: SSLv2Hello is disabled{code}
> As I understand, SSLv2Hello is used in older JDK versions for the initial handshake message where the SSL version that will be used for the rest of the handshake is negotiated.
> It is not possible to add SSLv2Hello to the list of protocols in server-ssl-context due to not being a valid value:
> {code:java}
> [standalone@localhost:9990 /] /subsystem=elytron/server-ssl-context=my-ssl-context:list-add(name=protocols, value=SSLv2Hello, index=0)
> {
> "outcome" => "failed",
> "failure-description" => "WFLYCTL0129: Invalid value SSLv2Hello for protocols; legal values are [\"SSLv2\", \"SSLv3\", \"TLSv1\", \"TLSv1.1\", \"TLSv1.2\", \"TLSv1.3\"]",
> "rolled-back" => true
> }{code}
> According to the undertow read-resource-description below, when server-ssl-context is configured in the Elytron subsystem, protocols must be defined in the server-ssl-context and not in the https connector in Undertow ("Where an SSLContext is references it should be configured with the supported protocols."):
> {code:java}
> /subsystem=undertow/server=default-server/https-listener=https/:read-resource-description(inherited=false,recursive=true,access-control=none)...
> "enabled-protocols" => {
> "type" => STRING,
> "description" => "Configures SSL protocols",
> "expressions-allowed" => true,
> "required" => false,
> "nillable" => true,
> "alternatives" => ["ssl-context"],
> "min-length" => 1L,
> "max-length" => 2147483647L,
> "deprecated" => {
> "since" => "4.0.0",
> "reason" => "Where an SSLContext is references it should be configured with the supported protocols."
> },
> "access-type" => "read-write",
> "storage" => "configuration",
> "restart-required" => "all-services"
> },
> ...{code}
> It is possible to add SSLv2Hello to the https connector in Undertow with legacy security as per.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 2 months
[JBoss JIRA] (WFLY-13916) Elytron server-ssl-context allowed protocols
by Sonia Zaldana (Jira)
[ https://issues.redhat.com/browse/WFLY-13916?page=com.atlassian.jira.plugi... ]
Sonia Zaldana updated WFLY-13916:
---------------------------------
Description:
SSLv2Hello is used in older JDK versions for the initial handshake message where the SSL version that will be used for the rest of the handshake is negotiated.
It is not possible to add SSLv2Hello to the list of protocols in server-ssl-context due to not being a valid value:
{code:java}
[standalone@localhost:9990 /] /subsystem=elytron/server-ssl-context=my-ssl-context:list-add(name=protocols, value=SSLv2Hello, index=0)
{
"outcome" => "failed",
"failure-description" => "WFLYCTL0129: Invalid value SSLv2Hello for protocols; legal values are [\"SSLv2\", \"SSLv3\", \"TLSv1\", \"TLSv1.1\", \"TLSv1.2\", \"TLSv1.3\"]",
"rolled-back" => true
}{code}
It is possible to add SSLv2Hello to the https connector in Undertow with legacy security as per.
> Elytron server-ssl-context allowed protocols
> --------------------------------------------
>
> Key: WFLY-13916
> URL: https://issues.redhat.com/browse/WFLY-13916
> Project: WildFly
> Issue Type: Feature Request
> Reporter: Sonia Zaldana
> Assignee: Sonia Zaldana
> Priority: Major
>
> SSLv2Hello is used in older JDK versions for the initial handshake message where the SSL version that will be used for the rest of the handshake is negotiated.
> It is not possible to add SSLv2Hello to the list of protocols in server-ssl-context due to not being a valid value:
> {code:java}
> [standalone@localhost:9990 /] /subsystem=elytron/server-ssl-context=my-ssl-context:list-add(name=protocols, value=SSLv2Hello, index=0)
> {
> "outcome" => "failed",
> "failure-description" => "WFLYCTL0129: Invalid value SSLv2Hello for protocols; legal values are [\"SSLv2\", \"SSLv3\", \"TLSv1\", \"TLSv1.1\", \"TLSv1.2\", \"TLSv1.3\"]",
> "rolled-back" => true
> }{code}
>
> It is possible to add SSLv2Hello to the https connector in Undertow with legacy security as per.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 2 months
[JBoss JIRA] (ELY-2024) Elytron server-ssl-context allowed protocols
by Sonia Zaldana (Jira)
[ https://issues.redhat.com/browse/ELY-2024?page=com.atlassian.jira.plugin.... ]
Sonia Zaldana updated ELY-2024:
-------------------------------
Description:
SSLv2Hello is used in older JDK versions for the initial handshake message where the SSL version that will be used for the rest of the handshake is negotiated.
It is not possible to add SSLv2Hello to the list of protocols in server-ssl-context due to not being a valid value:
{code:java}
[standalone@localhost:9990 /] /subsystem=elytron/server-ssl-context=my-ssl-context:list-add(name=protocols, value=SSLv2Hello, index=0)
{
"outcome" => "failed",
"failure-description" => "WFLYCTL0129: Invalid value SSLv2Hello for protocols; legal values are [\"SSLv2\", \"SSLv3\", \"TLSv1\", \"TLSv1.1\", \"TLSv1.2\", \"TLSv1.3\"]",
"rolled-back" => true
}{code}
It is possible to add SSLv2Hello to the https connector in Undertow with legacy security as per.
was:It is possible to add SSLv2Hello to the https connector in Undertow with legacy security as per.
> Elytron server-ssl-context allowed protocols
> --------------------------------------------
>
> Key: ELY-2024
> URL: https://issues.redhat.com/browse/ELY-2024
> Project: WildFly Elytron
> Issue Type: Feature Request
> Reporter: Sonia Zaldana
> Assignee: Sonia Zaldana
> Priority: Major
>
> SSLv2Hello is used in older JDK versions for the initial handshake message where the SSL version that will be used for the rest of the handshake is negotiated.
> It is not possible to add SSLv2Hello to the list of protocols in server-ssl-context due to not being a valid value:
> {code:java}
> [standalone@localhost:9990 /] /subsystem=elytron/server-ssl-context=my-ssl-context:list-add(name=protocols, value=SSLv2Hello, index=0)
> {
> "outcome" => "failed",
> "failure-description" => "WFLYCTL0129: Invalid value SSLv2Hello for protocols; legal values are [\"SSLv2\", \"SSLv3\", \"TLSv1\", \"TLSv1.1\", \"TLSv1.2\", \"TLSv1.3\"]",
> "rolled-back" => true
> }{code}
>
> It is possible to add SSLv2Hello to the https connector in Undertow with legacy security as per.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 2 months
[JBoss JIRA] (WFCORE-5145) Elytron server-ssl-context allowed protocols
by Sonia Zaldana (Jira)
[ https://issues.redhat.com/browse/WFCORE-5145?page=com.atlassian.jira.plug... ]
Sonia Zaldana updated WFCORE-5145:
----------------------------------
Description:
SSLv2Hello is used in older JDK versions for the initial handshake message where the SSL version that will be used for the rest of the handshake is negotiated.
It is not possible to add SSLv2Hello to the list of protocols in server-ssl-context due to not being a valid value:
{code:java}
[standalone@localhost:9990 /] /subsystem=elytron/server-ssl-context=my-ssl-context:list-add(name=protocols, value=SSLv2Hello, index=0)
{
"outcome" => "failed",
"failure-description" => "WFLYCTL0129: Invalid value SSLv2Hello for protocols; legal values are [\"SSLv2\", \"SSLv3\", \"TLSv1\", \"TLSv1.1\", \"TLSv1.2\", \"TLSv1.3\"]",
"rolled-back" => true
}{code}
It is possible to add SSLv2Hello to the https connector in Undertow with legacy security as per.
> Elytron server-ssl-context allowed protocols
> --------------------------------------------
>
> Key: WFCORE-5145
> URL: https://issues.redhat.com/browse/WFCORE-5145
> Project: WildFly Core
> Issue Type: Feature Request
> Reporter: Sonia Zaldana
> Assignee: Sonia Zaldana
> Priority: Major
>
> SSLv2Hello is used in older JDK versions for the initial handshake message where the SSL version that will be used for the rest of the handshake is negotiated.
> It is not possible to add SSLv2Hello to the list of protocols in server-ssl-context due to not being a valid value:
> {code:java}
> [standalone@localhost:9990 /] /subsystem=elytron/server-ssl-context=my-ssl-context:list-add(name=protocols, value=SSLv2Hello, index=0)
> {
> "outcome" => "failed",
> "failure-description" => "WFLYCTL0129: Invalid value SSLv2Hello for protocols; legal values are [\"SSLv2\", \"SSLv3\", \"TLSv1\", \"TLSv1.1\", \"TLSv1.2\", \"TLSv1.3\"]",
> "rolled-back" => true
> }{code}
>
> It is possible to add SSLv2Hello to the https connector in Undertow with legacy security as per.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 2 months