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

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

    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: