Содержание
- C# — SSL with Websphere MQ version 7.0.1
- 1 Answer 1
- Troubleshooting IBM MQ Java/JMS SSL Configurations
- Troubleshooting
- Problem
- Symptom
- Diagnosing The Problem
- Resolving The Problem
C# — SSL with Websphere MQ version 7.0.1
When connecting to an SSL enabled queue manager using C#, what values do I need to set to get the queues to work?
I currently get this error: Reason Code: 2393 MQRC_SSL_INITIALIZATION_ERROR
In my code I am setting the MQEnvironment.SSLKeyRepository and MQEnvironment.SSLCipherSpec
Is there something else I need to set with C# to make this work? I have seen some Java examples that set keystore passwords and types and things.
I have also seen examples setting system environment variables too, but that hasn’t seemed to make any difference either.
1 Answer 1
The general pattern for debugging WMQ SSL is as follows.
- Get the application to connect using no SSL. This eliminates problems with connectivity, wrong queue or queue manager names, etc.
- Get SSL working with server-only authentication. This means setting SSLCAUTH(OPTIONAL) on the SVRCONN channel. The QMgr will present a certificate that the application must trust but the application does not need to authenticate back to the server. This validates that both the application and the QMgr can access their keystores and that the QMgr’s certificate or CA chain are properly loaded in the app’s keystore.
- Finally, set SSLCAUTH(REQUIRED) in the SVRCONN channel so that the application authenticates back to the QMgr. At this point the only possible problems are that the QMgr doesn’t trust the app’s cert or CA.
If the connection attempt is refused by the QMgr, the errors at the client will purposely be cryptic. The detailed messages will be found in the QMgr’s AMQERR. LOG files. If the failure is at the client, these messages will be found in the client’s error logs or you can enable trace.
Enable trace using the strmqtrc command and stop it with endmqtrc. The WMQ Clients manual has a section describing where client trace files end up and another section dedicated to tracing on Windows in general. This can be very useful in determining client-side configuration problems such as failing to find a private key, failing to find a keystore, etc.
In your case, the 2393 indicates that something in the client configuration is failing. Since you are no longer getting the error with the keystore password, I’m guessing it may be having problems finding a private key or not trusting the cert provided by the QMgr. In the first case, setting SSLCAUTH(OPTIONAL) will work because the client’ won’t need it’s private key. However if the problem is trusting the QMgr or other configuration issues, SSLCAUTH(OPTIONAL) won’t help but tracing should sort that out.
Incidentally, the need to trace and diagnose on the client side is why IBM does not support client installations where the jars or libs were copied over rather than running the full client install. Although you can get the client to run by copying a few lib files and classes, this does not provide all the facilities for tracing and diagnostics. If you have not performed a full client install, some of what I’ve described here will not be possible. If that is the case, download and install the client from SupportPac MQC7.
Источник
Troubleshooting IBM MQ Java/JMS SSL Configurations
Troubleshooting
Problem
Symptom
Diagnosing The Problem
Two sets of documentation are required:
- SystemOut, console output or Java/JMS trace — this will show the exceptions with stack outputs as seen below
- AMQERR*.LOG files from the queue manager install location. these will contain the AMQxxxx errors as seen below
Resolving The Problem
| Cause 1 | Client missing personal certificate |
| SystemOut.log or Console Output | JMSWMQ0018: Failed to connect to queue manager.
JMSCMQ0001: WebSphere MQ call failed with compcode ‘2’ (‘MQCC_FAILED’) reason ‘2059’ (‘MQRC_Q_MGR_NOT_AVAILABLE’) Stack includes: |
| Queue Manager Error Logs |
AMQ9637: Channel is lacking a certificate. |
| Solution | Add a personal certificate to the client’s keystore which has been signed by a certificate in the queue manager’s key database. |
| Cause 2 | Missing server personal certificate |
| SystemOut.log or Console Output | JMSWMQ0018: Failed to connect to queue manager.
JMSCMQ0001: WebSphere MQ call failed with compcode ‘2’ (‘MQCC_FAILED’) reason ‘2397’ (‘MQRC_JSSE_ERROR’)) Stack includes: |
| Queue Manager Error Logs |
AMQ9637: Channel is lacking a certificate. |
| Solution | Add a personal certificate to the queue manager’s key database which has been signed by a certificate in the client’s truststore, and which has a label of the form»ibmwebspheremqqmname.« |
| Cause 3 | Missing server signer on client |
| SystemOut.log or Console Output | JMSWMQ0018: Failed to connect to queue manager
JMSCMQ0001: WebSphere MQ call failed with compcode ‘2’ (‘MQCC_FAILED’) reason ‘2397’ (‘MQRC_JSSE_ERROR’) Stack includes: |
| Queue Manager Error Logs |
AMQ9665: SSL connection closed by remote end of channel ‘. ‘. |
| Solution | Add the certificate used to sign the queue manager’s personal certificate to the client’s truststore. |
| Cause 4 | Missing client signer on server |
| SystemOut.log or Console Output | JMSWMQ0018: Failed to connect to queue manager
JMSCMQ0001: WebSphere MQ call failed with compcode ‘2’ (‘MQCC_FAILED’) reason ‘2397’ (‘MQRC_JSSE_ERROR’). Stack includes: |
| Queue Manager Error Logs |
AMQ9633: Bad SSL certificate for channel ‘. ‘. |
| Solution | Add the certificate used to sign the queue manager’s personal certificate to the client’s truststore. |
| Cause 5 | Cipher spec mismatch |
| SystemOut.log or Console Output | JMSWMQ0018: Failed to connect to queue manager
JMSCMQ0001: WebSphere MQ call failed with compcode ‘2’ (‘MQCC_FAILED’) reason ‘2397’ (‘MQRC_JSSE_ERROR’). Stack includes: |
| Queue Manager Error Logs |
AMQ9631: The CipherSpec negotiated during the SSL handshake does not match the required CipherSpec for channel ‘SYSTEM.DEF.SVRCONN’. |
| Solution | Ensure that the cipher suite on the client matches the cipher spec on the queue manager’s server connection channel. |
| Cause 6 | No cipher enabled on client |
| SystemOut.log or Console Output | JMSWMQ0018: Failed to connect to queue manager
JMSCMQ0001: WebSphere MQ call failed with compcode ‘2’ (‘MQCC_FAILED’) reason ‘2397’ (‘MQRC_JSSE_ERROR’). Stack includes: |
| Queue Manager Error Logs |
AMQ9639: Remote channel ‘SYSTEM.DEF.SVRCONN’ did not specify a CipherSpec. |
| Solution | Ensure that there is a cipher suite set on the client matching the cipher spec on the queue manager’s server connection channel. |
| Cause 7 | No cipher enabled on queue manager’s server connection channel |
| SystemOut.log or Console Output | JMSWMQ0018: Failed to connect to queue manager.
JMSCMQ0001: WebSphere MQ call failed with compcode ‘2’ (‘MQCC_FAILED’) reason ‘2397’ (‘MQRC_JSSE_ERROR’). Stack includes: |
| Queue Manager Error Logs |
AMQ9635: Channel ‘SYSTEM.DEF.SVRCONN’ did not specify a valid CipherSpec. |
| Solution | Ensure that there is a cipher spec on the queue manager’s server connection channel matching the cipher suite set on the client.. |
| Cause 8 | Using non-FIPS cipher, FIPS enabled on client (not on server) |
| SystemOut.log or Console Output | JMSWMQ0018: Failed to connect to queue manager
JMSCMQ0001: WebSphere MQ call failed with compcode ‘2’ (‘MQCC_FAILED’) reason ‘2393’ (‘MQRC_SSL_INITIALIZATION_ERROR’). Stack includes: |
| Queue Manager Error Logs |
No errors seen |
| Solution | Either disable FIPS on the client or ensure both FIPS is enabled on the server and a FIPS-enabled cipher is being used. |
| Cause 9 | Using non_FIPS cipher, FIPS enabled on server (not on client) |
| SystemOut.log or Console Output | JMSWMQ0018: Failed to connect to queue manager
JMSCMQ0001: WebSphere MQ call failed with compcode ‘2’ (‘MQCC_FAILED’) reason ‘2397’ (‘MQRC_JSSE_ERROR’). Stack includes: |
| Queue Manager Error Logs |
AMQ9616: The CipherSpec proposed is not enabled on the SSL server. |
| Solution | Either disable FIPS on the server or ensure both FIPS is enabled on the client and a FIPS-enabled cipher is being used. |
| Cause 10 | Using FIPS cipher, FIPS not enabled on client |
| SystemOut.log or Console Output | JMSWMQ0018: Failed to connect to queue manager
JMSCMQ0001: WebSphere MQ call failed with compcode ‘2’ (‘MQCC_FAILED’) reason ‘2397’ (‘MQRC_JSSE_ERROR’). Stack includes: |
| Queue Manager Error Logs |
AMQ9616: The CipherSpec proposed is not enabled on the SSL server. |
| Solution | Either enable FIPS on the client or ensure a non FIPS-enabled cipher is being used. |
| Cause 11 | Using non_FIPS cipher, FIPS enabled at both ends |
| SystemOut.log or Console Output | JMSWMQ0018: Failed to connect to queue manager.
JMSCMQ0001: WebSphere MQ call failed with compcode ‘2’ (‘MQCC_FAILED’) reason ‘2393’ (‘MQRC_SSL_INITIALIZATION_ERROR’). Stack includes: |
| Queue Manager Error Logs |
No errors seen.. |
| Solution | Either disable FIPS at both ends or ensure a FIPS-enabled cipher is being used. |
| Cause 12 | Value of SSLPEER on client does not match personal certificate |
| SystemOut.log or Console Output | JMSWMQ0018: Failed to connect to queue manager
JMSCMQ0001: WebSphere MQ call failed with compcode ‘2’ (‘MQCC_FAILED’) reason ‘2398’ (‘MQRC_SSL_PEER_NAME_MISMATCH’). Stack includes: |
| Queue Manager Error Logs |
No errors seen |
| Solution | Ensure the value of SSLPEER matches the distinguished name of the personal certificate. |
| Cause 13 | Value of SSLPEER on server does not match personal certificate |
| SystemOut.log or Console Output | JMSWMQ0018: Failed to connect to queue manager
JMSCMQ0001: WebSphere MQ call failed with compcode ‘2’ (‘MQCC_FAILED’) reason ‘2059’ (‘MQRC_Q_MGR_NOT_AVAILABLE’). Stack includes: |
| Queue Manager Error Logs |
AMQ9636: SSL distinguished name does not match peer name, channel ‘SYSTEM.DEF.SVRCONN’. |
| Solution | Ensure the value of SSLPEER matches the distinguished name of the personal certificate. |
| Cause 14 | Listener not running on server |
| SystemOut.log or Console Output | JMSWMQ0018: Failed to connect to queue manager.
JMSCMQ0001: WebSphere MQ call failed with compcode ‘2’ (‘MQCC_FAILED’) reason ‘2059’ (‘MQRC_Q_MGR_NOT_AVAILABLE’). Stack includes: |
| Queue Manager Error Logs |
No errors seen |
| Solution | Start the listener on the queue manager. |
| Cause 15 | Can not find client keystore |
| SystemOut.log or Console Output | JMSWMQ0018: Failed to connect to queue manager
JMSCMQ0001: WebSphere MQ call failed with compcode ‘2’ (‘MQCC_FAILED’) reason ‘2397’ (‘MQRC_JSSE_ERROR’). Stack includes: |
| Queue Manager Error Logs |
No errors seen |
| Solution | Specify the correct name and location for the client keystore. |
| Cause 16 | Client keystore password incorrect |
| SystemOut.log or Console Output | JMSWMQ0018: Failed to connect to queue manager
JMSCMQ0001: WebSphere MQ call failed with compcode ‘2’ (‘MQCC_FAILED’) reason ‘2397’ (‘MQRC_JSSE_ERROR’). Stack includes: |
| Queue Manager Error Logs |
No errors seen |
| Solution | Specify the correct password for the client keystore. |
| Cause 17 | Can not find client truststore |
| SystemOut.log or Console Output | JMSWMQ0018: Failed to connect to queue manager
JMSCMQ0001: WebSphere MQ call failed with compcode ‘2’ (‘MQCC_FAILED’) reason ‘2397’ (‘MQRC_JSSE_ERROR’). Stack includes: |
| Queue Manager Error Logs |
No errors seen.. |
| Solution | Specify the correct name and location for the client truststore. |
Weblogic to MQ Connectivity failing with 2400 Reason code
Trying to connect to QMGR using SVRCONN channel and cipher TLS_RSA_WITH_AES_256_CBC_SHA256 . When we try to connect it is always given MQRC 2400 or 2393 errors.
While use the TLS_RSA_WITH_AES_256_CBC_SHA256, we are getting the error below . TLS_RSA_WITH_AES_256_CBC_SHA256 is confiugred at MQ side in the SVRCONN Channel
Caused by: com.ibm.mq.MQException: JMSCMQ0001: WebSphere MQ call failed with compcode ‘2’ (‘MQCC_FAILED’) reason ‘2400’ (‘MQRC_UNSUPPORTED_CIPHER_SUITE’).
If we use the SSL_RSA_WITH_AES_256_CBC_SHA256, we are getting the error below error (RC=2393;)
Caused by: com.ibm.mq.jmqi.JmqiException: CC=2;RC=2393;AMQ9771: SSL handshake failed. [1=java.lang.IllegalArgumentException[Unsupported ciphersuite SSL_RSA_WITH_AES_256_CBC_SHA],3=xx.xx.xx.xx/xx.xxxx.xx:1414 (x.xx.xx.xx),4=SSLSocket.createSocket,5=default]
Completion Code 2 (MQCC_FAILED), Reason Code 2393 (MQRC_SSL_INITIALIZATION_ERROR)
MQRC = MQRC_UNSUPPORTED_CIPHER_SUITE [2400]
MQRC = MQRC_SSL_INITIALIZATION_ERROR [2393]
If using an IBM JRE, then the default ciphersuite mappings should be fine.
If using an Oracle (non-IBM) JRE, you must disable the default ciphersuite mappings,so that the ciphersuite you specify is used for the non-IBM JRE.
To disable the ciphersuite mappings for a non-IBM runtime environments, the following Java System Property must be set: com.ibm.mq.cfg.useIBMCipherMappings=false
The 2400 MQRC_UNSUPPORTED_CIPHER_SUITE error commonly occurs if using a non-IBM JRE (like Oracle JRE) and not having the MQ required JVM system argument set: -Dcom.ibm.mq.cfg.useIBMCipherMappings=false
If we are using Oralce JAVA for Weblogic then set -Dcom.ibm.mq.cfg.useIBMCipherMappings=false .This will allow IBM MQ to use oracle ciphers suite names while connecting like TLS_RSA_WITH_AES_256_CBC_SHA256
If JAVA version is below 161 then we need to download[UnlimitedJCEPolicyJDK8] JCE Unlimited Strength Jurisdiction Policy Files ()to use a SHA256 Cipher Suite. For latest java version UnlimitedJCEPolicy files are alread there to support SHA256 .
If we get any SSL handshake due to the nature of implementation try to add below to override default keystore and truststore
-Djavax.net.ssl.keyStore=/u01/ssl/krystore.jks -Djavax.net.ssl.trustStore=/u01/ssl/truststore.jks -Djavax.net.ssl.trustStorePassword=password -Djavax.net.ssl.keyStorePassword=password -Dcom.ibm.mq.cfg.preferTLS=true -Dcom.ibm.mq.cfg.useIBMCipherMappings=false
Issues resolved After Adding -Dcom.ibm.mq.cfg.useIBMCipherMappings=false in Weblogic JVM arguments for 2400 with cipher TLS_RSA_WITH_AES_256_CBC_SHA256 for handshake .
Я пытаюсь отправить сообщения в IBM MQ через безопасный канал SSL. Это мое первое приложение nodejs, которое интегрируется с MQ, хотя раньше я делал это с помощью .net. Я пробовал следующий код, но получаю исключение ниже исключения.
let hConn;
let cD = new msmq.MQCD();
let cno = new msmq.MQCNO();
let oD = new msmq.MQOD()
oD.ObjectName = config.queueName;
cD.ConnectionName = config.port;
cD.ChannelName = config.channel;
cD.CertificateLabel = config.certLabel;
cD.SSLCipherSpec = config.cipherSpec;
msmq.Connx(config.queueManager, cno, (err, hConn) => {
msmq.Open(hConn, oD, openOptions, (err, hObj) => {
let mqmd = new msmq.MQMD();
let pmo = new msmq.MQPMO();
msmq.Put(hObj, mqmd, pmo, message, (err) => {})
})
})
Ошибка:
error fields.name:MQError fields.message:CONNX: MQCC = MQCC_FAILED [2] MQRC = MQRC_KEY_REPOSITORY_ERROR [2381] [Pkg ver = 0.5.1] fields.mqrcstr:MQRC_KEY_REPOSITORY_ERROR fields.stack:MQError: CONNX: MQCC = MQCC_FAILED [2] MQRC = MQRC_KEY_REPOSITORY_ERROR
Я уверен, что это как-то связано с этой строкой кода, но я не смог найти никакого другого свойства apt, чтобы установить имя сертификата или путь, как я делал в .net (SSL_CERT_STORE_PROPERTY, это свойство, которое я использовал там). Любая помощь высоко ценится.
CD.CertificateLabel = config.certLabel;
Вот мой последний код, но все равно возникает та же ошибка.
let hConn;
let cD = new msmq.MQCD();
let cno = new msmq.MQCNO();
let oD = new msmq.MQOD();
let cO=new msmq.MQSCO;
oD.ObjectName = config.queueName;
cD.ConnectionName = config.port;
cD.ChannelName = config.channel;
cD.SSLCipherSpec = config.cipherSpec;
cO.KeyRepository = 'path of the cert file' (.pfx)
cno.ClientConn = cD;
cno.SSLConfig=cO;
msmq.Connx(config.queueManager, cno, (err, hConn) => {
msmq.Open(hConn, oD, openOptions, (err, hObj) => {
let mqmd = new msmq.MQMD();
let pmo = new msmq.MQPMO();
msmq.Put(hObj, mqmd, pmo, message, (err) => {})
})
})
Решение:
В итоге я решил свою проблему, передав как keyRepo, так и certLabel, а также файлы сертификатов в формате .kdb и .sth. Возникла проблема, с которой я столкнулся с именем пользователя, состоящим более чем из 12 символов, поэтому я использовал certLabel с идентификатором менее 12 символов после стандартного ‘ibmwebspheremq’
cO.CertificateLabel = config.certLabel;
cO.KeyRepository = 'path of the cert file and key name' (no extension in the file name)
Клиентский файл .ini (в его разделе SSL) Атрибут CertificateLabel — этот шаг по приведенной ниже ссылке необходим для того, чтобы приведенный выше код работал, на самом деле вам даже не нужно передавать метку сертификата, если она настроена на стороне сервера.
Https://www.ibm.com/support/knowledgecenter/en/SSFKSJ_9.0.0/com.ibm.mq.sec.doc/q014340_.htm
I deliberately misconfigured AT-TLS to see how easy it would be to identify and resolve the problems from an AT-TLS perspective. It turned out worse than I expected. There is little information on the z/OS to help you.
I configured TTLSEnvironmentAction {trace 255 } (see the bottom of this blog) and refreshed the PAGENT. I had configured SYSLOGD so records for *.TCPIP.*.* went to /var/log/TCPIP.
I reran my MQ client application and got
- from MQ on Linux, in file /var/mqm/errors/AMQERR01.LOG return code 2393 (MQRC_SSL_INITIALIZATION_ERROR).
- On Linux there was a file /var/mqm/trace/AMQ.SSL.TRC – which only IBM can format!
- From TCPIP on z/OS EZD1287I TTLS Error RC: 402 Initial Handshake LOCAL: 10.1.1.2..1414 REMOTE: 10.1.0.2..53900 JOBNAME: CSQ9CHIN RULE: REMOTE-TO-CSQ1 USERID: START1 GRPID: 0000001B ENVID: 0000000B CONNID: 0000006E This give
- the address of my client,
- the name of the chinit
- which AT-TLS rule was used
The message EZD1287I TTLS Error RC: 402 Initial Handshake pointed me to Cryptographic Services System Secure Sockets Layer Programming – No SSL cipher specifications. The first reason was
The client and server cipher specifications do not contain at least one value in common. Client and server cipher specifications might be limited depending on which System SSL FMIDs are installed. See Cipher suite definitions for more information. Server cipher specifications are dependent on the type of algorithms that are used by the server certificate (RSA, DSA, ECDSA, or Diffie-Hellman), which might limit the options available during cipher negotiation.
MQ Trace
I took an MQ trace and formatted it. I used grep to find which file had “Cipher” in it.
Within this file I searched for Start of GSKit TLS Handshake Transcript.
This had information sent to the server as part of the handshake, and further down it had the reason code. You can see from the example that the fields and their values have been displayed (so cipher spec 003c is displayed as tls_rsa_with_aes_128_cbc_sha256)
Start of GSKit TLS Handshake Transcript (1119 bytes) <client_hello> client_version TLSV12 random gsksslDissector_32Bits 7f9d66d8 gsksslDissector_Opaque Length: 28 3E 5B 45 66 EE A3 C1 9F FB 81 0C 2F 38 19 DF 95 >[Ef......./8... 5A 1B 54 CC B8 CB B6 C9 87 39 5E 88 Z.T......9^. session_id Length: 00 cipher_suites Length: 04 00 FF 00 3C ...< tls_ri_scsv,tls_rsa_with_aes_128_cbc_sha256 compression_methods Length: 01 00 . Extensions Length: 74 00 0D 00 18 00 16 06 01 05 01 04 01 03 01 02 01 ................ 06 03 05 03 04 03 03 03 02 03 02 02 00 00 00 2A ...............* 00 28 00 00 25 73 79 73 74 65 6D 32 65 2D 64 65 .(..%system2e-de 66 32 65 2D 73 76 72 63 6F 6E 6E 2E 63 68 6C 2E f2e-svrconn.chl. 6D 71 2E 69 62 6D 2E 63 6F 6D mq.ibm.com Extension Count: 2 signature_algorithms 13 rsa:sha512,rsa:sha384,rsa:sha256,rsa:sha224,rsa:sha1, ecdsa:sha512,ecdsa:sha384,ecdsa:sha256,ecdsa:sha224, ecdsa:sha1,dsa:sha1 server_name 0 system2e-def2e-svrconn.chl.mq.ibm.com End of GSKit TLS Handshake Transcript
{ rriEvent
...
RetCode = 20009665, rc1 = 420, rc2 = 0, Comment1='SYSTEM.DEF.SVRCONN',
Comment2='gsk_secure_soc_init', Comment3='10.1.1.2(1414)'
...
}
With this trace, I am able to see what was sent to z/OS.
The AT-TLS Trace
The trace ( configured in syslogd to be in /var/log/TCPIP) had a one line entry with (I’ve reformatted it to make it easier to read).
Map CONNID: 0000006B LOCAL: 10.1.1.2..1414 REMOTE: 10.1.0.2..53898 JOBNAME: CSQ9CHIN USERID: START1 TYPE: InBound STATUS: Enabled RULE: REMOTE-TO-CSQ1 ACTIONS: CSQ1-GROUP-ACTION CSQ1-INBOUND-ENVIRONMENT-ACTION N/A
and data
RC: 0 Connection Init Initial Handshake ACTIONS: CSQ1-GROUP-ACTION CSQ1-INBOUND-ENVIRONMENT-ACTION N/A HS-Server RC: 0 Call GSK_SECURE_SOCKET_OPEN - 00000052FD6228F0 RC: 0 Set GSK_FD(300) - 000000000000006B RC: 0 Set GSK_USER_DATA(200) - 000000007EC32430 RECV CIPHER 160303007B
and one loooong record with
RECV CIPHER 010000770303749ED51D8DC7794EE6AC36B01FD115F38A4B0812D35 C80A5F95DB840C35735CA00000400FF003C0100004A000D00180016 060105010401030102010603050304030303020302020000002A002 800002573797374656D32652D64656632652D737672636F6E6E2E63 686C2E6D712E69626D2E636F6D
SEND CIPHER 15030300020228
From the AT-TLS trace of the data received from the client, it is the data as received, and has not been split down into useful fields.
I could not find any documentation on how to format this string. It is not easy to create a program to format this (and get it right), for example converting cipher spec 003c to TLS_RSA_WITH_AES_128_CBC_SHA256. However I have a REXX exec which works in ISPF and decodes the data into fields, but not the contents of the fields – so the cipher spec is reported as 003c
I had some success taking this data, and creating a file which Wireshark could process. See Wireshark – using external data: Bodging a hex dump file. This was not always successful, as it looks like the data is truncated, and can have non hex data in the hex stream.
Note, the System SSL server started task, GSKSRVR, can capture System SSL trace. The output is like
Job TCPIP Process 0101001D Thread 00000001 read_v3_client_hello Received CLIENT-HELLO message
with no detailed information
Tracing just one session
If you have a busy system you could get trace data for many sessions. You may want to set up a TLS rule, so you use a “debug port”, or you specify the remote host IP address, and port, using information from the error message
EZD1287I TTLS Error RC: 402 Initial Handshake LOCAL: 10.1.1.2..1414 REMOTE: 10.1.0.2..53900 …
And dont forget…
And do not forget to reset the TTLSEnvironmentAction entry to reset the trace, and to refresh the PAGENT.
Published by Colin Paice
I retired from IBM where I worked on MQ on z/OS, and did customer stuff.
I retired, and keep my hand in with MQ, by playing with it!
View all posts by Colin Paice
Published
June 15, 2022June 17, 2022