Securing Queue Manager for Client Connection: Part 2 – Using SSL with CHLAUTH

Welcome to the 2nd Part of this Securing Queue Manager for Client Connection blog series. In the first part Part 1 – Using SSL we focused on enabling SSL communication between client (MQExplorer) and Queue Manager. But it provided complete administrative access for connections on the server-connection channel created for the purpose. We had disabled CHLAUTH and CONNAUTH security features and at the same time by-passed authorization by setting the MCAUSER of the channel to mqadmin (a privileged user belonging to mqm group).

Now, in this second part, we will enable CHLAUTH security and use it to restrict connections from client based on SSL Certificate DN and the Issuer’s DN as well as provide the client with different kind of security access depending on it.

For the illustration purpose, we will try to implement the below mentioned security access for the different purposes identified –> Administration / Monitoring / Application Usage. In this blog, we will configure for Administration and Monitoring purposes.

For recreating these steps, pre-required softwares are

  • OpenSSL to sign the certificates
  • MQ v8 or later installed on the Server (Linux machine)
  • MQ Explorer installed on client machine (For only MQ Explorer installation use SupportPac MS0T)
  • Part-1 of this blog series is completed

QM-access-types

1. Creating Groups & Users on MQ Linux Server

We are going to create 3 groups and users for this purpose as provided below

access-setup

Note: Although for set of group / user we need to provide full administration access, we are going to do it without making the user as privilege user, that is without making him  a member of mqm group

  • Logon to the MQ server and switch to root account
  • Create the groups as per above table
# groupadd mqsupp
# groupadd mqmon
  • Create the users and add them to appropriate groups as per above table
# useradd -g mqsupp yuvaraj
# useradd -g mqmon monusr1
  • Exit from root account

2. Generating SSL Certificate for the different Clients (Administrative / Monitoring )

  • Setting up the directory for storing the keys
# cd /ssl
# mkdir mqsupp mqmon
  • Create a key database for the different user account, using the following command
# runmqckm -keydb -create -db /ssl/mqsupp/yuvaraj.jks -pw admin 
     -type jks -stash
# runmqckm -keydb -create -db /ssl/mqmon/monusr1.jks -pw admin 
     -type jks -stash
  • Create Certificate Signing Request (CSR) for the respective user account’s using the following command
# runmqckm -certreq -create -db /ssl/mqsupp/yuvaraj.jks -pw admin 
    -type jks -label yuvaraj 
    -dn "CN=Yuvaraj C P,O=NA ,OU=Training,OU=MQ Support,C=IN" 
    -size 2048 -sig_alg SHA256_WITH_RSA 
    -file /ssl/mqsupp/yuvaraj_csr.arm

# runmqckm -certreq -create -db /ssl/mqmon/monusr1.jks -pw admin 
    -type jks -label monusr1 
    -dn "CN=Monitoring User 1 ,O=NA,OU=Training,OU=MQ Mon,C=IN" 
    -size 2048 -sig_alg SHA256_WITH_RSA 
    -file /ssl/mqmon/monusr1_csr.arm
  • Sign the respective user account’s CSR using the Intermediate CA’s private key to generate the certificate for the CSR and when prompted for pass phrase of Intermediate CA’s private key, use the value provided while creating it.
# cd /ssl/ca
# openssl ca -config intermediate/openssl.cnf -extensions usr_cert 
    -days 375 -notext -md sha256 -in /ssl/mqsupp/yuvaraj_csr.arm 
    -out /ssl/mqsupp/yuvaraj_cert.arm
# openssl ca -config intermediate/openssl.cnf -extensions usr_cert 
    -days 375 -notext -md sha256 -in /ssl/mqmon/monusr1_csr.arm 
    -out /ssl/mqmon/monusr1_cert.arm
  • Receive the Intermediate CA signed certificate into the respective user account’s key database using the following command
# runmqckm -cert -receive -file /ssl/mqsupp/yuvaraj_cert.arm 
     -db /ssl/mqsupp/yuvaraj.jks -pw admin -type jks -format ascii
