1

I’ve managed to establish a connection to a public queue with the older pymqi version for Python2 using the following python code:

import logging

import pymqi

logging.basicConfig(level=logging.INFO)

queue_manager = 'QM1'
channel = 'BZU.UAT.CHNL'
host = '245.274.46.56'
port = '1416'
queue_name = 'BZU.UAT.QUEUE'
conn_info = '%s(%s)' % (host, port)
ssl_cipher_spec = 'TLS_RSA_WITH_3DES_EDE_CBC_SHA'
key_repo_location = 'D:\\App\\BZU\\keydb\\key'
message = 'Hello from Python!'

cd = pymqi.CD()
cd.ChannelName = channel
cd.ConnectionName = conn_info
cd.ChannelType = pymqi.CMQC.MQCHT_CLNTCONN
cd.TransportType = pymqi.CMQC.MQXPT_TCP
cd.SSLCipherSpec = ssl_cipher_spec
cd.UserIdentifier = 'BZU'
cd.Password = ''

sco = pymqi.SCO()
sco.KeyRepository = key_repo_location

qmgr = pymqi.QueueManager(None)
qmgr.connect_with_options(queue_manager, cd, sco)

put_queue = pymqi.Queue(qmgr, queue_name)
put_queue.put(message)

get_queue = pymqi.Queue(qmgr, queue_name)
logging.info('Here is the message again: [%s]' % get_queue.get())

put_queue.close()
get_queue.close()
qmgr.disconnect()

Unfortunately, this code doesn’t work with pymqi version 1.9.3 for Python 3. In this case, I get the following error message:

Traceback (most recent call last):
  File ".\mq_conn_with_ssl.py", line 33, in <module>
    qmgr.connect_with_options(queue_manager, cd, sco)
  File "D:\App\BZU\arn-basis-common\py\pymqi\__init__.py", line 1347, in connect_with_options
    raise MQMIError(rv[1], rv[2])
pymqi.MQMIError: MQI Error. Comp: 2, Reason 2393: FAILED: MQRC_SSL_INITIALIZATION_ERROR

I had to convert all strings in this code to bytes, since the program demanded all strings as bytes . Example:

queue_manager = b'QM1'


In the comments you stated you found the following error in the AMQERR01.LOG file:

AMQ9716: Remote SSL certificate revocation status check failed for channel 'BZU.UAT.CHNL'.
JoshMc
  • 10,239
  • 2
  • 19
  • 38
lvs64
  • 13
  • 7
  • Please try with the latest version 1.10.1. There were fixes related the "ssl" code. What version of mq libraries are you using? – JoshMc Mar 12 '20 at 15:10
  • I'm using IBM_WebSphere_MQ_SDK-8.0.0 – lvs64 Mar 12 '20 at 15:43
  • I've just tried with the version 1.10.1. The result is the same. – lvs64 Mar 12 '20 at 16:35
  • Check in the `AMQERR01.LOG` file for any recent errors and post them. It may be that the cipher you are specifying is deprecated. Please also provide the full 4 digit version. 8.0.0.?. – JoshMc Mar 12 '20 at 17:02

1 Answers1

0

Compare the mqclient.ini file on your working server and on the non-working server for differences in the SSL: stanza that would account for the OCSP check failing.

The location of the mqclient.ini file can be found in the IBM MQ Knowledge center page IBM MQ>Configuring>Configuring connections between the server and clients>Configuring a client using a configuration file>Location of the client configuration file. See the summary is below:

  1. The location specified by the environment variable MQCLNTCF.
  2. A file called mqclient.ini in the present working directory of the application.
  3. A file called mqclient.ini in the IBM MQ data directory for Windows, UNIX and Linux systems.
  4. A file called mqclient.ini in a standard directory appropriate to the platform, and accessible to users:

The documentation on the SSL stanza of the mqclient.ini can be found in the IBM MQ Knowledge center page IBM MQ>Configuring>Configuring connections between the server and clients>Configuring a client using a configuration file>SSL stanza of the client configuration file. See the summary is below:

OCSPAuthentication = OPTIONAL | REQUIRED | WARN

OCSPCheckExtensions = YES | NO

SSLHTTPProxyName = string

JoshMc
  • 10,239
  • 2
  • 19
  • 38
  • I’m using version 8.0.0.9 of MQ. But, I wonder why this code runs through with the older version of pymqi for Python 2 and fails with the newest version for Pythnon 3, if MQ libraries are the same. I am afraid that to use another cipher is not an option for me. It would require some changes in the queue to which I have no access. – lvs64 Mar 13 '20 at 10:11
  • I gave the link to enable, try that. Probably older was compiled against an older version of MQ. – JoshMc Mar 13 '20 at 10:15
  • Check the clients `AMQERR01.LOG` as it should tell you more about the error you get. – JoshMc Mar 13 '20 at 10:26
  • Error message from the log-file ---> AMQ9716: Remote SSL certificate revocation status check failed for channel 'BZU.UAT.CHNL'. – lvs64 Mar 13 '20 at 11:08
  • What exact log and path was that from? App server or MQ server? Is the cert different between the two tests? – JoshMc Mar 13 '20 at 13:25
  • It is a MQ client installed on the application server. Path to the log file is : D:\App\IBM\MQ\errors\AMQERR01.LOG. The files with certificates are always the same. – lvs64 Mar 13 '20 at 14:17
  • Are the two tests on different servers or different users? – JoshMc Mar 13 '20 at 15:11
  • Well, we habe two different windows severs. The first one has python 2.6, the other one python 3.7 installed. The both servers have MQ client v. 8.0.0.9 and Visual Studio installed. Pymqi version 1.6 (I dont know exact number) was compiled and deployed on the first server, pymqi version 1.10 on the other. The programm code which I have posted earlier and certificates are identical. – lvs64 Mar 13 '20 at 16:34
  • @lvs64 Check the `mqclient.ini` on both. I expect you have some OCSP checks that are disabled on the working server. – JoshMc Mar 16 '20 at 09:34
  • Your assumption was absolutely right. I 've adjusted mqclient.ini on the second server. After that, it is working too. Thank you very much for your help! – lvs64 Mar 16 '20 at 12:31
  • Did the mqclient.ini have any settings to allow weak ciphers as well? It would seem to need that as well at the level of MQ you are at. I can adjust my answer with the `mqclient.ini` information. – JoshMc Mar 16 '20 at 13:54
  • I added two parameters to the ini-file:`SSL: SSLHTTPProxyName= OCSPAuthentication=WARN ` – lvs64 Mar 16 '20 at 15:32
  • So you had nothing else **already** in the `mqclient.ini` to specifically enable to usage of `TLS_RSA_WITH_3DES_EDE_CBC_SHA` which is a deprecated cipher as of 8.0.0.6? – JoshMc Mar 16 '20 at 15:46
  • That is very strange and likely a defect based on the documentation. – JoshMc Mar 23 '20 at 21:35
  • I have updated my answer to account for our discussion and your findings above. Please accept when you get a chance. – JoshMc Mar 23 '20 at 22:10