IBM MQIPT SSL Handshake-Problem

Oct 09 2020

Wir verbinden den Java MQ-Client mit dem IBM MQ-Server des Kunden. Um eine Verbindung herzustellen, haben wir eine MQIPT-Instanz in Cloud-Räumlichkeiten und eine MQIPT-Instanz in Nicht-Cloud-Räumlichkeiten. Sobald die SSL-Sicherheit in Nicht-Cloud-Räumlichkeiten deaktiviert ist, können wir diese verbinden. Sobald jedoch SSL von Nicht-Cloud-Standorten aktiviert wurde, tritt ein SSL-Handshake-Problem auf. Zertifikate werden zwischen uns geteilt.

Wir haben keinen Zugriff auf diese Nicht-Cloud-Umgebung.

Wir verbinden MQIPT per Java-Client. und unten sind die Spuren, die wir in mqipt trace bekommen.

  1. Wenn wir auf dem mq java client keine Verschlüsselung einstellen, wird der folgende Fehler angezeigt

In diesem Fall ist MQIPT für alle Verschlüsselungen aktiviert.

Issuer: 'CN=********* TEST CA ****,OU=*****,O=******** AG,C=******'
12:45:13.799    27   1414-2s         Processing keyType: RSA
12:45:13.800    27   1414-2s         No RSA certificates in keyring
12:45:13.800    27   1414-2s         Processing keyType: DSA
12:45:13.800    27   1414-2s         No DSA certificates in keyring
12:45:13.800    27   1414-2s         Processing keyType: EC
12:45:13.800    27   1414-2s         No EC certificates in keyring
12:45:13.800    27   1414-2s         WARNING: No suitable certificate to send to the remote server
12:45:13.800    27   1414-2s         --------} IPTX509KeyManager.chooseClientAlias() rc=0
12:45:14.184    27   1414-2s         SSLHandshakeException handshaking:com.ibm.jsse2.k.a(k.java:7)
  1. Wenn wir jedoch CipherSuite im Java MQ-Client festlegen, erhalten wir Fehlerprotokolle in mqipt
MQCPI014 Protocol eyecatcher (16030300) not recognized

MQIPT-Version -> IBM MQ Internet Pass-Thru V9.2.0.1

MQIPT conf wie unten

[global]
CommandPort=1884
RemoteShutDown=true
MinConnectionThreads=5
MaxConnectionThreads=100
IdleTimeout=20
ClientAccess=true
QMgrAccess=true
HTTP=true
HTTPChunking=false
Trace=5
ConnectionLog=true
MaxLogFileSize=50

[route]
Name=Route_1
Active=true
ListenerPort=1414
Destination=mq-dmz-************
DestinationPort=********
HTTP=true
HTTPS=true
SSLClient=true
SSLClientProtocols=TLSv1.2
SSLClientKeyRing="path of key ring PFX file"
SSLClientKeyRingPW="path of password file"
HTTPServer=<Http Server name>
HTTPServerPort=443
URIName=<URI name>
SSLClientCAKeyRing="same as SSLClientKeyRing"
SSLClientCAKeyRingPW="same as SSLClientKeyRingPW"
SSLClientCipherSuites=SSL_ECDHE_RSA_WITH_AES_256_GCM_SHA384

Antworten

1 JoshMc Oct 13 2020 at 17:03

Das Setup zum Akzeptieren der Verbindung vom MQ-Client, zum Entschlüsseln und anschließenden erneuten Verschlüsseln und zum Weiterleiten an den nächsten Hop sollte ungefähr so ​​aussehen:

[route]
Name=Route_1
Active=true
ListenerPort=1414
Destination=mq-dmz-************
DestinationPort=********
HTTP=true
HTTPS=true
SSLClient=true
SSLClientProtocols=TLSv1.2
SSLClientKeyRing="path of key ring PFX file"
SSLClientKeyRingPW="path of password file"
HTTPServer=<Http Server name>
HTTPServerPort=443
URIName=<URI name>
SSLClientCAKeyRing="same as SSLClientKeyRing"
SSLClientCAKeyRingPW="same as SSLClientKeyRingPW"
SSLClientCipherSuites=SSL_ECDHE_RSA_WITH_AES_256_GCM_SHA384
SSLServer=true
SSLServerProtocols=TLSv1.2
SSLServerKeyRing="path of key ring PFX file"
SSLServerKeyRingPW="path of password file"
SSLServerCAKeyRing="same as SSLServerKeyRing"
SSLServerCAKeyRingPW="same as SSLServerCAKeyRing"
SSLServerCipherSuites=SSL_ECDHE_RSA_WITH_AES_256_GCM_SHA384

Was Sie vermissen, ist, dass die Route vom Standpunkt der TLS-Sitzung aus konfiguriert ist. Sie sind entweder:

  1. TLS-Server (Sie empfangen die eingehende Verbindung und entschlüsseln sie)
  2. TLS-Client (Sie stellen eine Verbindung zu einem anderen Warteschlangenmanager oder MQIPT her und verschlüsseln)

Um eine TLS-Verbindung von Ihrer MQ-Client-Anwendung zu akzeptieren, müssen Sie die SSLServer*Entsprechungen zu den bereits konfigurierten SSLClient*Einstellungen konfigurieren .