Page 1 of 23

Using a CCDT in JSON with SSL/TLS with the IBM MQ sample amqsputc

https://www.ibm.com/support/pages/node/6955535

Date last updated: 13-Feb-2023

Angel Rivera
IBM MQ Support
https://www.ibm.com/products/mq/support
Find all the support you need for IBM MQ

+++ Objective +++

The objective of this tutorial is to describe how to use a CCDT in JSON with SSL/TLS with
the IBM MQ sample: amqsputc

For historical legacy, the term "SSL" is being used in this tutorial in general and includes
TLS.

The approach taken here is conservative and gradual. The idea is to begin with a solid
baseline and subsequent steps are discreet and narrow in scope. In case that there is an
error, it needs to be fixed before taking the next step.
Why? Because if you try to implement everything at once and then you encounter an error,
where do you begin the troubleshooting task? And the answer to this rhetorical question is:
well, it is difficult to troubleshoot such scenario when there are many possible candidates!

One important aspect to consider is that the MQ Client application does NOT need to be
aware if SSL is being used or not used: the underlying MQ client shared-libraries are the
ones that will handle the SSL aspects!
Of course, the configuration of the SSL certificates and SSL-enabled channels need to be
done by the user and the MQ administrator, and this is the part that is the most confusing to
do correctly.

First, we need to ensure that non-SSL server-connection channels can be used with the MQ
sample amqsputc (that puts a message): beginning with using only the simple environment
variable MQSERVER and then a CCDT in JSON that does not use SSL.

Secondly, only after all errors encountered with the first step are fixed, then we test the
SSL/TLS server-connection channel with the MQ sample "amqssslc".

Thirdly, only after all errors encountered with the first and second steps are fixed, then you
can proceed to test your client application with the CCDT JSON that uses SSL. In that way,
if you encounter errors, they will most likely be contained with that client application and
not with the certificates, the SSL channel, and the CCDT.
 Page 2 of 23

The following environment variables are used:

MQSERVER => to provide non-SSL channel, hostname and port
MQCLNTCF => points to mqclient.ini, also called "MQ Client Configuration file"
MQCHLLIB => specifies the full path of the directory where the CCDT file is located
MQCHLTAB => name of the CCDT file

The following MQ samples are used. They are included with the MQ Samples fileset on the
installation image for the MQ server and the MQ client.
amqsputc => to put a message, using server-connection channel via MQSERVER and CCDT
amqssslc => to connect to a queue manager using SSL without CCDT.

++ Recommendations for copy/paste the commands from this document

It is recommended that you copy all the commands in this section and paste
them in a plain text editor such as Notepad, which uses monospace font and no wrap
around the lines.

Then make global replacements for the items such as key database, passwords, user name,
queue manager, etc.

Finally, you can copy from Notepad each command and execute it in a command prompt for
Window or for the remote host in Linux.

ATTENTION: Some commands are very long and they may take multiple lines in this
document, but they are really a single long line! You need to ensure that you run the long
single line!
 Page 3 of 23

++ References:

The following tutorials provide step-by-step instructions for performing specific tasks.
It is recommended that you download the PDFs and have then handy!

1: Referenced as [Basic config qmgr]

https://www.ibm.com/support/pages/node/1135522
Configuring IBM MQ to use a dedicated Listener, Channel and Queue in Linux
Note: If you have already one MQ Listener, there is no really need to create another one
and you can skip the step to create another Listener from the following tutorial:
.
Chapter 1: User "root" adds the proper user and group in both hosts
Chapter 2: MQ administrator (user "mqm") creates a queue manager with the basic/normal
objects in host-1
Chapter 3: MQ administrator adds the dedicated objects.
- Listener (such as MY.LISTENER in port 1420)
- Server-Connection Channel (such as MY.CHANNEL)
- Channel Authentication Record (CHLAUTH) for this server-connection channel that allows
only the user "fulano" who is a member of the group "mqusers".
- Queue (such as MY.Q)
- Authority records for group "mqusers" to display, put, get, browse, etc. from the
dedicated queue.
Chapter 4: User "fulano" from host-2 puts and gets messages using the dedicated objects

2: Referenced as [Using SSL]

https://www.ibm.com/support/pages/node/6470619
Using SSL TLS in MQ 9.2 to connect a C-based client in Windows to a queue manager in
Linux, using self-signed certificates, 2-way authentication
The objective of this document is to provide step-by-step details:
- To connect an MQ 9.2 C-based client from Windows
… to a single-instance queue manager running MQ 9.2 in Linux,
… using self-signed certificates for 2-way authentication (client authenticates the queue
manager, and the queue manager authenticates the client).
- The MQ sample amqssslc is used for testing, because it does not require an MQ CCDT file.
- The MQ sample amqsputc is also used for testing placing a message into queue Q1, and it
requires a CCDT file (for this tutorial it uses JSON format).
For illustration purposes the following protocol will be used:
TLS 1.3 compliant: TLS_AES_128_GCM_SHA256
 Page 4 of 23

3: Referenced as [CCDT in JSON]

https://www.ibm.com/support/pages/node/6568807
Using IBM MQ CCDT file in JSON format
This feature was introduced in MQ 9.1.2 CD and it is available in MQ 9.2 LTS and CD.
There are several examples and the complete JSON file for each of the examples is
included.
- Example 1: Very simple CCDT file: 1 channel, 1 queue manager, no SSL/TLS
- Suggestion to use MQSERVER in host-2 to validate basic connectivity
- Unset MQSERVER and MQCLNTCF
- Creating a CCDT JSON file
- Specifying the MQ environment variables for the CCDT file
- Example 2: CCDT file for 1 channel, 1 queue manager using SS/TLS.
- Example 3: CCDT for 1 multi-instance queue manager, no SSL/TLS
- Using “runmqsc -n” to view the clients defined in the CCDT file
- Troubleshooting Scenario
- Using ccdt_schema.json provided with MQ to validate the CCDT file.
- How to unset MQ environment variables regarding Connectivity

4: Referenced as [Connection precedence]

https://www.ibm.com/support/pages/node/6430633
Connection precedence hierarchy for MQ Clients: PreConnect Exit, MQCONN API, MQSERVER,
mqclient.ini, CCDT

1: Pre-connect exit (this is an advanced feature)

2: Using the MQCNO structure on MQCONNX API call (This is specified in the application's
code or via input arguments).
3: MQSERVER environment variable. This is a common one, specially during testing. Widely
used with C-code samples (It is NOT pertinent with JMS).
4: mqclient.ini file (MQCLNTCF environment variable)
MQSERVER equivalent setting = ServerConnectionParms
5: Client Channel Definition Table (CCDT) file.
Via the MQCHLLIB and MQCHLTAB environment variables
6: mqclient.ini file - CCDT settings:
ChannelDefinitionDirectory and ChannelDefinitionFile
 Page 5 of 23

5: Referenced as [Troubleshooting]

https://www.ibm.com/support/pages/6955529
Exploring some troubleshooting scenarios for SSL/TLS in IBM MQ
The objective of this document is to document the errors encountered during the
preparation of a tutorial on MQ and SSL, what do the errors look like and how they were
resolved.
The scenarios are:
Scenario 1: CipherSpec specified by the MQ Client does not match the required one
Scenario 2: Label specified by the MQ Client does not match the one from the Client
certificate
Scenario 3: Using a TLS 1.2 CipherSpec but the queue manager expects only TLS 1.3
Scenario 4: Specifying suffix (kdb) for keystore, 2381 MQRC_KEY_REPOSITORY_ERROR
Scenario 5: Dealing with an expired client certificate
Scenario 6: MQSERVER does not support SSL/TLS
 Page 6 of 23

++ Configuration used for this tutorial

The following hosts and MQ objects were used for this tutorial.

+ Queue Manager in Linux RHEL:

MQ version.release: 9.3.0.2 LTS

Host-1: volterra1
Platform: IBM MQ for Linux (x86-64 platform)
O/S Details: Red Hat Enterprise Linux 8.6 (Ootpa)
Queue Manager Name:QM93TLS
Port: 1419
SSL Certificate Label: ibmwebspheremqqm93tls
Non-SSL Server-Connection Channel: NON.SSL.SVRCONN
SSL Server-Connection Channel for Linux: SSL.SVRCONN.LNX
SSL Server-Connection Channel for Windows: SSL.SVRCONN.WIN

+ Client in Linux RHEL:

MQ version.release: 9.2.0.6 LTS

Host-2: suvetero1
Platform: IBM MQ for Linux (x86-64 platform)
O/S Details: Red Hat Enterprise Linux 8.6 (Ootpa)
User: mqm
SSL Certificate Label: ibmwebspheremqmqm
C-based client application (Provided with MQ Samples): amqsputc
CCDT in JSON for non-SSL channel (see Section J): ccdt-QM93TLS-volterra1-nonssl.json
CCDT in JSON for SSL channel for Linux (see Section J):
ccdt-QM93TLS-volterra1-linux-ssl.json

+ Client in Windows 10:

MQ version.release: 9.3.0.2 LTS

Host-3: tolteca1
Platform: IBM MQ for Windows (x64 platform)
User: Administrator
SSL Certificate Label: ibmwebspheremqadministrator
C-based client application (Provided with MQ Samples): amqsputc
CCDT in JSON for non-SSL channel (see Section J): ccdt-QM93TLS-volterra1-nonssl.json
CCDT in JSON for SSL channel for Linux (see Section K):
ccdt-QM93TLS-volterra1-windows-ssl.json
 Page 7 of 23

* Section A: Host-1 Linux, Queue manager. From reference [Basic config qmgr]

- As user "root"

Login as user "root".

Facilitate the remote access from Windows user "Administrator", truncated to 12 characters
in lowercase: "administrato"
useradd -u 603 -g mqm -s /bin/bash -d /home/administrato -m administrato

Login as user "mqm".

The rest of the commands are done as user "mqm".

- As user "mqm"

Setup the environment variables for MQ. You need to "source" the command in Linux, that
is, start with a dot, then a space and then the rest.
. /opt/mqm/bin/setmqenv -n Installation1

Create queue manager with port 1419 and start it:

crtmqm -u SYSTEM.DEAD.LETTER.QUEUE -p 1419 QM93TLS
strmqm QM93TLS

Create objects in the queue manager:

runmqsc QM93TLS

## Define a channel to be used by a remote MQ Explorer

DEFINE CHANNEL(SYSTEM.ADMIN.SVRCONN) CHLTYPE(SVRCONN)

## Define a channel to be used by remote clients, it is open to all users,

DEFINE CHANNEL(NON.SSL.SVRCONN) CHLTYPE(SVRCONN)

## Define queue:
DEFINE QLOCAL(Q1)

## Security note: the following ALTER is not suitable for PRODUCTION but might be suitable
for TEST queue managers.
## For testing queue managers: disable userid/password for remote users
ALTER AUTHINFO(SYSTEM.DEFAULT.AUTHINFO.IDPWOS) AUTHTYPE(IDPWOS) CHCKCLNT(OPTIONAL)
REFRESH SECURITY TYPE(CONNAUTH)
 Page 8 of 23

## Security note: the following CHLAUTH records may not be suitable for PRODUCTION but
might be suitable for TEST queue managers.
## For testing queue managers: allow MQ Administrator to remotely access the queue
manager
SET CHLAUTH(*) TYPE(BLOCKUSER) USERLIST('nobody','*MQADMIN')
SET CHLAUTH(SYSTEM.ADMIN.*) TYPE(BLOCKUSER) USERLIST('nobody')
SET CHLAUTH(SYSTEM.DEF.SVRCONN) TYPE(ADDRESSMAP) ADDRESS(*) USERSRC(CHANNEL)
SET CHLAUTH(SYSTEM.DEF.*) TYPE(BLOCKUSER) USERLIST('nobody')
## Allow the following SVRCONN to be accessed by an administrator
SET CHLAUTH(NON.SSL.SVRCONN) TYPE(BLOCKUSER) USERLIST('nobody')
END
 Page 9 of 23

* Section B: Host-2 Linux, Client. From reference [Basic config qmgr]

The objective of this step is to ensure that a plain non-SSL server-connection channel can
be used to connect the MQ client from host-2 to the MQ queue manager in host-1.

There could be several issues that can be encountered at this time, such as:
- firewall problems
- wrong host or port specified by the MQ client application
- incorrect userid
- incomplete authorizations for the remote user
- listener for the queue manager not running
… etc …

Setup the environment variables for MQ

. /opt/mqm/bin/setmqenv -n Installation1

# Add the MQ directory with the samples into the PATH (not added by setmqenv)
export PATH=$PATH:$MQ_INSTALLATION_PATH/samp/bin

Set the MQSERVER environment variable, which has the HIGHEST PRECEDENCE over other
MQ environment variables:
export MQSERVER='NON.SSL.SVRCONN/TCP/volterra1.fyre.ibm.com(1419)'

Issue the MQ sample for putting a message via a server-connection channel:

$ amqsputc Q1 QM93TLS
Sample AMQSPUT0 start
target queue is Q1
THIS IS A TEST MESSAGE
Sample AMQSPUT0 end

If the test was not successful, then you need to take a pause here, and ensure to fix the
current problem(s) before proceeding with SSL.
 Page 10 of 23

* Section C: Host-3 Windows, Client. From reference [Basic config qmgr]

The objective of this step is to ensure that a plain non-SSL server-connection channel can
be used to connect the MQ client from host-2 to the MQ queue manager in host-1.

Setup the environment variables for MQ

setmqenv -n Installation1

If necessary, you may need to specify the full path:

"C:\Program Files\IBM\MQ\bin\setmqenv" -n Installation1

Add into the PATH the directories for the samples:

set PATH=%PATH%;%MQ_FILE_PATH%\Tools\c\Samples\Bin;%MQ_FILE_PATH%\Tools\c\Samples\Bin64

Set the MQSERVER environment variable, which has the HIGHEST PRECEDENCE over other
MQ environment variables:
set MQSERVER=NON.SSL.SVRCONN/TCP/volterra1.fyre.ibm.com(1419)

Issue the MQ sample for putting a message via a server-connection channel:

C:> amqsputc Q1 QM93TLS

Sample AMQSPUT0 start
target queue is Q1
THIS IS A TEST MESSAGE
Sample AMQSPUT0 end

If the test was not successful, then you need to take a pause here, and ensure to fix the
current problem(s) before proceeding with SSL.
 Page 11 of 23

* Section D: Host-1 Linux, Queue manager. From reference [Using SSL]

OK, now that we have confirmed that the remote client can connect successfully using
normal non-SSL channels, we can proceed to do the configurations for SSL.

User "mqm" creates directory to keep SSL related files:

mkdir /var/mqm/ssl

Create key repository, certificate and channels.

(In another step later on, you will need to add the certificates from the clients)

runmqckm -keydb -create -db "/var/mqm/qmgrs/QM93TLS/ssl/QM93TLS.kdb" -pw serverpass

-type cms -stash

Note:
After stashing the kdb password, you could to use the -stashed command line option than to
specify the -pw option.

runmqckm -cert -create -db "/var/mqm/qmgrs/QM93TLS/ssl/QM93TLS.kdb" -pw serverpass

-label ibmwebspheremqqm93tls -dn "CN=QM93TLS,O=IBM,C=USA" -size 2048

runmqckm -cert -list -db "/var/mqm/qmgrs/QM93TLS/ssl/QM93TLS.kdb" -pw serverpass

runmqckm -cert -details -db "/var/mqm/qmgrs/QM93TLS/ssl/QM93TLS.kdb" -pw serverpass

-label ibmwebspheremqqm93tls

At this point we have 3 files in:

$ cd /var/mqm/qmgrs/QM93TLS/ssl
$ ls -1
QM93TLS.kdb
QM93TLS.rdb
QM93TLS.sth

runmqckm -cert -extract -db "/var/mqm/qmgrs/QM93TLS/ssl/QM93TLS.kdb" -pw serverpass

-label ibmwebspheremqqm93tls -target /var/mqm/ssl/QM93TLS.crt -format ascii

At this point we have 1 file in this other directory:

$ cd /var/mqm/ssl
$ ls -1
QM93TLS.crt
 Page 12 of 23

Let's proceed to create objects in the queue manager:

runmqsc QM93TLS

ALTER QMGR SSLKEYR('/var/mqm/qmgrs/QM93TLS/ssl/QM93TLS')

DEFINE CHANNEL('SSL.SVRCONN.WIN') CHLTYPE(SVRCONN) TRPTYPE(TCP) +

SSLCIPH(TLS_AES_128_GCM_SHA256) SSLCAUTH(REQUIRED) +
SSLPEER('CN=administrator,O=IBM,C=USA') REPLACE

DEFINE CHANNEL('SSL.SVRCONN.LNX') CHLTYPE(SVRCONN) TRPTYPE(TCP) +

SSLCIPH(TLS_AES_128_GCM_SHA256) SSLCAUTH(REQUIRED) SSLPEER('CN=mqm,O=IBM,C=USA') +
REPLACE

## (TEST machines) The following is to allow the remote access from MQ Administrators
SET CHLAUTH(SSL.SVRCONN.*) TYPE(BLOCKUSER) USERLIST('nobody')

REFRESH SECURITY TYPE(SSL)

END
 Page 13 of 23

* Section E: Host-2 Linux, client. From reference [Using SSL]

User "mqm" creates directory to keep SSL related files:

mkdir /var/mqm/ssl

Create key repository and certificate:

export MQSSLKEYR=/var/mqm/ssl/clientkey

runmqckm -keydb -create -db /var/mqm/ssl/clientkey.kdb -pw clientpass -type cms -stash

runmqckm -cert -create -db /var/mqm/ssl/clientkey.kdb -pw clientpass -label

ibmwebspheremqmqm -dn "CN=mqm,O=IBM,C=USA" -size 2048

runmqckm -cert -list -db /var/mqm/ssl/clientkey.kdb -pw clientpass

runmqckm -cert -details -db /var/mqm/ssl/clientkey.kdb -pw clientpass -label

ibmwebspheremqmqm

runmqckm -cert -extract -db /var/mqm/ssl/clientkey.kdb -pw clientpass -label

ibmwebspheremqmqm -target /var/mqm/ssl/mqm-client.crt -format ascii

At this point you should have 4 files in: /var/mqm/ssl

$ ls -1
clientkey.kdb
clientkey.rdb
clientkey.sth
mqm-client.crt

Exchange keys with the host that has the queue manager
The crt file from the queue manager is expected to be received at:
/var/mqm/ssl/QM93TLS.crt

You must ensure that the received *.crt files have ownership of "mqm"mqm" and
at least rw permissions for user, such as:
-rw------- 1 mqm mqm 1118 Feb 12 13:19 /var/mqm/ssl/QM93TLS.crt

runmqckm -cert -add -db /var/mqm/ssl/clientkey.kdb -pw clientpass -label

ibmwebspheremqqm93tls -file /var/mqm/ssl/QM93TLS.crt -format ascii

At this point, you should see the following certificates:

runmqckm -cert -list -db /var/mqm/ssl/clientkey.kdb -pw clientpass

Certificates in database /var/mqm/ssl/clientkey.kdb:

ibmwebspheremqmqm
ibmwebspheremqqm93tls

ATTENTION! You should not try yet to connect via SSL, because it is necessary to
update the key repository of the queue manager!
 Page 14 of 23

* Section F: Host-3 Windows, client. From reference [Using SSL]

Specify the key repository

set MQSSLKEYR=C:\ProgramData\IBM\MQ\ssl\clientkey

runmqckm -keydb -create -db "C:\ProgramData\IBM\MQ\ssl\clientkey.kdb" -pw clientpass -

type cms -stash

runmqckm -cert -create -db "C:\ProgramData\IBM\MQ\ssl\clientkey.kdb" -pw clientpass -

label ibmwebspheremqadministrator -dn "CN=administrator,O=IBM,C=USA" -size 2048

runmqckm -cert -list -db "C:\ProgramData\IBM\MQ\ssl\clientkey.kdb" -pw clientpass

runmqckm -cert -details -db "C:\ProgramData\IBM\MQ\ssl\clientkey.kdb" -pw clientpass -

label ibmwebspheremqadministrator

runmqckm -cert -extract -db "C:\ProgramData\IBM\MQ\ssl\clientkey.kdb" -pw clientpass -

label ibmwebspheremqadministrator -target "C:\ProgramData\IBM\MQ\ssl\administrator.crt"
-format ascii

At this point you should have 4 files in:

C:\ProgramData\IBM\MQ\ssl> dir /b
administrator.crt
clientkey.kdb
clientkey.rdb
clientkey.sth

Exchange keys with the host that has the queue manager

The crt file from the queue manager is expected to be received at:
C:\ProgramData\IBM\MQ\ssl\QM93TLS.crt

runmqckm -cert -add -db "C:\ProgramData\IBM\MQ\ssl\clientkey.kdb" -pw clientpass -

label ibmwebspheremqqm93tls -file C:\ProgramData\IBM\MQ\ssl\QM93TLS.crt -format ascii

At this point you should see the following certificates

runmqckm -cert -list -db "C:\ProgramData\IBM\MQ\ssl\clientkey.kdb" -pw clientpass

Certificates in database C:\ProgramData\IBM\MQ\ssl\clientkey.kdb:

ibmwebspheremqadministrator
ibmwebspheremqqm93tls

ATTENTION! You should not try yet to connect via SSL, because it is necessary to
update the key repository of the queue manager!
 Page 15 of 23

* Section G: Host-1 Linux, Queue manager. From reference [Using SSL]

Exchange keys with the hosts with the clients.

The crt files are expected to be received at:
/var/mqm/ssl/mqm-client.crt
/var/mqm/ssl/administrator.crt
.
ATTENTION!!!
You must ensure that the received *.crt files have ownership of "mqm"mqm" and at least
rw permissions for user, such as:
-rw------- 1 mqm mqm 1106 Feb 12 13:15 mqm-client.crt
-rw------- 1 mqm mqm 1118 Feb 12 13:19 administrator.crt

Proceed to add the certificates.

runmqckm -cert -add -db "/var/mqm/qmgrs/QM93TLS/ssl/QM93TLS.kdb" -pw serverpass -label

ibmwebspheremqmqm -file /var/mqm/ssl/mqm-client.crt -format ascii

runmqckm -cert -add -db "/var/mqm/qmgrs/QM93TLS/ssl/QM93TLS.kdb" -pw serverpass -label

ibmwebspheremqadministrator -file /var/mqm/ssl/administrator.crt -format ascii

At this point you should see the following certificates:

runmqckm -cert -list -db "/var/mqm/qmgrs/QM93TLS/ssl/QM93TLS.kdb" -pw serverpass

Certificates in database /var/mqm/qmgrs/QM93TLS/ssl/QM93TLS.kdb:

ibmwebspheremqqm93tls
ibmwebspheremqadministrator
ibmwebspheremqmqm

ATTENTION!!
Because the key repository was modified, it is necessary to refresh the security via
runmqsc.

runmqsc QM93TLS
REFRESH SECURITY TYPE(SSL)
END

(Additional details)
Note regarding the deletion of a certificate (reuse the one for “-cert -details” and
replace it with “-cert -delete)

runmqckm -cert -details -db "/var/mqm/qmgrs/QM93TLS/ssl/QM93TLS.kdb" -pw serverpass -

label ibmwebspheremqmqm

runmqckm -cert -delete -db "/var/mqm/qmgrs/QM93TLS/ssl/QM93TLS.kdb" -pw serverpass -

label ibmwebspheremqmqm
 Page 16 of 23

* Section H: Host-2 Linux, Client. From reference [Using SSL]

Do NOT include the suffix .kdb in for the key repository, argument -k

$ amqssslc -m QM93TLS -c SSL.SVRCONN.LNX -x 'volterra1.fyre.ibm.com(1419)' -k

/var/mqm/ssl/clientkey -s TLS_AES_128_GCM_SHA256 -l ibmwebspheremqmqm

Sample AMQSSSLC start

Connecting to queue manager QM93TLS
Using the server connection channel SSL.SVRCONN.LNX
on connection name volterra1.fyre.ibm.com(1419).
Using SSL CipherSpec TLS_AES_128_GCM_SHA256
Using SSL key repository stem /var/mqm/ssl/clientkey
Certificate Label: ibmwebspheremqmqm
No OCSP configuration specified.
Connection established to queue manager QM93TLS
Sample AMQSSSLC end
 Page 17 of 23

* Section I: Host-3 Windows, Client. From reference [Using SSL]

Do NOT include the suffix .kdb in for the key repository, argument -k

C:\> amqssslc -m QM93TLS -c SSL.SVRCONN.WIN -x volterra1.fyre.ibm.com(1419) -k

"C:\ProgramData\IBM\MQ\ssl\clientkey" -s TLS_AES_128_GCM_SHA256 -l
ibmwebspheremqadministrator

Sample AMQSSSLC start

