Info about JDK used: $ /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) Legacy Security Realm unzip the WildFly start the server with proper JDK JAVA_HOME=/home/jstourac/jdks/jdk1.8.0_261 ./wildfly-20.0.0.Final/bin/standalone.sh wait till server boots up and perform an HTTP request (note that curl with HTTP2 support has to be used, otherwise use different client) curl -k https: //localhost:8443 -vvv >/dev/ null see that HTTP/1.1 is used only; there is also this message in the output ALPN, server did not agree to a protocol Now workaround: unzip the WildFly start the server with proper JDK and property from UNDERTOW-1726 JAVA_HOME=/home/jstourac/jdks/jdk1.8.0_261 ./wildfly-20.0.0.Final/bin/standalone.sh -Dio.undertow.protocols.alpn.jdk8 wait till server boots up and perform an HTTP request curl -k https: //localhost:8443 -vvv >/dev/ null see that HTTP/2 is used successfully now 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: /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 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. 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: /subsystem=elytron/server-ssl-context=test:write-attribute(name=wrap, value= true ) If the server is restarted with or without the system property ALPN is not available.