# runmqckm -cert -receive -file /ssl/mqmon/monusr1_cert.arm 
     -db /ssl/mqmon/monusr1.jks -pw admin -type jks -format ascii
  • Add the Intermediate & Root CA’s certificate to the respective user acc0unt’s key database using the following command
# runmqckm -cert -add -db /ssl/mqsupp/yuvaraj.jks -pw admin 
       -label nebula-intermediate 
       -file /ssl/ca/intermediate/certs/intermediate.cert.der -format ascii
# runmqckm -cert -add -db /ssl/mqsupp/yuvaraj.jks -pw admin 
       -label nebula-root -file /ssl/ca/certs/ca.cert.der -format ascii
# runmqckm -cert -add -db /ssl/mqmon/monusr1.jks -pw admin 
       -label nebula-intermediate 
       -file /ssl/ca/intermediate/certs/intermediate.cert.der -format ascii
# runmqckm -cert -add -db /ssl/mqmon/monusr1.jks -pw admin 
       -label nebula-root -file /ssl/ca/certs/ca.cert.der -format ascii
  • FTP the directory containing the key databases we created for different user account’s under /ssl/ to the respective client machine using suitable ftp client.

3. Enabling Client Connection for Privileged User Account 

Pre-requisites: MQ v8 server or above is installed in the linux machine and user account mqadmin (member of mqm group) is setup with home directory as /home/mqadmin. Part-1 of this blog series is completed.

All the below steps are to be executed in the scripting window (using runmqsc) of the queue manager

  • Create and start the listener object to specify the port on which the queue manager is to listen for client connections (if not created already)
DEFINE LISTENER(TCP.LISTENER) TRPTYPE(TCP) +
   CONTROL(QMGR) PORT(1909)
START LISTENER(TCP.LISTENER)
  • Modify the queue manager property to enable CHLAUTH and disable CONNAUTH security features and to specify the location of the SSL key database that is to be used by the QM for SSL Communication, as shown below
ALTER QMGR CERTLABL('secureqm') +
    SSLKEYR('/home/mqadmin/ssl/secureqm/key') +
    CHLAUTH(ENABLED) CONNAUTH(' ')
  • Create a new Server Connection channel that is to be used only by privileged user account for administering queue manager. By default block all connections on this channel and hence the MCAUSER attribute of this channel is set to ‘nobody’. We will be overriding this value using the appropriate Channel Authentication record depending on the specific value of client’s SSL DN and Issuer DN.
DEFINE CHANNEL(PRIV.ADMIN.SVRCONN) CHLTYPE(SVRCONN) + 
  MCAUSER('nobody') SSLCIPH(TLS_RSA_WITH_AES_256_CBC_SHA256)
  • Create a Channel Authentication Rule as Back-stop rule (refer CHLAUTH – the back-stop rule (IBM Developerworks Blog)) to block everyone connecting to the queue manager. The CHLAUTH rule created by default with QM only blocks privileged user account, where as the new rule that we are creating is to block everyone.
SET CHLAUTH('*') TYPE(ADDRESSMAP) ADDRESS('*') USERSRC(NOACCESS) + 
    DESCR('Back-stop rule to block everyone') WARN(NO) ACTION(ADD)
  • Create a new CHLAUTH record to override the existing default rule that blocks all connections by privileged user account
SET CHLAUTH('PRIV.ADMIN.SVRCONN') TYPE(BLOCKUSER) +
  USERLIST('anyuser') + 
  DESCR('Rule to override blocking of privilege user account') + 
  WARN(NO) ACTION(ADD)
  • Create  a new Channel Authentication Rule to allow only administrator’s to connect to our queue manager for administration purpose. In our case, the user account of administrator is mqadmin
SET CHLAUTH('PRIV.ADMIN.SVRCONN') TYPE(SSLPEERMAP) + 
SSLPEER('CN=nebula-mqexplorer, OU=Training, O=NA') + 
USERSRC(MAP) MCAUSER('mqadmin') DESCR('SSL Auth for privilege user') + 
SSLCERTI('CN=Nebula Intermediate CA, OU=Training, O=Nebula Academy') + 
ACTION(ADD)
  • Refresh the security using the command
