IBM MQ basics: security — part 1: SSL communications

It is fre­quent­ly neglect­ed. It is almost always over­looked. It is the ugly duck­ling of dis­trib­uted appli­ca­tion design. Yes, I am talk­ing about Infor­ma­tion Security.

Secu­ri­ty should be a com­pul­so­ry require­ment of any application.

IBM MQ has exten­sive secu­ri­ty options for either pro­tect­ing your MQ infra­struc­ture and secur­ing the infor­ma­tion that flows trough MQ in the form of messages.

Secu­ri­ty in IBM MQ is a some­what com­plex fea­ture, so this will be the first of a series of three arti­cles about MQ’s secu­ri­ty features.

Secu­ri­ty fea­tures were great­ly improved in IBM MQ 8.0. The most changed fea­tures (user authen­ti­ca­tion and chan­nel secu­ri­ty) will be addressed in future posts.

In the first part of this sub-series of arti­cles about secur­ing your com­mu­ni­ca­tions with SSL.

Com­mu­ni­ca­tion between queue man­agers and between clients and queue man­ag­er can and should be encrypt­ed using SSL. This assures that mes­sages being trans­mit­ted over the net­work, if inter­cept­ed, can­not be read by unwant­ed third-par­ties (or, at least, be very dif­fi­cult to read).

To have your queue man­ag­er com­mu­ni­cate using SSL, the fol­low­ing is needed:

• SSL cer­tifi­cates for both ends of a sender/receiver chan­nel pair.
• SSL options set for the chan­nels (both sender and receiver)

As for the SSL cer­tifi­cates, you can use self-signed cer­tifi­cates or CA-signed cer­tifi­cates. Keep in mind that pub­lic CA-signed cer­tifi­cates are quite expen­sive. Self-signed ones are more than enough and offer the same lev­el of con­fi­den­tial­i­ty as CA-signed ones.

For now, I’ll stick with self-signed certificates.

In the fol­low­ing exam­ples, I’ll be con­nect­ing two queue man­agers, MQ01 and MQ02 using an encrypt­ed channel.

To cre­ate a self-signed cer­tifi­cate in MQ, just issue the commands:

First, cre­ate a keystore:

cd /var/mqm/qmgrs/MQ01/ssl
run­mqakm ‑key­db ‑db key.kdb ‑cre­ate ‑gen­pw ‑stash

The options used are:

• -key­db: spec­i­fy keys data­base commands
• -db: key data­base to create
• -gen­pw: gen­er­ate pass­word for the key database
• -stash: gen­er­ate stash file (file with encrypt­ed pass­word) for the key database

Cre­ate a self-signed certificate:

run­mqakm ‑cert ‑cre­ate ‑db key.kdb ‑label ibmwebspheremqmq01 ‑dn “CN=MQ01,OU=Testing,O=MyOrg,L=Lisbon,C=PT”
‑size 2048 ‑default_cert ‑expire 10950 ‑stashed

Then, extract the pub­lic key of the certificate:

run­mqakm ‑cert ‑extract ‑db key.kdb ‑label ibmwebspheremqmq01 ‑file ibmwebspheremqmq01.pem ‑stashed

Copy the file ibmwebspheremqmq01.pem to the oth­er queue man­ager’s server.

Do the same for the oth­er queue manager.

Then add the pub­lic key from the remote queue man­ag­er to the local queue man­ager’s keystore:

run­mqakm ‑cert ‑add ‑db key.kdb ‑stashed ‑file ibmwebspheremqmq02.pem ‑label ibmwebspheremqmq02

Do the same for the oth­er queue manager.

Next, con­fig­ure sender and receiv­er channels.

For the sake of this exam­ple, I will define a sender and a receiv­er in each queue man­ag­er, name TO.MQ01 and TO.MQ02, which will enable com­mu­ni­ca­tion between both queue man­agers in both ways. Remem­ber that the receiv­er has to have the same name as the remote sender. Note that one-way com­mu­ni­ca­tions requires only a sender chan­nel in the local queue man­ag­er and a receiv­er chan­nel in the remote queue manager.

run­mqsc MQ01
DEFINE QLOCAL(MQ02) USAGE(XMITQ) TRIGGER TRIGDATA(TO.MQ02) TRIGTYPE(FIRST) INITQ(SYSTEM.CHANNEL.INITQ)
DEFINE CHANNEL(TO.MQ02) CHLTYPE(SDR) SSLCIPH(TLS_RSA_WITH_AES_256_GCM_SHA384) XMITQ(MQ02) CONNAME(‘ubuntuvm2(1414)’)

On the remote queue man­ag­er, cre­ate the cor­re­spond­ing receiv­er channel:

run­mqsc MQ02
DEFINE CHANNEL(TO.MQ02) CHLTYPE(RCVR) SSLCIPH(TLS_RSA_WITH_AES_256_GCM_SHA384) SSLCAUTH(REQUIRED)

To turn on SSL on the chan­nel, you only have to spec­i­fy the cipher, using the SSLCIPH para­me­ter. The SSLCAUTH para­me­ter, when set, enables two-way client cer­tifi­cate authen­ti­ca­tion, that is, the sender’s cer­tifi­cate is used to encrypt com­mu­ni­ca­tions and the receiver’s cer­tifi­cate is used to val­i­date that the remote MQ is using a cer­tifi­cate know to the sender side.

If every­thing is cor­rect­ly con­fig­ured, you can now start the sender and dis­play its status:

run­mqsc MQ01
START CHANNEL(TO.MQ02)
DISPLAY CHSTATUS(TO.MQ02) ALL
4 : DISPLAY CHSTATUS(TO.MQ02) ALL
AMQ8417I: Dis­play Chan­nel Sta­tus details.
CHANNEL(TO.MQ02) CHLTYPE(SDR)
BATCHES(0) BATCHSZ(50)
BUFSRCVD(1) BUFSSENT(1)
BYTSRCVD(268) BYTSSENT(268)
CHSTADA(2019–12-05) CHSTATI(11.37.28)
COMPHDR(NONE,NONE) COMPMSG(NONE,NONE)
COMPRATE(0,0) COMPTIME(0,0)
CONNAME(192.168.133.21(1414)) CURLUWID(65C6D65D014F1F12)
CURMSGS(0) CURRENT
CURSEQNO(0) EXITTIME(0,0)
HBINT(300) INDOUBT(NO)
JOBNAME(0000161600000001) LOCLADDR(192.168.133.20(49270))
LONGRTS(999999999) LSTLUWID(0000000000000000)
LSTMSGDA( ) LSTMSGTI( )
LSTSEQNO(0) MCASTAT(RUNNING)
MONCHL(OFF) MSGS(0)
NETTIME(0,0) NPMSPEED(FAST)
RQMNAME(MQ02) SHORTRTS(8)
SECPROT(TLSV12)
SSLCERTI(CN=MQ02,OU=Testing,O=MyOrg,L=Lisbon,C=PT)
SSLCIPH(TLS_RSA_WITH_AES_256_GCM_SHA384)
SSLKEYDA( ) SSLKEYTI( )
SSLPEER(SERIALNUMBER=3C:D4:52:01:E8:A2:BE:E6,CN=MQ02,OU=Testing,O=MyOrg,L=Lisbon,C=PT)
SSLRKEYS(0) STATUS(RUNNING)
STOPREQ(NO) SUBSTATE(MQGET)
XBATCHSZ(0,0) XMITQ(MQ02)
XQTIME(0,0) RVERSION(09010300)
RPRODUCT(MQMM)