Testing a mutual TLS connection to a queue manager from your laptop

After you have created a queue manager using the IBM® MQ Operator, you can test that it is working by connecting to it and putting and getting a message. This task takes you through how to connect using the IBM MQ sample programs, by running them on a machine outside the Kubernetes cluster, such as your laptop.

1. Confirm that the queue manager is running
   The queue manager is now being deployed. Confirm it is in Running state before proceeding. For example:

   oc get qmgr exampleqm

2. Find the queue manager hostname
   Use the following command to find the queue manager fully-qualified hostname for the queue manager from outside the OCP cluster, using the route which is created automatically: exampleqm-ibm-mq-qm:

   oc get route exampleqm-ibm-mq-qm --template="{{.spec.host}}"

3. Create a IBM MQ Client Channel Definition Table (CCDT)
   Create a file called ccdt.json with the following contents:

   {
       "channel":
       [
           {
               "name": "MTLS.SVRCONN",
               "clientConnection":
               {
                   "connection":
                   [
                       {
                           "host": "hostname from previous step",
                           "port": 443
                       }
                   ],
                   "queueManager": "EXAMPLEQM"
               },
               "transmissionSecurity":
               {
                 "cipherSpecification": "ANY_TLS13",
                 "certificateLabel": "example-app1"
               },
               "type": "clientConnection"
           }
      ]
   }

   The connection uses port 443, because that's the port the Red Hat® OpenShift Container Platform router is listening on. The traffic will be forwarded to the queue manager on port 1414.

   If you have used a different channel name, then you will also need to adjust that. The mutual TLS examples use a channel named MTLS.SVRCONN

   For more details, see Configuring a JSON format CCDT

4. Create an client INI file to configure the connection details
   Create a file called mqclient.ini in the current directory. This file will be read by amqsputc and amqsgetc.

   Channels:
     ChannelDefinitionDirectory=.
     ChannelDefinitionFile=ccdt.json
   SSL:
     OutboundSNI=HOSTNAME
     SSLKeyRepository=example-app1.p12
     SSLKeyRepositoryPassword=password you used when creating the p12 file

   Make sure to update the SSLKeyRepositoryPassword to the password you chose when creating the PKCS#12 file. There are other ways to set the key store password, including using an encrypted password. For more information see Supplying the key repository password for an IBM MQ MQI client on AIX®, Linux, and Windows

   Note that the Red Hat OpenShift Container Platform Router uses SNI for routing requests to the IBM MQ queue manager. The OutboundSNI=HOSTNAME attribute ensures that the IBM MQ client includes the necessary information for the router to work with the default route configured by the IBM MQ Operator. For more information, see Configuring a Route to connect to a queue manager from outside a Red Hat OpenShift cluster.

5. If you are using an arm64 Apple Mac, then you need to configure an additional environment variable.

   export MQSSLTRUSTSTORE=example-app1-chain.crt

   This file contains the full certificate chain, including the application and CA certificates.
6. Put messages to the queue
   Run the following command:

   /opt/mqm/samp/bin/amqsputc EXAMPLE.QUEUE EXAMPLEQM

   If connection to the queue manager is successful, the following response is output:

   target queue is EXAMPLE.QUEUE

   Put several messages to the queue, by entering some text then pressing Enter each time.

   To finish, press Enter twice.

7. Retrieve the messages from the queue
   Run the following command:

   /opt/mqm/samp/bin/amqsgetc EXAMPLE.QUEUE EXAMPLEQM

   The messages you added in the previous step have been consumed, and are output. After a few seconds, the command exits.