Connecting to queue manager QM93TLS
Using the server connection channel SSL.SVRCONN.WIN
on connection name volterra1.fyre.ibm.com(1419).
Using SSL CipherSpec TLS_AES_128_GCM_SHA256
Using SSL key repository stem C:\ProgramData\IBM\MQ\ssl\clientkey
Certificate Label: ibmwebspheremqadministrator
No OCSP configuration specified.
Connection established to queue manager QM93TLS
Sample AMQSSSLC end
 Page 18 of 23

* Section J: Host-2 Linux, Client. From references [CCDT in JSON] and [Connection
precedence]

There are 2 sections here.

The first one is about using the CCDT that does not use SSL.
The second one is the one that uses SSL.

+ Using a CCDT in JSON that does NOT use SSL

Let's use the following CCDT in JSON file:

Location: /var/mqm/ssl
File name: ccdt-QM93TLS-volterra1-nonssl.json

The contents will be:

+ begin contents (ignore this line)
{
"channel": [
{
"name": "NON.SSL.SVRCONN",
"clientConnection": {
"connection": [
{
"host": "volterra1.fyre.ibm.com",
"port": 1419
}
],
"queueManager": "QM93TLS"
},
"type": "clientConnection"
}
]
}
+ end contents (ignore this line)

Now you MUST unset the environment variables MQSERVER and MQCLNTCF.

Why? Because MQSERVER has the highest precedence in the connectivity hierarchy and the
presence of MQSERVER will NOT allow you to use CCDT.
The presence of MQSERVER is a VERY COMMON ERROR when customers try to use their CCDT
file.

To unset the variable MQSERVER type:

$ unset MQSERVER

For completeness, just in case that you are using the mqclient.ini (Client Configuration
file), unset the following variable, which has higher precedence than the CCDT ones.
$ unset MQCLNTCF
 Page 19 of 23

Proceed to set the following 2 environment variables that provide the full path of the CCDT
file:
$ export MQCHLLIB=/var/mqm/ssl
$ export MQCHLTAB=ccdt-QM93TLS-volterra1-nonssl.json

Notice that you need to have the environment variable that points to the key repository:
$ export MQSSLKEYR=/var/mqm/ssl/clientkey

Run the amqsputc sample.

$ amqsputc Q1 QM93TLS
Sample AMQSPUT0 start
target queue is Q1
this is a test using CCDT JSON using normal (non SSL) channel

Sample AMQSPUT0 end

The purpose of this test is to ensure that the environment variables are properly set and
that the CCDT is being used.

As an extra step to confirm that the CCDT file is being used, you can introduce a typo in the
host name inside the CCDT file and repeat.

For example, I deleted one letter from the host name inside the CCDT. That is. This was the
only change. Then I repeated the sample:

$ amqsputc Q1 QM93TLS
Sample AMQSPUT0 start
MQCONNX ended with reason code 2538

$ mqrc 2538
2538 0x000009ea MQRC_HOST_NOT_AVAILABLE

Please remember to modify the CCDT file to revert back to the valid host name.
 Page 20 of 23

+ Using a CCDT in JSON that does NOT use SSL

Let's use the following CCDT in JSON file:

Location: /var/mqm/ssl
File name: ccdt-QM93TLS-volterra1-linux-ssl.json

The contents will be:

+ begin contents (ignore this line)
{
"channel": [
{
"name": "SSL.SVRCONN.LNX",
"clientConnection": {
"connection": [
{
"host": "volterra1.fyre.ibm.com",
"port": 1419
}
],
"queueManager": "QM93TLS"
},
"transmissionSecurity":
{
"cipherSpecification": "TLS_AES_128_GCM_SHA256",
"certificateLabel": "ibmwebspheremqmqm",
},
"type": "clientConnection"
}
]
}
+ end contents (ignore this line)

Proceed to set the following 2 environment variables that provide the full path of the CCDT
file:
$ export MQCHLLIB=/var/mqm/ssl
$ export MQCHLTAB=ccdt-QM93TLS-volterra1-linux-ssl.json

Notice that you need to have the environment variable that points to the key repository:
$ export MQSSLKEYR=/var/mqm/ssl/clientkey

Run the amqsputc sample.

$ amqsputc Q1 QM93TLS
Sample AMQSPUT0 start
target queue is Q1
This is a test using CCDT JSON using SSL
Sample AMQSPUT0 end
 Page 21 of 23

