Mutual TLS, Authentication, and Authorization for IBM MQ

Zhimin Wen
11 min readNov 6, 2021

When MQ is running on the container platform, the default OS-based authentication is no longer valid considering in OpenShift a random user ID is used to run the MQ. You either need to set up an LDAP server or use certificate-based authentication. Using the IBM MQ deployed on OpenShift with the latest Cloud Pak for Integration, we will examine the mutual TLS communication, certificate to user mapping, and the authorization for MQ objects. We adopt a step-by-step approach recording down the errors encountered so that we can avoid these traps later.

Certificate Authority

The CA is at the center of the trust. Between the two parties' communication, one side can trust the other side only when a unique certificate is presented and validated. The validation means the certificate must be issued/signed by an authority, the CA, that one side recognizes and therefore trusts. Typically, the server certificate is validated by the client. But for mutual TLS (mTLS), the client certificate is also validated by the server. This is where the mutual comes from.

Let’s create the CA using cfssl tooling. Generate the following key request JSON file,

{
"CN": "myca",
"hosts": [
"myca"
],
"key": {
"algo": "rsa",
"size": 4096
},
"names": [
{
"C": "SG",
"ST": "SG",
"L": "Singapore"
}
]
}

Notice the key size is 4096. Create the self-signed CA

cfssl gencert -initca myca.json | cfssljson -bare myca

Two PEM files are created, one is the myca.pem certificate file, which can be publicly distributed. The other one is the paired private key file, myca-key.pem It should be kept securely.

Define the following profile in JSON format, named ca-config.json

{
"signing": {
"default": {
"expiry": "43800h"
},
"profiles": {
"server": {
"expiry": "43800h",
"usages": [
"signing",
"key encipherment",
"server auth",
"client auth"
]
},
"client": {
"expiry": "43800h",
"usages": [
"signing",
"key encipherment",
"client auth"
]…

--

--