Uploaded image for project: 'JBoss Enterprise Application Platform'
  1. JBoss Enterprise Application Platform
  2. JBEAP-20993

(7.4.0) SSL handshake fails on JDK 11.0.10

XMLWordPrintable

    • Icon: Bug Bug
    • Resolution: Done
    • Icon: Critical Critical
    • 7.4.0.GA
    • 7.3.5.GA, 7.3.6.GA, 7.4.0.Beta
    • Productization, Undertow
    • None
    • False
    • False
    • Undefined
    • Workaround Exists
    • Hide

      Use the system property 

      jdk.tls.namedGroups="secp256r1, secp384r1, secp521r1, ffdhe2048, ffdhe3072, ffdhe4096, ffdhe6144, ffdhe8192"
      Show
      Use the system property jdk.tls.namedGroups= "secp256r1, secp384r1, secp521r1, ffdhe2048, ffdhe3072, ffdhe4096, ffdhe6144, ffdhe8192"
    • Hide

      Issue can be reproduced by running WSTrustTestCase from the server integration suite

      Show
      Issue can be reproduced by running WSTrustTestCase from the server integration suite

      It's basically the same issue as https://github.com/bcgit/bc-java/issues/589

      JDK 11.0.10 introduced support for X25519 and X448 in TLS which is handled by Bouncy Castle by providing version specific classes in a multi-release jar. The issue is that our redhat jars are not built as multi-release, so during the handshake we're getting:

      

javax.net.ssl.SSLException: closing inbound before receiving peer's close_notify
at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:133)
at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:117)
at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:339)
at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:295)
at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:286)
at java.base/sun.security.ssl.SSLEngineImpl.closeInbound(SSLEngineImpl.java:733)
at io.undertow.core@2.0.33.SP2-redhat-00001//io.undertow.protocols.ssl.SslConduit.notifyReadClosed(SslC
at io.undertow.core@2.0.33.SP2-redhat-00001//io.undertow.protocols.ssl.SslConduit.closed(SslConduit.jav
at io.undertow.core@2.0.33.SP2-redhat-00001//io.undertow.protocols.ssl.SslConduit.close(SslConduit.java
at io.undertow.core@2.0.33.SP2-redhat-00001//io.undertow.protocols.ssl.SslConduit.doUnwrap(SslConduit.j
at io.undertow.core@2.0.33.SP2-redhat-00001//io.undertow.protocols.ssl.SslConduit.doHandshake(SslCondui
at io.undertow.core@2.0.33.SP2-redhat-00001//io.undertow.protocols.ssl.SslConduit.access$900(SslConduit
at io.undertow.core@2.0.33.SP2-redhat-00001//io.undertow.protocols.ssl.SslConduit$5$1.run(SslConduit.ja
at org.jboss.xnio.nio@3.7.12.Final-redhat-00001//org.xnio.nio.WorkerThread.safeRun(WorkerThread.java:61
at org.jboss.xnio.nio@3.7.12.Final-redhat-00001//org.xnio.nio.WorkerThread.run(WorkerThread.java:479)}

       
      which is caused by

      java.lang.ClassCastException: class org.bouncycastle.jcajce.provider.asymmetric.edec.BCXDHPublicKey cannot be cast to class java.security.interfaces.XECPublicKey (org.bouncycastle.jcajce.provider.asymmetric.edec.BCXDHPublicKey is in unnamed module of loader 'org.bouncycastle@1.65.0.redhat-00001' @578de4d9; java.security.interfaces.XECPublicKey is in module java.base of loader 'bootstrap')

      We'll need to rebuild BC as a multi-release jar and do a component upgrade.

              dkreling Daniel Kreling
              pjelinek@redhat.com Pavel Jelinek
              Votes:
              0 Vote for this issue
              Watchers:
              4 Start watching this issue

                Created:
                Updated:
                Resolved: