Java MQ客户端经MQIPT跨环境SSL握手故障技术问询

Alright, let's break down your two MQIPT failure scenarios and walk through targeted fixes based on the logs, config, and version (IBM MQ Internet Pass-Thru V9.2.0.1) you shared.

Scenario 1: SSL Handshake Failure (No Java Client CipherSuite Set) #

The core error here is WARNING: No suitable certificate to send to the remote server followed by an SSLHandshakeException. Here's what's going on and how to fix it:

Root Cause #

Your cloud MQIPT instance can't find a valid client certificate (with private key) in the configured PFX keyring to present to the on-prem MQIPT during SSL handshake. The logs explicitly state no RSA/DSA/EC certificates are available in the keyring, which means:

• The PFX file specified in SSLClientKeyRing either doesn't contain a client certificate with an associated private key, or
• The certificate's key type doesn't align with the default cipher suites, or
• MQIPT can't access the certificate due to an incorrect password in the SSLClientKeyRingPW file.

Fixes to Try #

1. Validate the PFX Keyring Content
   Use IBM MQ's built-in key management tool runmqckm to inspect the PFX file and confirm it contains a client certificate with a private key:

   runmqckm -cert -list -db "/path/to/your/keyring.pfx" -pw "your-pfx-password"
   

   Look for an entry marked as a personal certificate (not just a CA certificate) with a key type of RSA or EC (matching the cipher suite you later tried using).

2. Verify Password File Correctness
   Double-check that the password file referenced in SSLClientKeyRingPW contains the exact password for the PFX file. MQIPT fails silently if the password is wrong, leading to missing certificate errors.

3. Confirm CA Trust Chain
   Since you're using the same PFX for SSLClientKeyRing and SSLClientCAKeyRing, ensure the file includes both the CA that signed your client certificate and the CA trusted by the on-prem MQIPT. This ensures mutual trust during the handshake.

Scenario 2: Protocol Eyecatcher Error (Java Client CipherSuite Set) #

The error MQCPI014 Protocol eyecatcher (16030300) not recognized indicates a protocol mismatch between your Java MQ client and the MQIPT route.

Root Cause #

Your MQIPT route is configured for HTTP/HTTPS tunneling (evidenced by HTTP=true, HTTPS=true, HTTPServer, and URIName in the route config), but your Java client is sending raw MQ SSL traffic directly to the MQIPT listener port (1414) instead of using HTTP CONNECT requests to establish the tunnel. The 16030300 value is MQ's protocol identifier, which MQIPT doesn't expect when in HTTP tunnel mode.

Fixes to Try #

1. Adjust Java Client Connection Mode
   Configure your Java MQ client to use the cloud MQIPT as an HTTP proxy. In your client connection settings, set:

   • Proxy host to your cloud MQIPT hostname
   • Proxy port to 1414
     This way, the client sends HTTP CONNECT requests to MQIPT, which then tunnels the MQ traffic over HTTPS to the on-prem MQIPT.

2. Simplify MQIPT Route (If HTTP Tunnel Isn't Needed)
   If you don't require HTTP tunneling, modify your route config to remove HTTP-related parameters and use direct TCP forwarding with SSL:

   [route]
   Name=Route_1
   Active=true
   ListenerPort=1414
   Destination=mq-dmz-************
   DestinationPort=********
   SSLClient=true
   SSLClientProtocols=TLSv1.2
   SSLClientKeyRing="path of key ring PFX file"
   SSLClientKeyRingPW="path of password file"
   SSLClientCAKeyRing="same as SSLClientKeyRing"
   SSLClientCAKeyRingPW="same as SSLClientKeyRingPW"
   SSLClientCipherSuites=SSL_ECDHE_RSA_WITH_AES_256_GCM_SHA384
   

   With this config, your Java client can connect directly to port 1414 using the specified cipher suite, as MQIPT will handle SSL handshake with the on-prem instance without HTTP wrapping.

3. Align Cipher Suites
   Ensure the cipher suite set in your Java client (SSL_ECDHE_RSA_WITH_AES_256_GCM_SHA384) matches exactly with the value in SSLClientCipherSuites in MQIPT. Also confirm the on-prem MQIPT supports this cipher suite (MQIPT 9.2.0.1 does support it, but double-check with the on-prem team).

Additional Checks for Mutual Success #

• Protocol Version Alignment: Ensure your Java client is configured to use TLSv1.2 (matching SSLClientProtocols=TLSv1.2 in MQIPT). Older TLS versions may be blocked by the on-prem MQIPT.
• On-Prem MQIPT Validation: Even though you can't access the on-prem environment, ask the team to confirm:
  • Their MQIPT is configured to require client authentication (if using mutual SSL)
  • They've imported your CA certificate into their truststore
  • Their server certificate uses a key type compatible with your cipher suite (RSA, in this case)

内容的提问来源于stack exchange，提问作者Nilay Tiwari