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

[QE](7.3.z) SSL handshake fails on JDK 11.0.10

    XMLWordPrintable

Details

    • 10
    • 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

    Description

      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(SslConduit
      at io.undertow.core@2.0.33.SP2-redhat-00001//io.undertow.protocols.ssl.SslConduit.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.

      Attachments

        Issue Links

          Activity

            People

              dkreling Daniel Kreling
              pmackay@redhat.com Peter Mackay
              Votes:
              0 Vote for this issue
              Watchers:
              10 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: