SSL:HandShakeError:WebMethods10.11Connecting to JDK8 Servers

Hello Experts,
We had our WebMethods 10.1 upgraded to 10.11 .
The upgrades have been smooth and we where able to pass most of the testing.
We have seen ONE case where the request from 10.11 fails with ‘com.wm.app.b2b.server.ServiceException: javax.net.ssl.SSLHandshakeException: Remote host terminated the handshake’ where as the same identical piece of code works in 10.1 .
After debugging, we have found that there is an issue with the requests going from Java11 [webm10.11 uses] is being failed at the target server [webLogic - Java 8] with the below error


<Aug 23, 2022 11:44:04,291 AM GMT+03:00> <Debug> <SecuritySSL> <BEA-000000> <[Thread[ExecuteThread: '2' for queue: 'weblogic.socket.Muxer',5,Thread Group for Queue: 'weblogic.socket.Muxer']]weblogic.security.SSL.jsseadapter: SSLENGINE: Exception occurred during SSLEngine.wrap(ByteBuffer,ByteBuffer).
java.lang.NullPointerException
        at org.bouncycastle.crypto.signers.PSSSigner.generateSignature(Unknown Source)
        at org.bouncycastle.jcajce.provider.asymmetric.rsa.PSSSignatureSpi.engineSign(Unknown Source)
        at java.security.Signature$Delegate.engineSign(Signature.java:1382)
        at java.security.Signature.sign(Signature.java:698)
        at sun.security.ssl.CertificateVerify$T13CertificateVerifyMessage.<init>(CertificateVerify.java:933)
        at sun.security.ssl.CertificateVerify$T13CertificateVerifyProducer.onProduceCertificateVerify(CertificateVerify.java:1107)
        at sun.security.ssl.CertificateVerify$T13CertificateVerifyProducer.produce(CertificateVerify.java:1100)
        at sun.security.ssl.SSLHandshake.produce(SSLHandshake.java:420)
        at sun.security.ssl.ClientHello$T13ClientHelloConsumer.goServerHello(ClientHello.java:1085)
        at sun.security.ssl.ClientHello$T13ClientHelloConsumer.consume(ClientHello.java:1021)
        at sun.security.ssl.ClientHello$ClientHelloConsumer.onClientHello(ClientHello.java:705)
        at sun.security.ssl.ClientHello$ClientHelloConsumer.consume(ClientHello.java:672)
        at sun.security.ssl.SSLHandshake.consume(SSLHandshake.java:376)
        at sun.security.ssl.HandshakeContext.dispatch(HandshakeContext.java:479)
        at sun.security.ssl.SSLEngineImpl$DelegatedTask$DelegatedAction.run(SSLEngineImpl.java:990)
        at sun.security.ssl.SSLEngineImpl$DelegatedTask$DelegatedAction.run(SSLEngineImpl.java:977)
        at java.security.AccessController.doPrivileged(Native Method)
        at sun.security.ssl.SSLEngineImpl$DelegatedTask.run(SSLEngineImpl.java:924)
        at weblogic.socket.JSSEFilterImpl.doTasks(JSSEFilterImpl.java:223)
        at weblogic.socket.JSSEFilterImpl.doHandshake(JSSEFilterImpl.java:123)
        at weblogic.socket.JSSEFilterImpl.isMessageComplete(JSSEFilterImpl.java:354)
        at weblogic.socket.SocketMuxer.readReadySocketOnce(SocketMuxer.java:976)
        at weblogic.socket.SocketMuxer.readReadySocket(SocketMuxer.java:917)
        at weblogic.socket.NIOSocketMuxer.process(NIOSocketMuxer.java:599)
        at weblogic.socket.NIOSocketMuxer.processSockets(NIOSocketMuxer.java:563)
        at weblogic.socket.SocketReaderRequest.run(SocketReaderRequest.java:30)
        at weblogic.socket.SocketReaderRequest.execute(SocketReaderRequest.java:43)
        at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:147)
        at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:119)

Issue reported:

https://github.com/bcgit/bc-java/issues/633 [Bug Tracker]
https://bugs.openjdk.org/browse/JDK-8216039
https://bugs.openjdk.org/browse/JDK-8256076

The target system is on webLogic running on Java build 1.8.0_341-b10.

Now we have come across a stalemate, as most of our Backends/external systems are still working in Java 1.8 where as 10.11 is on Java11 [which breaks the integration ] .

Have anyone faced similar issue ?
Any advises/Workarounds?

Thanks

Hi Sajid,

looks like a mismatch in CipherSpecs or TLS version for me.

webM 10.11 tries to use a CipherSpec which is not yet known by Java 8.
When it come to the TLS version make sure that both parties can agree on TLS v1.2 as TLS v1.3 might no be available on Java 8 based systems.

Regards,
Holger