* Section K: Host-2 Windows, Client. From references [CCDT in JSON] and [Connection
precedence]

There are 2 sections here.

The first one is about using the CCDT that does not use SSL.
The second one is the one that uses SSL.

+ Using a CCDT in JSON that does NOT use SSL

Let's use the following CCDT in JSON file:

Location: C:\ProgramData\IBM\MQ\ssl
File name: ccdt-QM93TLS-volterra1-nonssl.json

The contents will be:

+ begin contents (ignore this line)
{
"channel": [
{
"name": "NON.SSL.SVRCONN",
"clientConnection": {
"connection": [
{
"host": "volterra1.fyre.ibm.com",
"port": 1419
}
],
"queueManager": "QM93TLS"
},
"type": "clientConnection"
}
]
}
+ end contents (ignore this line)

Now you MUST unset the environment variables MQSERVER and MQCLNTCF.

Why? Because MQSERVER has the highest precedence in the connectivity hierarchy and the
presence of MQSERVER will NOT allow you to use CCDT.
The presence of MQSERVER is a VERY COMMON ERROR when customers try to use their CCDT
file.

To unset the variable MQSERVER type:

set MQSERVER=

For completeness, just in case that you are using the mqclient.ini (Client Configuration
file), unset the following variable, which has higher precedence than the CCDT ones.
set MQCLNTCF=
 Page 22 of 23

Proceed to set the following 2 environment variables that provide the full path of the CCDT
file:
set MQCHLLIB=C:\ProgramData\IBM\MQ\ssl
set MQCHLTAB=ccdt-QM93TLS-volterra1-nonssl.json

Notice that you need to have the environment variable that points to the key repository:
set MQSSLKEYR=C:\ProgramData\IBM\MQ\ssl\clientkey

The following command will show you all the MQ environment variables. Here we show only
the ones of interest.

C:\> set MQ
MQCHLLIB=C:\ProgramData\IBM\MQ\ssl
MQCHLTAB=ccdt-QM93TLS-volterra1-nonssl.json
MQSSLKEYR=C:\ProgramData\IBM\MQ\ssl\clientkey
…

C:\> amqsputc Q1 QM93TLS

Sample AMQSPUT0 start
target queue is Q1
This is a test from Windows using CCDT with non SSL.
Sample AMQSPUT0 end

The purpose of this test is to ensure that the environment variables are properly set and
that the CCDT is being used.

As an extra step to confirm that the CCDT file is being used, you can introduce a typo in the
host name inside the CCDT file and repeat.

For example, I deleted one letter from the host name inside the CCDT. That is. This was the
only change. Then I repeated the sample:

C:\> amqsputc Q1 QM93TLS

Sample AMQSPUT0 start
MQCONNX ended with reason code 2538

C:\> mqrc 2538

2538 0x000009ea MQRC_HOST_NOT_AVAILABLE

Please remember to modify the CCDT file to revert back to the valid host name.
 Page 23 of 23

+ Using a CCDT in JSON that does NOT use SSL

Let's use the following CCDT in JSON file:

Location: C:\ProgramData\IBM\MQ\ssl
File name: ccdt-QM93TLS-volterra1-windows-ssl.json

The contents will be:

+ begin contents (ignore this line)
{
"channel": [
{
"name": "SSL.SVRCONN.WIN",
"clientConnection": {
"connection": [
{
"host": "volterra1.fyre.ibm.com",
"port": 1419
}
],
"queueManager": "QM93TLS"
},
"transmissionSecurity":
{
"cipherSpecification": "TLS_AES_128_GCM_SHA256",
"certificateLabel": "ibmwebspheremqmqm",
},
"type": "clientConnection"
}
]
}
+ end contents (ignore this line)

Proceed to set the following 2 environment variables:

set MQCHLLIB=C:\ProgramData\IBM\MQ\ssl
set MQCHLTAB=ccdt-QM93TLS-volterra1-windows-ssl.json

Notice that you need to have the environment variable that points to the key repository:
set MQSSLKEYR=C:\ProgramData\IBM\MQ\ssl\clientkey

Run the amqsputc sample.

C:> amqsputc Q1 QM93TLS

Sample AMQSPUT0 start
target queue is Q1
This is a test from Windows using CCDT with SSL.
Sample AMQSPUT0 end

+++ end +++