[
https://issues.redhat.com/browse/WFLY-13924?page=com.atlassian.jira.plugi...
]
Darran Lofthouse updated WFLY-13924:
------------------------------------
Steps to Reproduce:
Info about JDK used:
{code}
$ /home/jstourac/jdks/jdk1.8.0_261/bin/java -version
java version "1.8.0_261"
Java(TM) SE Runtime Environment (build 1.8.0_261-b12)
Java HotSpot(TM) 64-Bit Server VM (build 25.261-b12, mixed mode)
{code}
h2. Legacy Security Realm
# unzip the WildFly
# start the server with proper JDK
{code}
JAVA_HOME=/home/jstourac/jdks/jdk1.8.0_261 ./wildfly-20.0.0.Final/bin/standalone.sh
{code}
# wait till server boots up and perform an HTTP request (note that curl with HTTP2 support
has to be used, otherwise use different client)
{code}
curl -k
https://localhost:8443 -vvv >/dev/null
{code}
# see that HTTP/1.1 is used only; there is also this message in the output
{quote}
* ALPN, server did not agree to a protocol
{quote}
Now workaround:
# unzip the WildFly
# start the server with proper JDK and property from UNDERTOW-1726
{code}
JAVA_HOME=/home/jstourac/jdks/jdk1.8.0_261 ./wildfly-20.0.0.Final/bin/standalone.sh
-Dio.undertow.protocols.alpn.jdk8
{code}
# wait till server boots up and perform an HTTP request
{code}
curl -k
https://localhost:8443 -vvv >/dev/null
{code}
# see that HTTP/2 is used successfully now
h2. Unwrapped Elytron Configuration
This step needs to be run AFTER the first step so the default self signed certificate is
pre-generated.
Execute the following CLI commands to switch to an Elytron SSLContext:
{code}
/subsystem=elytron/key-store=test:add(relative-to=jboss.server.config.dir,
path=application.keystore, credential-reference={clear-text=password})
/subsystem=elytron/key-manager=test:add(key-store=test,
credential-reference={clear-text=password})
/subsystem=elytron/server-ssl-context=test:add(key-manager=test)
batch
/subsystem=undertow/server=default-server/https-listener=https:undefine-attribute(name=security-realm)
/subsystem=undertow/server=default-server/https-listener=https:write-attribute(name=ssl-context,
value=test)
run-batch
{code}
The same curl command can be used to test the establishment of a HTTPS connection.
Using the system property -Dio.undertow.protocols.alpn.jdk8 again restores the ability to
use ALPN.
h2. Wrapped Elytron Configuration
_It was always preferred that the Elytron subsystem would wrap the SSLContext to prevent
against unintended modification but we had to drop to unwrapping to support the JDK 8 hack
needed for ALPN._
This third test should be executed after the previous test as it is a continuation of the
configuration.
Execute the following CLI to ensure the SSLContext is wrapped:
{code}
/subsystem=elytron/server-ssl-context=test:write-attribute(name=wrap, value=true)
{code}
If the server is restarted with or without the system property ALPN is not available.
was:
Info about JDK used:
{code}
$ /home/jstourac/jdks/jdk1.8.0_261/bin/java -version
java version "1.8.0_261"
Java(TM) SE Runtime Environment (build 1.8.0_261-b12)
Java HotSpot(TM) 64-Bit Server VM (build 25.261-b12, mixed mode)
{code}
# unzip the WildFly
# start the server with proper JDK
{code}
JAVA_HOME=/home/jstourac/jdks/jdk1.8.0_261 ./wildfly-20.0.0.Final/bin/standalone.sh
{code}
# wait till server boots up and perform an HTTP request (note that curl with HTTP2 support
has to be used, otherwise use different client)
{code}
curl -k
https://localhost:8443 -vvv >/dev/null
{code}
# see that HTTP/1.1 is used only; there is also this message in the output
{quote}
* ALPN, server did not agree to a protocol
{quote}
Now workaround:
# unzip the WildFly
# start the server with proper JDK and property from UNDERTOW-1726
{code}
JAVA_HOME=/home/jstourac/jdks/jdk1.8.0_261 ./wildfly-20.0.0.Final/bin/standalone.sh
-Dio.undertow.protocols.alpn.jdk8
{code}
# wait till server boots up and perform an HTTP request
{code}
curl -k
https://localhost:8443 -vvv >/dev/null
{code}
# see that HTTP/2 is used successfully now
HTTP2 is not working with Oracle JDK8 u261
------------------------------------------
Key: WFLY-13924
URL:
https://issues.redhat.com/browse/WFLY-13924
Project: WildFly
Issue Type: Bug
Components: Security, Web (Undertow)
Affects Versions: 20.0.0.Final, 20.0.1.Final, 21.0.0.Beta1
Reporter: Jan Stourac
Assignee: Flavia Rainone
Priority: Blocker
Fix For: 21.0.0.Final
There seems to be some problem with HTTP2 support with new Oracle JDK8 u261 and WildFly
since {{20.0.0.Final}} version. When request against server is executed, then HTTP2 is not
established and communication remains via HTTP/1.1.
There is no such issue when I use {{WildFly 19.0.0.Final}}. Also, if I switch back to
an older Oracle JDK8 u241, there is no such issue even with newer WildFly versions.
This all seems to be tied with backport of ALPN support into the Oracle JDK8 recently and
also work in following issue UNDERTOW-1726.
There seems to be a workaround available - to define
'-Dio.undertow.protocols.alpn.jdk8' during the server startup. With this property
configured, the issue seems to disappear (as such, blocker priority of this may be
discussed).
*What is the issue here:*
This is a change in default behavior of the server (HTTP2 not working with Oracle
JDK8u261+ since WildFly 20.0.0.Final). We should try to resolve this without default
behavior change if possible. Only in case there is really no other solution, we need to
document such thing.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)