Cipher Specs

Cipher specifications are the vocabulary IBM MQ uses when you set SSLCIPH on a channel or listener. Each string selects a bundle of algorithms: how keys are exchanged, whether RSA or ECDHE is used, whether bulk encryption is AES-256-GCM or an older CBC mode, and which hash signs the handshake. Choosing specs is a balance between security policy and partner compatibility—a bank hub may mandate TLS 1.2+ with AEAD ciphers only, while a legacy factory system still negotiates older RSA_CBC_SHA256 until a migration project lands. Mismatch between sender and receiver is one of the fastest ways to stall channels in BINDING with errors that mention GSKit or handshake failure. This tutorial explains how to read IBM cipher spec names, compare strength tiers, align SDR/RCVR and SVRCONN/client CCDT, phase out weak options, and relate cipher choice to mutual TLS and certificate types without duplicating the full SSLCIPH attribute reference page.

How SSLCIPH Works on Channels

When TCP connects, the TLS layer negotiates the highest mutually supported cipher from the SSLCIPH value configured on the IBM MQ side and the client or partner configuration. On message channels both SDR and RCVR (or both cluster sender/receiver) need compatible specs. On SVRCONN, the client CCDT or MQCD SSLCipherSpec must align with the channel SSLCIPH. Listeners can set SSLCIPH to constrain inbound connections before the channel name is known. Changing SSLCIPH requires restarting or cycling channel instances—plan maintenance windows.

Example cipher spec families (illustrative—verify against IBM docs for your release)
Example SSLCIPH-style nameCharacteristicsGuidance
TLS_RSA_WITH_AES_256_GCM_SHA384TLS 1.2, RSA key exchange, AES-256-GCMCommon enterprise choice; ensure RSA key size adequate
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256Forward secrecy with ECDHEPreferred where both sides support ECDHE
TLS_RSA_WITH_AES_256_CBC_SHA256CBC mode encryptionLegacy compatibility; plan migration to GCM
TLS_CHACHA20_POLY1305_SHA256TLS 1.3 style AEAD (names vary)Modern stacks; confirm MQ 9.x platform support
NULL / EXPORT / DES (historical)Weak or no encryptionDisable; never on production

TLS 1.2 Versus TLS 1.3

TLS 1.3 reduces handshake round trips and removes obsolete algorithms from the default set. IBM MQ 9.x adds support for newer specs on platforms as documented in each fix pack readme. Mixed estates run TLS 1.2 on older partners and TLS 1.3 on internal microservices—document minimum versions per connection class. Operating system and Java levels on clients also cap available protocols; upgrading only the queue manager is insufficient if the client OS cannot speak TLS 1.3.

Comparing Cipher Strength

  • Prefer AEAD (GCM, ChaCha20-Poly1305) over CBC for new designs.
  • Prefer ECDHE key exchange for forward secrecy when partners support it.
  • Avoid NULL encryption, single DES, EXPORT-grade, and SSLv3 entirely.
  • Match RSA key length (2048+ bits) and ECC curves to corporate PKI standards.
  • Align mutual TLS with cipher specs that support client cert authentication you use.

Compliance frameworks (PCI-DSS, HIPAA) publish prohibited algorithms—map those lists to IBM SSLCIPH strings explicitly in your standards document rather than saying “use strong TLS.”

Configuring Channel and Client Ciphers

shell
1
2
3
4
ALTER CHANNEL('QM1.TO.QM2') CHLTYPE(SDR) SSLCIPH('TLS_RSA_WITH_AES_256_GCM_SHA384') ALTER CHANNEL('QM1.TO.QM2') CHLTYPE(RCVR) SSLCIPH('TLS_RSA_WITH_AES_256_GCM_SHA384') ALTER CHANNEL('APP.SVRCONN') CHLTYPE(SVRCONN) SSLCIPH('TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256') * Client CCDT must use the same or compatible SSLCipherSpec string

Explainer: Lock and Key Grade

Cipher specs are the grade of lock on the truck door. AES-GCM is a modern deadbolt; NULL cipher is a plastic clip. Partners must agree on the same lock grade or the door never closes (handshake failure).

Migration From Weak Ciphers

  1. Inventory current SSLCIPH on all channels with DISPLAY CHANNEL(*) SSLCIPH.
  2. Identify partners still requiring CBC or old RSA key sizes.
  3. Lab test stronger spec on duplicate channel names.
  4. Schedule production ALTER during agreed window; monitor BINDING.
  5. Remove weak specs from organizational allow-list after last partner moves.

Relationship to SSLCAUTH and Certificates

Cipher specs control encryption strength; SSLCAUTH controls whether a client certificate is required. You can run strong AES-GCM with one-way TLS (server cert only) or add SSLCAUTH(REQUIRED) for mutual TLS. Certificate key type (RSA versus EC) must match cipher suites that support your cert algorithm—ECDSA personal certs need suites that negotiate ECDSA signatures.

Explain Like I'm Five: Cipher Specs

Cipher specs are the secret code language two walkie-talkies use so nobody else can understand—but both walkie-talkies must be set to the same language number or they only hear static.

Practice Exercises

Exercise 1

Run DISPLAY CHANNEL(*) SSLCIPH in a lab QM and classify each spec as modern or legacy.

Exercise 2

Partner requires CBC; write a migration email asking them to support GCM with target date.

Exercise 3

Handshake fails after ALTER SSLCIPH—list three log locations to check on both sides.

Frequently Asked Questions

Frequently Asked Questions

Test Your Knowledge

Test Your Knowledge

1. SSLCIPH selects:

  • Cipher suite
  • Queue name
  • User ID
  • Trigger type

2. Weak legacy protocol to disable:

  • SSLv3
  • TLS 1.3
  • AES-GCM
  • MQSC

3. AES-GCM is an example of:

  • AEAD cipher
  • Queue type
  • DLQ policy
  • Topic wildcard

4. Cipher mismatch usually fails at:

  • TLS handshake
  • MQGET only
  • Backup
  • STRMQM
Published
Read time15 min
AuthorMainframeMaster
Verified: IBM MQ 9.3 documentation