SSL/TLS Channels

IBM MQ moves business payloads across networks that include the public internet, shared data centers, and cloud VPC peering. Without TLS, anyone who can capture packets sees message content and metadata. SSL/TLS channels wrap the TCP connection established by TRPTYPE(TCP) in encryption and optional certificate-based identity. Administrators configure cipher suites with SSLCIPH, client certificate policy with SSLCAUTH, and queue manager key repositories—not per-message application encryption unless compliance requires both. Beginners often configure TLS on only one side of an SDR/RCVR pair or forget that certificate expiry stops traffic as surely as a firewall. This tutorial walks through one-way versus mutual TLS, key repository setup at a high level, channel attributes, pairing with CHLAUTH SSLPEERMAP, revocation via AUTHINFO, cipher modernization, and handshake troubleshooting distinct from CHLAUTH blocks and 2035 authorization failures.

What TLS Provides and What It Does Not

TLS provides confidentiality and integrity on the wire plus server authentication (and client authentication when configured). It does not replace CHLAUTH: knowing the channel name and port is still possible from configuration leaks. It does not grant put authority: MCAUSER and OAM still control queues. It does not validate business payload content. Treat TLS as necessary baseline transport security for remote channels and SVRCONN client access, then layer CHLAUTH and least-privilege MCAUSER on top.

One-Way TLS Versus Mutual TLS

One-way TLS: the queue manager (or partner) presents a server certificate; the client verifies trust via CA. The connecting party may not present a client cert. Traffic is encrypted; partner identity relies on IP CHLAUTH or network zoning. Mutual TLS: the accepting channel sets SSLCAUTH(REQUIRED); the connector must present a client certificate the receiver trusts. Identity is stronger—map DN with SSLPEERMAP. Payment and B2B hubs commonly require mutual TLS on RCVR and SVRCONN. Internal-only links sometimes use one-way TLS inside a private network—document the risk acceptance.

1
2
3
4
5
6
7
ALTER QMGR SSLKEYR('/var/mqm/qmgrs/QM1/ssl/key')
DEFINE CHANNEL('QM1.TO.QM2') CHLTYPE(SDR) TRPTYPE(TCP) +
  CONNAME('qm2.example.com(1414)') XMITQ('QM2.XMIT') +
  SSLCIPH('TLS_RSA_WITH_AES_256_CBC_SHA256')
DEFINE CHANNEL('QM1.TO.QM2') CHLTYPE(RCVR) TRPTYPE(TCP) +
  SSLCIPH('TLS_RSA_WITH_AES_256_CBC_SHA256') SSLCAUTH(REQUIRED)
* Use cipher names valid for your MQ release—check IBM docs

Key Repository and Certificate Lifecycle

The queue manager stores personal certificates and trusted CAs in the SSLKEYR repository. Channel definitions reference that repository implicitly—both SDR and RCVR on a pair need trust chains that validate partner certs. Certificate expiry causes sudden BINDING failures across all channels using that cert—monitor expiry dates in your PKI calendar. Renew certs in lab, update repository, restart or refresh per platform guidance, then update CHLAUTH SSLPEER if DN changes. Corporate CAs often issue new certs with slightly different DN strings—test SSLPEER patterns with wildcards only where IBM syntax allows.

Cipher Suites and Compliance

SSLCIPH strings name combinations of protocol version and algorithms. Weak ciphers (NULL, EXPORT, SSLv3, short RSA keys) fail compliance scans. Standardize on TLS 1.2+ and AEAD ciphers supported by IBM MQ 9.x on your platform. Mixed estates during migration may temporarily allow two cipher strings on different channel pairs—track technical debt. Java and .NET clients must also support chosen ciphers; upgrading only the queue manager is insufficient if clients are old.

TLS With CHLAUTH and MCAUSER

After handshake, CHLAUTH SSLPEERMAP rules match the peer certificate distinguished name and set MCAUSER. Channel MCAUSER provides default when no map applies. A common secure pattern: RCVR SSLCAUTH(REQUIRED), SSLPEERMAP to application MCAUSER, channel MCAUSER a low-privilege default that cannot put to production queues. SVRCONN for microservices: same pattern per service certificate. Revoked certificates should fail when SSLCRLNL points at CRLLDAP or OCSP AUTHINFO objects.

Listeners and Client Connections

LISTENER objects accept TCP; TLS negotiation happens when the channel definition requires SSL. Clients using MQCONNX specify channel name; server SVRCONN supplies SSLCIPH and SSLCAUTH. Client channel tables (CCDT) may include SSL parameters. MQIPT gateways terminate TLS at the edge and forward inside a zone—architecture choice, not a beginner default. Firewalls must pass TLS ports; deep inspection appliances can break handshakes if they re-sign certificates without trust on both ends.

Troubleshooting Handshake Failures

1. Queue manager error log at connect time—cipher mismatch, cert untrusted, expired cert, hostname verify.
2. DISPLAY CHANNEL SSLCIPH SSLCAUTH on both sides—compare values.
3. Verify partner cert is in key database or signed by trusted CA.
4. Test with openssl s_client or IBM documented tools to port and cert chain.
5. If handshake succeeds but bind fails, switch investigation to CHLAUTH—not SSL.

Explainer: Sealed Tunnel

TLS is a sealed tunnel between two buildings. SSLCIPH picks how thick the walls are. SSLCAUTH decides whether the visitor must show a photo ID card, not just trust the building address. CHLAUTH decides which room they may enter after they arrive.

Explain Like I'm Five: SSL/TLS Channels

SSL/TLS makes the messages scrambled on the wire so strangers cannot read them, and can check ID cards so only trusted partners connect.

Practice Exercises

Exercise 1

Document cipher and SSLCAUTH for one SDR/RCVR pair in your lab; note expiry dates.

Exercise 2

List differences between handshake failure and CHLAUTH block in logs.

Exercise 3

Plan cert renewal: key repository, channels, SSLPEERMAP, partner notification.

Frequently Asked Questions

Test Your Knowledge