REFRESH SECURITY
  • Connect to SECUREQM from MQ Explorer on the client machine.Follow the steps provided in section 5 of Part-1 of this blog series, and using the server-connection channel PRIV.ADMIN.SVRCONN
  • On successful connection from MQ Explorer, check the channel status on MQ Linux server for the SECUREQM as shown below. Check the SSLPEER, SSLCERTI, SECPROT and MCAUSER attribute values on the channel status output
DIS CHS(PRIV.ADMIN.SVRCONN) ALL

AMQ8417: Display Channel Status details.
 CHANNEL(PRIV.ADMIN.SVRCONN) CHLTYPE(SVRCONN)
 BUFSRCVD(66) BUFSSENT(69)
 BYTSRCVD(17652) BYTSSENT(41280)
 CHSTADA(2017-03-08) CHSTATI(13.01.21)
 COMPHDR(NONE,NONE) COMPMSG(NONE,NONE)
 COMPRATE(0,0) COMPTIME(0,0)
 CONNAME(192.168.203.1) CURRENT
 EXITTIME(0,0) HBINT(300)
 JOBNAME(000022C300000004) 
 LOCLADDR(::ffff:192.168.203.143(1909))
 LSTMSGDA(2017-03-08) LSTMSGTI(13.01.23)
 MCASTAT(RUNNING) MCAUSER(mqadmin)
 MONCHL(OFF) MSGS(67)
 RAPPLTAG(MQ Explorer 8.0.0) SECPROT(TLSV12)
 SSLCERTI(E=reachnebula@gmail.com,CN=Nebula Intermediate CA,OU=Training,O=Nebula Academy,ST=TamilNadu,C=IN)
 SSLKEYDA( ) SSLKEYTI( )
 SSLPEER(SERIALNUMBER=10:01,CN=nebula-mqexplorer,OU=Training,O=NA,C=IN)
 SSLRKEYS(0) STATUS(RUNNING)
 STOPREQ(NO) SUBSTATE(RECEIVE)
 CURSHCNV(1) MAXSHCNV(10)
 RVERSION(08000002) RPRODUCT(MQJB)

4. Granting Requisite Access to User Account

  • We are not going to add the user accounts that was created for queue manager administrative purpose to mqm group. Instead we are going to create Access Control List (ACL) for administrative access using setmqaut command
  • Copy the scripts grantAdminAccess.odt & grantReadAccess.odt attached in the appendix section of this blog as /home/mqadmin/grantAdminAccess.sh/home/mqadmin/grantReadAccess.sh respectively

grantAdminAccess.sh

#!/bin/sh
## These commands give group 'mqsupp' full administrative access 
## for the QM to specified group
## Usage:
## grantAdminAccess.sh <QM Name> <Group>
## 
## <QM Name> : Name of the queue manager for which admin access is required
## <Group> : Group to which administrative access is to be granted

