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)

DEFINE CHANNEL(CLIENT43) CHLTYPE(SVRCONN) SSLCIPH(TLS_RSA_WITH_AES_128_CBC_SHA) MCAUSER('client43') 

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

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

Done!

Troubleshooting tips

# Test auth records towards client user 
DISPLAY CHLAUTH(CLIENT43) MATCH(RUNCHECK) ALL ADDRESS('127.0.0.1') CLNTUSER('client43')

# 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 9.0.5.0, 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

Premisses
* 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

REFRESH SECURITY TYPE(SSL)

Done!

Tested on MQ v9.0.5.0 and Red Hat Linux 7.5

IBM MQ: Why is my cluster sender channel trying to connect to 1414 when I have clearly specified 1415 (or any other port)?

Cluster sender channels seems to get “stuck” sometimes and fall back to port 1414 when trying to find the cluster repository.

The solution:
Delete the channel and create it again

DEFINE CHANNEL(TO.REPO) CHLTYPE(CLUSSDR) TRPTYPE(TCP) CONNAME('127.0.0.1(1415)') CLUSTER(EXTERNAL.CLIENTS) DESCR('Cluster-sender channel from MYQM01 to repo at MYREPO01')

Tested on MQ 9.0.5.0 and Red Hat Linux 7.5