Mutual TLS

Passwords shared in configuration files leak through tickets, backups, and shoulder surfing. Mutual TLS (mTLS) replaces or supplements passwords with cryptographic client identity: each connecting application or queue manager presents a private key and certificate the partner validates against a trusted CA. In IBM MQ, mutual TLS is implemented with the same TLS stack as one-way encryption—SSLKEYR repositories, SSLCIPH cipher specs, and SSLCAUTH on the accepting channel—but the accepting side refuses connections that do not present an acceptable client certificate. Banks, health information exchanges, and zero-trust networks adopt mTLS on SVRCONN for microservices and on RCVR for B2B queue manager pairs. This tutorial contrasts one-way and mutual TLS, walks through SSLCAUTH values, client cert issuance and renewal, SSLPEERMAP to MCAUSER, differences between application clients and message channels, and troubleshooting when handshake succeeds but CHLAUTH blocks the DN.

One-Way TLS Versus Mutual TLS

One-way TLS encrypts traffic and proves the server identity to the client. An attacker who steals only a password still cannot decrypt past captures, but a stolen password might authorize a new connection if CHLAUTH and OAM allow password auth. Mutual TLS adds client certificate validation on the accepting MQ channel: only holders of approved private keys connect, which pairs well with short-lived automation credentials and eliminates shared passwords across partners. Cost: PKI operations, cert renewal, and DN management in CHLAUTH rules.

One-way vs mutual TLS on IBM MQ
AspectOne-way TLSMutual TLS
Server certificateRequiredRequired
Client certificateOptionalRequired (SSLCAUTH REQUIRED)
Typical identityPassword + USERMAPSSLPEERMAP to MCAUSER
RevocationServer cert CRL/OCSPBoth sides may need checks
Operational loadLowerHigher (PKI lifecycle)

SSLCAUTH on Accepting Channels

SSLCAUTH applies to channels that accept inbound TLS connections: RCVR, CLUSRCVR, SVRCONN. REQUIRED mandates a client certificate. OPTIONAL accepts connections with or without client cert—useful during migration. Consult IBM documentation for ANY and NONE semantics on your release before production ALTER. The sending side (SDR, CLNTCONN) must present a personal cert from its SSLKEYR or client keystore when the partner requires it.

shell
1
2
3
4
5
6
DEFINE CHANNEL('PARTNER.IN') CHLTYPE(RCVR) TRPTYPE(TCP) + SSLCIPH('TLS_RSA_WITH_AES_256_GCM_SHA384') SSLCAUTH(REQUIRED) DEFINE CHLAUTH('PARTNER.IN') TYPE(SSLPEERMAP) CHLTYPE(RCVR) + SSLPEER('CN=qm2,O=Partner,C=US') ADDRESS('*') + MCAUSER('partmq') ACTION(MAP) * Remote SDR must present cert matching SSLPEER and trusted by SSLKEYR

Application Clients With mTLS

Java, .NET, Node, Python, and Go clients configure personal cert and CA trust in connection factories or CCDT, mirroring channel SSLCIPH. The SVRCONN should set SSLCAUTH(REQUIRED) and CHLAUTH SSLPEERMAP to a dedicated MCAUSER with minimal queue rights. Avoid mapping many different cert DNs to the same powerful MCAUSER—split by application. Containers should mount certs from secrets volumes, not bake keys into images.

Message Channels With mTLS

Queue manager to queue manager traffic uses SDR/RCVR. Mutual TLS on RCVR means the remote SDR channel initiator presents a cert identifying the sending queue manager or organization. SSLPEER patterns often include CN=QM2 or organizational O= attributes. When clustering, CLUSRCVR may use mTLS for hub connectivity. Certificate renewal on one side without updating partner trust causes all channels to fail simultaneously—use staged rollout.

Combining mTLS With CHLAUTH and OAM

  1. TLS validates certificates cryptographically.
  2. CHLAUTH SSLPEERMAP selects MCAUSER when DN matches.
  3. OAM/RACF checks MCAUSER has +put/+get on queues.

Encryption alone does not grant put access. Conversely, a valid password login cannot bypass SSLCAUTH(REQUIRED) if the channel demands a cert—clients see handshake or CHLAUTH errors instead of 2035 on put.

Explainer: Two-Way ID Check

One-way TLS is showing your driver license to enter a building. Mutual TLS is both you showing your license and the building showing its permit to you, and the guard only opens the turnstile when both documents match the approved list.

Migration From Passwords to mTLS

Phase 1: enable one-way TLS with passwords. Phase 2: SSLCAUTH OPTIONAL and issue client certs to pilot apps. Phase 3: SSLPEERMAP and test. Phase 4: SSLCAUTH REQUIRED and disable password-only USERMAP for those channels. Document rollback: temporary OPTIONAL only with change approval. Communicate DN formats to partners before cutover.

Troubleshooting mTLS

  • Handshake failure — missing client cert, wrong cipher, untrusted CA.
  • TLS OK, CHLAUTH block — SSLPEER DN mismatch after renewal.
  • RUNNING but 2035 — MCAUSER from map lacks queue authority.
  • Partner connects with old cert — parallel trust during dual-cert window.

Explain Like I'm Five: Mutual TLS

Mutual TLS means both you and your friend show secret membership cards before you swap lunch boxes, so strangers cannot pretend to be your friend.

Practice Exercises

Exercise 1

Write MQSC for RCVR with REQUIRED and one SSLPEERMAP rule for a partner CN.

Exercise 2

Compare operational steps for renewing server cert only versus both sides in mTLS.

Exercise 3

Design MCAUSER strategy: one cert per microservice versus shared service ID—tradeoffs.

Frequently Asked Questions

Frequently Asked Questions

Test Your Knowledge

Test Your Knowledge

1. Mutual TLS requires:

  • Client and server certificates
  • Password only
  • No SSLKEYR
  • NULL cipher

2. SSLCAUTH(REQUIRED) on RCVR means:

  • Partner must send client cert
  • No TLS
  • No listener
  • XMITQ required

3. SSLPEERMAP maps cert to:

  • MCAUSER
  • PORT
  • MAXDEPTH
  • TRIGTYPE

4. One-way TLS encrypts but may not:

  • Identify the client by cert
  • Use TCP
  • Use listener
  • Use queues
Published
Read time16 min
AuthorMainframeMaster
Verified: IBM MQ 9.3 documentation