if [ $# -lt 2 ]
 then
 echo "Incorrect number of arguments supplier"
 echo "Usage: grantAdminAccess.sh <QM Name> <Group>"
 exit 1
 else
 setmqaut -m $1 -t qmgr -g $2 +connect +inq +alladm
 setmqaut -m $1 -n "**" -t q -g $2 +alladm +crt +browse
 setmqaut -m $1 -n "**" -t topic -g $2 +alladm +crt
 setmqaut -m $1 -n "**" -t channel -g $2 +alladm +crt
 setmqaut -m $1 -n "**" -t process -g $2 +alladm +crt
 setmqaut -m $1 -n "**" -t namelist -g $2 +alladm +crt
 setmqaut -m $1 -n "**" -t authinfo -g $2 +alladm +crt
 setmqaut -m $1 -n "**" -t clntconn -g $2 +alladm +crt
 setmqaut -m $1 -n "**" -t listener -g $2 +alladm +crt
 setmqaut -m $1 -n "**" -t service -g $2 +alladm +crt
 setmqaut -m $1 -n "**" -t comminfo -g $2 +alladm +crt

## The following commands provide administrative access for MQ Explorer.
 setmqaut -m $1 -n SYSTEM.MQEXPLORER.REPLY.MODEL -t q -g $2 +dsp +inq +get
 setmqaut -m $1 -n SYSTEM.ADMIN.COMMAND.QUEUE -t q -g $2 +dsp +inq +put
fi

grantReadAccess.sh

#!/bin/sh
## These commands gives the specified group full administrative access to QM
## 
## Usage:
## grantReadAccess.sh <QM Name> <Group>
## 
## <QM Name> : Name of the queue manager for which admin access is required
## <Group> : Group to which administrative access is to be granted

if [ $# -lt 2 ]
 then
 echo "Incorrect number of arguments supplier"
 echo "Usage: grantReadAccess.sh <QM Name> <Group>"
 exit 1
 else
 
 setmqaut -m $1 -t qmgr -g $2 +connect +inq +dsp
 setmqaut -m $1 -n "**" -t q -g $2 +dsp +browse
 setmqaut -m $1 -n "**" -t topic -g $2 +dsp
 setmqaut -m $1 -n "**" -t channel -g $2 +dsp
 setmqaut -m $1 -n "**" -t process -g $2 +dsp
 setmqaut -m $1 -n "**" -t namelist -g $2 +dsp
 setmqaut -m $1 -n "**" -t authinfo -g $2 +dsp
 setmqaut -m $1 -n "**" -t clntconn -g $2 +dsp
 setmqaut -m $1 -n "**" -t listener -g $2 +dsp
 setmqaut -m $1 -n "**" -t service -g $2 +dsp
 setmqaut -m $1 -n "**" -t comminfo -g $2 +dsp

## The following commands provide administrative access for MQ Explorer.
 setmqaut -m $1 -n SYSTEM.MQEXPLORER.REPLY.MODEL -t q -g $2 +dsp +inq +get
 setmqaut -m $1 -n SYSTEM.ADMIN.COMMAND.QUEUE -t q -g $2 +dsp +inq +put
fi
  • Grant permission on these files to mqadmin and mqm group as shown below
# chmod 774 grant*.sh
  • Run the script files to create requisite ACL for mqsupp and mqmon groups to QM SECUREQM. The script files takes 2 parameters –> Queue Mangare name and group respectively
# cd /home/mqadmin
# ./grantAdminAccess.sh SECUREQM mqsupp
# ./grantReadAccess.sh SECUREQM mqmon

5. Enabling Client Connection for Non-Privileged User Account

All the below steps are to be executed in the scripting window (using runmqsc) of the queue manager

  • Create and start the listener object to specify the port on which the queue manager is to listen for client connections (if not created already)
DEFINE LISTENER(TCP.LISTENER) TRPTYPE(TCP) +
   CONTROL(QMGR) PORT(1909)
START LISTENER(TCP.LISTENER)
  • Modify the queue manager property to enable CHLAUTH and disable CONNAUTH security features and to specify the location of the SSL key database that is to be used by the QM for SSL Communication, as shown below (if not modified already)
ALTER QMGR CERTLABL('secureqm') +
    SSLKEYR('/home/mqadmin/ssl/secureqm/key') +
    CHLAUTH(ENABLED) CONNAUTH(' ')
  • Create a new Server Connection channel that is to be used for client connection to the queue manager for various purposes. By default block all connections on this channel and hence the MCAUSER attribute of this channel is set to ‘nobody’. We will be overriding this value using the appropriate Channel Authentication record depending on the specific value of client’s SSL DN and Issuer DN.
DEFINE CHANNEL(RMT.ADMIN.SVRCONN) CHLTYPE(SVRCONN) + 
  MCAUSER('nobody') SSLCIPH(TLS_RSA_WITH_AES_256_CBC_SHA256)
  • Create a Channel Authentication Rule as Back-stop rule (refer CHLAUTH – the back-stop rule (IBM Developerworks Blog)) to block everyone connecting to the queue manager. The CHLAUTH rule created by default with QM only blocks privileged user account, where as the new rule that we are creating is to block everyone (if not created already)
SET CHLAUTH('*') TYPE(ADDRESSMAP) ADDRESS('*') USERSRC(NOACCESS) + 
    DESCR('Back-stop rule to block everyone') WARN(NO) ACTION(ADD)
  • Create  a new Channel Authentication Rule to identify the client connection based on their SSL DN and Issuer DN and map it to appropriate access level user account on the server side.
SET CHLAUTH('RMT.ADMIN.SVRCONN') TYPE(SSLPEERMAP) + 
SSLPEER('CN=Yuvaraj C P, OU=Training, OU=MQ Support, O=NA') + 
USERSRC(MAP) MCAUSER('yuvaraj') + 
DESCR('SSL Auth for Administrative user') + 
SSLCERTI('CN=Nebula Intermediate CA, OU=Training, O=Nebula Academy') +
ACTION(ADD)

SET CHLAUTH('RMT.ADMIN.SVRCONN') TYPE(SSLPEERMAP) + 
SSLPEER('CN=Monitoring User 1, OU=Training, OU=MQ Mon, O=NA') + 
USERSRC(MAP) MCAUSER('monusr1') DESCR('SSL Auth for Monitoring user') +
SSLCERTI('CN=Nebula Intermediate CA, OU=Training, O=Nebula Academy') +
ACTION(ADD)
  • Refresh the security using the command
REFRESH SECURITY
REFRESH SECURITY TYPE(SSL)
  • Connect to SECUREQM from MQ Explorer on the client machine.Follow the steps provided in section 5 of Part-1 of this blog series, and using the server-connection channel RMT.ADMIN.SVRCONN. 
    • For Administrative access: Try using the key store yuvaraj.jks in MQ Explorer
    • For Read only access: Try using the key store monusr1.jks in MQ Explorer

Notice the kind the access you get on MQ Explorer in both the cases

  • On successful connection from MQ Explorer, check the channel status on MQ Linux server for the SECUREQM as shown below. Check the SSLPEER, SSLCERTI, SECPROT and MCAUSER attribute values on the channel status output

6. Appedix

7. References

CHLAUTH – the back-stop rule (Application Integration Middleware Support Blog)

CHLAUTH – Allow some privileged admins (Application Integration Middleware Support Blog)

Will be following up this blog to extend the client connectivity  with CONNAUTH security feature too.

For any corrections / suggestions / comments / query please do drop a note to reachnebula@learnibmesb.com (or) reachnebula@gmail.com

Advertisements

Securing Queue Manager for Client Connection: Part 1 – Using SSL

Queue Manager provides various security mechanism – Authorization using OAM, Connection Authentication (introduced in MQ v8), Channel Authentication Records (CHLAUTH introduced in MQ v7.1) and SSL.

Am writing a series of blog for securing a queue manager for client connection by combining all these security mechanisms – SSL, CHLAUTH, CONNAUTH and OAM.

In this first part of blog series, we will focus on securing QM client connection using SSL. Also in this blog, instead of using self-signed certificates for the demonstration, we will use OpenSSL tool to setup internal CA’s and use them for signing the certificates for QM and the clients. This is to demonstrate working with CA signed certificates in real-time environments.

For recreating these steps, pre-required softwares are

  • OpenSSL to setup up internal Root CA and Intermediate CA’s and signing the Certificate requests
  • MQ v8 or later installed on the Server (Linux machine)
  • MQ Explorer installed on client machine (For only MQ Explorer installation use SupportPac MS0T)

1. Setting up Internal Root and Intermediate CA’s using OpenSSL

Reference: https://jamielinux.com/docs/openssl-certificate-authority/introduction.html

To install OpenSSL in RHEL / CentOS,

yum install openssl
Note: This is typically installed on CentOS by default.

Creating Internal Root CA

  • Create the required directories for storing all keys and certificates. Note: The index.txt and serial files act as a flat file database to keep track of signed certificates.
# mkdir /ssl
# mkdir /ssl/ca
# cd /ssl/ca
# mkdir certs crl newcerts private
# chmod 700 private
# touch index.txt
# echo 1000 > serial
  • Download and Copy the configuration file for the root CA (RootCAConfig.odt) file from the appendix to /ssl/ca/openssl.cnf
  • Create the private key for the root CA using the command provided below. When prompted for pass phrase, please provide the pass phrase for securing the private key. This pass phrase is required for accessing the private key for signing certificates.
# cd /ssl/ca
# openssl genrsa -aes256 -out private/ca.key.pem 4096
# chmod 400 private/ca.key.pem
  • Create the Root CA certificate using the private key we have just created. Enter the pass phrase for the Root CA’s private key when prompted.

 And then provide the requested information for the certificates at the prompts appropriately.

# cd /ssl/ca
# openssl req -config openssl.cnf -key private/ca.key.pem -new -x509 
-days 7300 -sha256 -extensions v3_ca -out certs/ca.cert.pem

RootCertificate

  • Verify the Root CA certificate that we had just created
    # openssl x509 -noout -text -in certs/ca.cert.pem

Creating Internal Intermediate CA

  • Create the required directories for storing all keys and certificates..
# cd /ssl/ca
# mkdir intermediate
# cd intermediate
# mkdir certs crl csr newcerts private
# chmod 700 private
# touch index.txt
# echo 1000 > serial
# echo 1000 > /ssl/ca/intermediate/crlnumber
  • Download and Copy the configuration file for the Intermediate CA (IntermediateCAConfig.odt) file from the appendix to /ssl/ca/intermediate/openssl.cnf
  • Create the private key for the root CA using the command provided below. When prompted for pass phrase, please provide the pass phrase for securing the private key. This pass phrase is required for accessing the private key for signing certificates.
# cd /ssl/ca
# openssl genrsa -aes256 \
  -out intermediate/private/intermediate.key.pem 4096
# chmod 400 intermediate/private/intermediate.key.pem
  • Create the Intermediate CA’s certificate signing request (CSR). And then provide the requested information for the certificates at the prompts appropriately.
# cd /ssl/ca
# openssl req -config intermediate/openssl.cnf -new -sha256 \
      -key intermediate/private/intermediate.key.pem \
      -out intermediate/csr/intermediate.csr.pem

IntermediateCertRequest

  • Create the Intermediate CA’s certificate signing request (CSR). And then provide the requested information for the certificates at the prompts appropriately.
# cd /ssl/ca
# openssl ca -config openssl.cnf -extensions v3_intermediate_ca \
      -days 3650 -notext -md sha256 \
      -in intermediate/csr/intermediate.csr.pem \
      -out intermediate/certs/intermediate.cert.pem

IntermediateCertSign

  • Verify the Intermediate CA certificate.
# cd /ssl/ca
# openssl x509 -noout -text \ -in intermediate/certs/intermediate.cert.pem
# openssl verify -CAfile certs/ca.cert.pem \                 intermediate/certs/intermediate.cert.pem

Now that we have set the internal Root and Intermediate CA’s for our purpose, we will start working with QM

2. Generating SSL Certificate for QM – SECUREQM

Pre-requisites: MQ v8 server or above is installed in the linux machine and user account mqadmin (member of mqm group) is setup with home directory as /home/mqadmin

  • Setting up the directory for storing the keys
# cd /home/mqadmin
# mkdir ssl
# mkdir ssl/secureqm
  • Create a key database for the Queue Manager SECUREQM using the following command
# runmqckm -keydb -create -db /home/mqadmin/ssl/secureqm/key.kdb \ 
   -pw admin -type cms -stash
  • Queue Manager and the channel processes require read access on the key database & its related files. Hence, set the permissions on the files *.kdb, *.sth, *.crl, and *.rdb, to read and write for the file owner, and to read for the mqm or client user group (-rw-r—–)
# cd /home/mqadmin/ssl/secureqm
# chmod 640 key.kdb key.rdb key.sth
  • Create Certificate Signing Request (CSR) for the SECUREQM using the following command
# runmqckm -certreq -create -db /home/mqadmin/ssl/secureqm/key.kdb \
  -pw admin -label secureqm -dn "CN=secureqm,O=NA,OU=Training,C=IN" \
  -size 2048 -sig_alg SHA256_WITH_RSA \
  -file /home/mqadmin/ssl/secureqm/secureqm.arm
  • Create the SECUREQM certificate using the Intermediate CA’s private key to sign the queue manager’s CSR as shown below
# openssl ca -config intermediate/openssl.cnf \
-extensions server_cert -days 375 -notext -md sha256 \
-in /home/mqadmin/ssl/secureqm/secureqm.arm \
-out intermediate/certs/secureqm.arm
  • Receive the CA signed certificate into the queue manager’s key database using the following command
# runmqckm -cert -receive \
   -file /ssl/ca/intermediate/certs/secureqm.arm \
   -db /home/mqadmin/ssl/secureqm/key.kdb -pw admin -format ascii

We need to add the Root CA & Intermediate CA’s certificate to the queue manager’s key database for setting up the certificate chain of trust.

  • Covert the Intermediate CA’s certificate from PEM to DER format using the following command
# openssl x509 -outform der -in certs/intermediate.cert.pem \
    -out certs/intermediate.cert.der
  • Covert the Root CA’s certificate from PEM to DER format using the following command
# openssl x509 -outform der -in certs/ca.cert.pem \
    -out certs/ca.cert.der
  • Add the Intermediate & Root CA’s certificate to the queue manager’s key database using the following command
# runmqckm -cert -add -db /home/mqadmin/ssl/secureqm/key.kdb \
   -pw admin -label nebula-intermediate \
   -file /ssl/ca/intermediate/certs/intermediate.cert.der \
   -format ascii
# runmqckm -cert -add -db /home/mqadmin/ssl/secureqm/key.kdb \
   -pw admin -label nebula-root -file /ssl/ca/certs/ca.cert.der \
   -format ascii

3. Generating SSL Certificate for the client (MQ Explorer)

  • Setting up the directory for storing the keys
# cd /home/mqadmin
# mkdir ssl
# mkdir ssl/mqexplorer
  • Create a key database for the MQ Explorer client using the following command
# runmqckm -keydb -create \
   -db /home/mqadmin/ssl/mqexplorer/mqex_key.jks \
   -pw admin -type cms -stash
  • Create Certificate Signing Request (CSR) for the mq explorer client using the following command
# runmqckm -certreq -create \
    -db /home/mqadmin/ssl/mqexplorer/mqex_key.jks \
    -pw admin -type jks -label mqexClient \
    -dn "CN=nebula-mqexplorer,O=NA,OU=Training,C=IN" -size 2048 \
    -sig_alg SHA256_WITH_RSA \
    -file /home/mqadmin/ssl/mqexplorer/mqexClient_csr.arm
  • Sign the mq explorer’s CSR using the Intermediate CA’s private key to generate the certificate for the CSR
# cd /ssl/ca
# openssl ca -config intermediate/openssl.cnf 
   -extensions usr_cert -days 375 -notext -md sha256 
   -in /home/mqadmin/ssl/mqexplorer/mqexClient_csr.arm 
   -out intermediate/certs/mqexClient_cert.arm
  • Receive the Intermediate CA signed certificate into the mq explorer’s key database using the following command
# runmqckm -cert -receive 
   -file /ssl/ca/intermediate/certs/mqexClient_cert.arm
   -db /home/mqadmin/ssl/mqexplorer/mqex_key.jks -pw admin 
   -type jks -format ascii
  • Add the Intermediate & Root CA’s certificate to the queue manager’s key database using the following command
# runmqckm -cert -add -db /home/mqadmin/ssl/mqexplorer/mqex_key.jks \
   -pw admin -label nebula-intermediate \
   -file /ssl/ca/intermediate/certs/intermediate.cert.der -format ascii
# runmqckm -cert -add -db /home/mqadmin/ssl/mqexplorer/mqex_key.jks \
  -pw admin -label nebula-root -file /ssl/ca/certs/ca.cert.der \
  -format ascii
  • FTP the mqexplorer directory under /home/mqadmin/ssl/ to the client machine using suitable ftp client.

Now that we are done with all certificates generation for both Queue Manager and the client, lets proceed with start using this certificates for communication between QM and the MQ Explorer.

For this, we need to enable our QM for remote connection and to use the SSL key database we have created in the earlier steps.

4. Enabling Remote Connectivity for QM and to use SSL

As far as this blog is concerned, we will disable the other security features CHLAUTH and CONNAUTH (for MQ 8) of the QM. We will extend the setup to use CHLAUTH and CONNAUTH in the subsequent parts of this blog series.

  • Create a queue manager SECUREQM for our setup purpose using the command shown below, using the mqadmin user account which is part of mqm group
# crtmqm -u SYSTEM.DEAD.LETTER.QUEUE SECUREQM
  • Start the queue manager using the command shown below
# strmqm SECUREQM
  • Get into the scripting mode of the queue manager using the runmqsc command as shown below
# runmqsc SECUREQM

All the below steps are to be executed in the scripting window of the queue manager

  • Create and start the listener object to specify the port on which the queue manager is to listen for client connections.
DEFINE LISTENER(TCP.LISTENER) TRPTYPE(TCP) +
   CONTROL(QMGR) PORT(1909)
START LISTENER(TCP.LISTENER)
  • Modify the queue manager property to disable CHLAUTH and CONNAUTH security features and to specify the location of the SSL key database that is to be used by the QM for SSL Communication, as shown below
ALTER QMGR CERTLABL('secureqm') +
    SSLKEYR('/home/mqadmin/ssl/secureqm/key') +
    CHLAUTH(DISABLED) CONNAUTH(' ')
  • Create a new Server Connection channel to be used by the clients for secured connectivity to the queue manager as shown below

Note: we have set MCAUSER property of the channel to specify mqadmin user account which is privileged user account as it belongs to mqm group. Hence QM will not check for access rights for any connection coming on this channel. We are setting this for demonstration purpose only and this is not to be followed in real-time situations or production environment. Ideally privileged user account should not be set for MCAUSER attribute of channel 

DEFINE CHANNEL(MQEXP.SVRCONN) CHLTYPE(SVRCONN) MCAUSER('mqadmin') +
   SSLCIPH(TLS_RSA_WITH_AES_256_CBC_SHA256)

5. Connecting to SECUREQM from MQ Explorer

Pre-requisite: The mqexplorer directory under /home/mqadmin/ssl/ in the MQ Server is ftp’ed on to the client machine where MQ Explorer is installed.

  • Launch the MQ Explorer on the client machine
  • Right click on the Queue Manager folder in MQ Explorer and select the option “Add Remote Queue Manager”

mqexp_ssl1

  • In the Add Queue Manager wizard, specify the QM name as SECUREQM and with the option Connect directly selected, click Next

mqexp_ssl2

  • Specify the connection details of the queue manager – Host Name / IP Address of MQ Server, Port Number as 1909 (port at which QM listener is created & listening) and Server-Connection channel as MQEXP.SVRCONN, and click Next

mqexp_ssl3

  • In the Specify security exit details wizard, without selecting the option Enable security exit, click Next
  • In the Specify user identification details wizard, without selecting the option Enable user identification, click Next
  • In the Specify SSL certificate key repository details wizard, check the option Enable SSL Key repositories. Browse and select the mqex_key.jks file for the Store name property under Trusted Certificate Store as well as Personal Certificate Store categories. Click Next

mqexp_ssl4

  • In the Specify SSL option wizard, check the Enable SSL option wizard and select SSL CipherSpec property value as TLS_RSA_WITH_AES_256_CBC_SHA256 from the list and click Finish

mqexp_ssl5

  • When prompted for the password to access key database, provide the password as “admin” or whatever used at the time of key database creation and click Ok. Queue Manager SECUREQM should be listed in the MQ Explorer on successful connection

mqexp_ssl5a

  • In the MQ Server, check the channel status MQEXP.SVRCONN from the script window of SECUREQM, using the following command. Check for the attributes SSLPEER (denotes the DN of the client) and SSLCERTI  (denotes the DN of the Certificate Issuer), in the output.
# runmqsc SECUREQM
    DISPLAY CHS(MQEXP.SVRCONN) ALL

mqexp_ssl6

6. Appendix

Hope this helps.

Will be following up this blog to extend the client connectivity using SSL with CHLAUTH and later with CONNAUTH.

For any corrections / suggestions / query please do drop a note to reachnebula@learnibmesb.com (or) reachnebula@gmail.com