Tag Archives: IBM MQ - Page 2

IBM MQ: My first try at topic trees

There is a lot of texts and pictures out there talking about topic trees but I have had a hard time finding any complete examples, so to better get a grip on what topic trees are and how I can use them I created this small example.

Goal: To be able to subscribe to multiple topics of similar entity types using only one subscription

Let’s get right into the tree building. I’m here going to use the runmqsc program but you can use MQExplorer if you like a GUI

DEFINE TOPIC(APPLE)  TOPICSTR('/prices/fruit/apple')
DEFINE TOPIC(ORANGE) TOPICSTR('/prices/fruit/orange')
DEFINE TOPIC(PUZZLE) TOPICSTR('/prices/toys/puzzle')
DEFINE TOPIC(CUBE)   TOPICSTR('/prices/toys/cube')

These commands will give you a tree looking like this

                    /      \
               fruits       toys
              /     \      /    \
          orange  apple  cube  puzzle

And now I’m going to try to show the “magic” this brings

A. Subscribe to TOPICSTR(‘/prices/#’) will get you ALL messages published on ANY topic string in this tree
B. Subscribe to TOPICSTR(‘/prices/toys/#’) will get you messages published on ‘/prices/toys’, ‘/prices/toys/cube’ and ‘/prices/toys/puzzle’. No other
C. Subscribe to TOPICSTR(‘/prices/fruit/orange/#’) will get you messages published on ‘/prices/fruit/orange’ only. No other

Pure magic!

Tested on IBM MQ v9.0.5.0 on Red Hat Linux 7.5

IBM MQ: Add a new java client to a queue manager that is using two-way TLS/SSL authentication

In my line of work this is quite common task. I’ll place it here to be able to point new colleagues to it when I get tired of explaining 🙂
I’m here going to use the runmqsc and ikeycmd, both shipped with MQ from 8 and up, and the keytool program that can be found in most java distributions. MQExplorer and ikeyman could also be used if you like a GUI better

Add client to OS

useradd client43

Set a password and we are done with the OS part

Now create client channel in MQ (runmqsc MYQM01)


Two things to note here:
* MCAUSER: this is the OS user that is going to use the channel. In this case ‘client43’ that we created in the beginning
* SSLCIPH: this cipher has to match the one used in the client. NOTE! Cipher names can differ between Java and MQ. Search IBM website for translation tables between cipher names

Set connection access to the new client

setmqaut -m MYQM01 -t qmgr -p client43 -all +connect +inq

Set object access to the new client (eg. PUT and GET rights for a local queue)

setmqaut -m MYQM01 -t queue -n QL.MY.CLIENTS.NEW.QUEUE -p client43 -all +put +get

Add client certificate to MQ certificate store

ikeycmd -cert -add -db "/var/mqm/qmgrs/MYQM01/ssl/key.kdb" -pw changeit -label ibmwebspheremqclient43 -file ibmwebspheremqclient43.crt -format ascii  

NOTE: The default naming convention for client certificates is: ibmwebspheremq + user name. In this example it turns out to: ibmwebspheremqclient43

NOTE 2: If you are using a self-signed certificate you only need to add that certificate to the MQ certificate store BUT if you are using a CA signed client certificate ALL certificates need to be put into the MQ certificate store in order from root to client certificate. The whole certificate chain needs to be present for the client certificate to be resolved correctly by MQ

Add server certificate to the client.jks

keytool -import -alias ibmwebspheremqmyqm01 -file ibmwebspheremqmyqm01.crt -keystore client.jks

NOTE: You can use whatever label you want here. I use the default MQ naming pattern for anything relating to IBM MQ


Troubleshooting tips

# Test auth records towards client user 

# Check clients authentication records on the queue manager
dmpmqaut -m MYQM01 -p client43

# View certificate labels in jks 
keytool -list -keystore client.jks -storepass changeit

# View certificate labels in kdb
ikeycmd -cert -list ca -db key.kdb -pw changeit

Tested on MQ, Java 1.8.0_121 and Red Hat Linux 7.5

IBM MQ: How to copy a TLS/SSL configured keystore from one queue manager to another

Sometimes you got more then one queue manager on a machine. If these queue managers need to be TLS/SSL enabled (and they should always be that) they all need a server certificate, but because they are on the same machine they might all need to have the same certificate. Copying from one setup to another is actually really simple. I’m here going to show how

* Two queue managers: MYQM01 and MYQM02
* MYQM01 has a configured and working keystore and stash file
* Keystore file and stash is called key.kdb and key.sth
* We are using the default label name pattern for server certificates: ibmwebspheremq<qmanager name>
* We are using the default keystore location in Linux: /var/mqm/qmgrs/<qmanager name>/ssl/

First we need to copy all the files

cp /var/mqm/qmgrs/MYQM01/ssl/key* /var/mqm/qmgrs/MYQM02/ssl/

Now we need to rename the label of the server certificate in the new location (for this we use the ikeycmd program shipped with installations from MQ 8 and up)

ikeycmd -cert -rename -label ibmwebspheremqmyqm01 -new_label ibmwebspheremqmyqm02 -db key.kdb -stashed

As a rule I always do this whenever I change anything in a keystore. Here using runmqsc but can also be done via MQExplorer if you prefer a GUI. The queue manager that needs the refresh here is MYQM02



Tested on MQ v9.0.5.0 and Red Hat Linux 7.5