Refresh SSL security in IBM-MQ telemetry channel doesnt work as expected - ssl

Question

We're running Websphere MQ 9.1 and our Telemetry (MQTT) channel is configured to require SSL Authentication.
Our certificates have lifespans of just a few months and we want to automate the process of replacing these certificates. I can easily create a new .kdb file and place in the SSLKEYR location, but this doesn't automatically make the channel use the new certificates.
I have tried the REFRESH SECURITY TYPE(SSL) command and this command succeeds (output: AMQ8560I: IBM MQ security cache refreshed.) I would think this should work, see: https://www.ibm.com/docs/en/ibm-mq/9.1?topic=authorities-refreshing-tls-security
Refreshing TLS security
If you make a change to the key repository, you can refresh the copy of the key repository that is held in memory while a channel is running, without restarting the channel. When you refresh the cached copy of the key repository, the TLS channels that are currently running on the queue manager are updated with the new information.
About this task
When a channel is secured using TLS, the digital certificates and their associated private keys are stored in the key repository. A copy of the key repository is held in memory while a channel is running. If you make a change to the key repository, you can refresh the copy of the key repository that is held in memory without restarting the channel.
When you refresh the cached copy of the key repository, all TLS channels that are currently running are updated:
Sender, server, and cluster-sender channels that use TLS are allowed to complete the current batch of messages. The channels then run the SSL handshake again with the refreshed view of the key repository.
All other channel types that use TLS are stopped. If the partner end of the stopped channel has retry values defined, the channel retries and runs the SSL handshake again. The new SSL handshake uses the refreshed view of the contents of the key repository, the location of the LDAP server to be used for the Certificate Revocation Lists, and the location of the key repository. In the case of server-connection channel, the client application loses its connection to the queue manager and has to reconnect to continue.
However - when I replace the KDB with a keyrepository with different certificates and I refresh the security, my clients still reconnect after I purge them from the channel. When I restart the channel, the clients stay offline as expected.
Why doesn't refresh security work in this case (because its a telemetry channel?) and is there a way to solve this puzzle without stopping and starting the channel?

Answer 1

In IBM MQ, MQTT components are called MQXR. There are 3 log files you can check:
(1)
Windows: {MQ_DATA_PATH}\qmgrs\{qmgr_name}\mqxr.stdout
Windows: {MQ_DATA_PATH}\qmgrs\{qmgr_name}\mqxr.stderr
Unix: {MQ_DATA_PATH}/qmgrs/{qmgr_name}/mqxr.stdout
Unix: {MQ_DATA_PATH}/qmgrs/{qmgr_name}/mqxr.stderr
(2)
Windows: {MQ_DATA_PATH}\qmgrs\{qmgr_name}\errors\mqxr_0.log
Unix: {MQ_DATA_PATH}/qmgrs/{qmgr_name}/errors/mqxr_0.log
The log file mqxr_0.log should have any error messages related to refreshing security.
Here's an interesting note from the MQ Knowledge Center:
All other channel types using TLS are stopped with a STOP CHANNEL MODE(FORCE) STATUS(INACTIVE) command. If the partner end of the stopped message channel has retry values defined, the channel retries and the new TLS handshake uses the refreshed view of the contents of the TLS key repository, the location of the LDAP server to be used for Certification Revocation Lists, and the location of the key repository. In the case of a server-connection channel, the client application loses its connection to the queue manager and has to reconnect in order to continue.
So, you issuing the stop channel command is basically what the note said the refresh security command will do.
Finally, you should probably open a PMR (help ticket) with IBM to see what they say and possibly fix the issue if it is a bug.