APAR status
Closed as program error.
Error description
A client application using the MQ Classes for JMS, when running on a non-IBM JRE, can generate a SunCertPathBuilderException during a TLS handshake, and thus failing to validate certificates. This can result in the following stack trace; [07/07/23 09:25:36.974.00] 00000001 PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target [javax.net.ssl.SSLHandshakeException] at: [07/07/23 09:25:36.974.00] 00000001 java.base/sun.security.ssl.Alert.createSSLException(Alert.java:1 31) [07/07/23 09:25:36.974.00] 00000001 java.base/sun.security.ssl.TransportContext.fatal(TransportConte xt.java:353) [07/07/23 09:25:36.974.00] 00000001 java.base/sun.security.ssl.TransportContext.fatal(TransportConte xt.java:296) [07/07/23 09:25:36.974.00] 00000001 java.base/sun.security.ssl.TransportContext.fatal(TransportConte xt.java:291) [07/07/23 09:25:36.974.00] 00000001 java.base/sun.security.ssl.CertificateMessage$T12CertificateCons umer.checkServerCerts(CertificateMessage.java:654) [07/07/23 09:25:36.974.00] 00000001 java.base/sun.security.ssl.CertificateMessage$T12CertificateCons umer.onCertificate(CertificateMessage.java:473) [07/07/23 09:25:36.974.00] 00000001 java.base/sun.security.ssl.CertificateMessage$T12CertificateCons umer.consume(CertificateMessage.java:369) [07/07/23 09:25:36.974.00] 00000001 java.base/sun.security.ssl.SSLHandshake.consume(SSLHandshake.jav a:392) [07/07/23 09:25:36.974.00] 00000001 java.base/sun.security.ssl.HandshakeContext.dispatch(HandshakeCo ntext.java:443) [07/07/23 09:25:36.974.00] 00000001 java.base/sun.security.ssl.HandshakeContext.dispatch(HandshakeCo ntext.java:421) [07/07/23 09:25:36.974.00] 00000001 java.base/sun.security.ssl.TransportContext.dispatch(TransportCo ntext.java:183) [07/07/23 09:25:36.974.00] 00000001 java.base/sun.security.ssl.SSLTransport.decode(SSLTransport.java :172) [07/07/23 09:25:36.974.00] 00000001 java.base/sun.security.ssl.SSLSocketImpl.decode(SSLSocketImpl.ja va:1507) [07/07/23 09:25:36.974.00] 00000001 java.base/sun.security.ssl.SSLSocketImpl.readHandshakeRecord(SSL SocketImpl.java:1417) [07/07/23 09:25:36.974.00] 00000001 java.base/sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocke tImpl.java:456) [07/07/23 09:25:36.974.00] 00000001 java.base/sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocke tImpl.java:427) Thus preventing the client application from performing a successful handshake with the server (Queue Manager).
Local fix
Problem summary
**************************************************************** USERS AFFECTED: This issue affects users of the MQ Classes for JMS who have applications running with a non-IBM JRE, utilising TLS. Platforms affected: MultiPlatform **************************************************************** PROBLEM DESCRIPTION: Traditionally there has been some differences between IBM JRE and other JRE vendors' naming for TLS cipher suites. As the IBM JRE has been updated, these differences have been removed, and thus the IBM JRE cipher suite mappings now align with other JRE vendors. However as this refactoring was made, the MQ Classes for JMS would always attempt to create an SSL_TLSv2 SSL Context regardless of the JRE being used. Thus, when running on a non-IBM JRE, the MQ Classes for JMS could generate a SunCertPathBuilderException during a TLS handshake, and thus failing to validate certificates. This could result in the following stack trace; [07/07/23 09:25:36.974.00] 00000001 PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target [javax.net.ssl.SSLHandshakeException] at: [07/07/23 09:25:36.974.00] 00000001 java.base/sun.security.ssl.Alert.createSSLException(Alert.java:1 31) [07/07/23 09:25:36.974.00] 00000001 java.base/sun.security.ssl.TransportContext.fatal(TransportConte xt.java:353) [07/07/23 09:25:36.974.00] 00000001 java.base/sun.security.ssl.TransportContext.fatal(TransportConte xt.java:296) [07/07/23 09:25:36.974.00] 00000001 java.base/sun.security.ssl.TransportContext.fatal(TransportConte xt.java:291) [07/07/23 09:25:36.974.00] 00000001 java.base/sun.security.ssl.CertificateMessage$T12CertificateCons umer.checkServerCerts(CertificateMessage.java:654) [07/07/23 09:25:36.974.00] 00000001 java.base/sun.security.ssl.CertificateMessage$T12CertificateCons umer.onCertificate(CertificateMessage.java:473) [07/07/23 09:25:36.974.00] 00000001 java.base/sun.security.ssl.CertificateMessage$T12CertificateCons umer.consume(CertificateMessage.java:369) [07/07/23 09:25:36.974.00] 00000001 java.base/sun.security.ssl.SSLHandshake.consume(SSLHandshake.jav a:392) [07/07/23 09:25:36.974.00] 00000001 java.base/sun.security.ssl.HandshakeContext.dispatch(HandshakeCo ntext.java:443) [07/07/23 09:25:36.974.00] 00000001 java.base/sun.security.ssl.HandshakeContext.dispatch(HandshakeCo ntext.java:421) [07/07/23 09:25:36.974.00] 00000001 java.base/sun.security.ssl.TransportContext.dispatch(TransportCo ntext.java:183) [07/07/23 09:25:36.974.00] 00000001 java.base/sun.security.ssl.SSLTransport.decode(SSLTransport.java :172) [07/07/23 09:25:36.974.00] 00000001 java.base/sun.security.ssl.SSLSocketImpl.decode(SSLSocketImpl.ja va:1507) [07/07/23 09:25:36.974.00] 00000001 java.base/sun.security.ssl.SSLSocketImpl.readHandshakeRecord(SSL SocketImpl.java:1417) [07/07/23 09:25:36.974.00] 00000001 java.base/sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocke tImpl.java:456) [07/07/23 09:25:36.974.00] 00000001 java.base/sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocke tImpl.java:427) Thus preventing the client application from performing a successful handshake with the server (Queue Manager).
Problem conclusion
Users of the MQ Classes for JMS should now be able to successfully perform a TLS handshake, due to a modification in the initialisation of the keystores, dependent on the JRE. --------------------------------------------------------------- The fix is targeted for delivery in the following PTFs: Version Maintenance Level v9.x CD 9.3.5 The latest available maintenance can be obtained from 'WebSphere MQ Recommended Fixes' http://www-1.ibm.com/support/docview.wss?rs=171&uid=swg27006037 If the maintenance level is not yet available information on its planned availability can be found in 'WebSphere MQ Planned Maintenance Release Dates' http://www-1.ibm.com/support/docview.wss?rs=171&uid=swg27006309 ---------------------------------------------------------------
Temporary fix
Comments
APAR Information
APAR number
IT44140
Reported component name
MQ BASE V9.3
Reported component ID
5724H7291
Reported release
933
Status
CLOSED PER
PE
NoPE
HIPER
NoHIPER
Special Attention
NoSpecatt / Xsystem
Submitted date
2023-07-11
Closed date
2023-10-11
Last modified date
2023-10-11
APAR is sysrouted FROM one or more of the following:
APAR is sysrouted TO one or more of the following:
Fix information
Fixed component name
MQ BASE V9.3
Fixed component ID
5724H7291
Applicable component levels
[{"Business Unit":{"code":"BU059","label":"IBM Software w\/o TPS"},"Product":{"code":"SSYHRD","label":"IBM MQ"},"Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"933","Line of Business":{"code":"LOB45","label":"Automation"}}]
Document Information
Modified date:
12 October 2023