Cipher suites define how IBM MQ encrypts and authenticates bytes on a TLS channel—key exchange, bulk encryption, and message authentication algorithms bundled into one negotiated choice. The channel attribute SSLCIPH names the suite (or specification string) your queue manager offers; the partner must accept it during the GSKit handshake. When operations upgrades security and sets AES-only on production while a legacy partner still offers DES or RC4, channels enter retry loops with SSL errors that look like network outages. This tutorial explains what SSLCIPH means, how negotiation works between client and server, common suite families and why AES-GCM replaced CBC for many estates, aligning SSLCIPH on SDR, RCVR, and SVRCONN pairs, global protocol restrictions, performance considerations, documenting approved cipher allow-lists, and troubleshooting cipher mismatch without disabling TLS entirely.
DEFINE or ALTER CHANNEL with SSLCIPH sets the cipher for that channel object. Sender and receiver in a pair should specify compatible values—many sites copy the same SSLCIPH to both SDR and RCVR. SVRCONN and client connection factory must agree with the server SVRCONN SSLCIPH. Empty or default SSLCIPH may use queue manager defaults depending on version—never rely on defaults in production; set explicitly in runbooks.
12345DEFINE CHANNEL('APP.SVRCONN') CHLTYPE(SVRCONN) TRPTYPE(TCP) + SSLCIPH(TLS_RSA_WITH_AES_256_GCM_SHA384) SSLCAUTH(REQUIRED) DEFINE CHANNEL('PARIS.TO.LONDON') CHLTYPE(SDR) TRPTYPE(TCP) + SSLCIPH(TLS_RSA_WITH_AES_256_GCM_SHA384) CONNAME('london.example(1414)') * Strings must match IBM supported names for your GSKit level
| Family | Modern posture | Notes |
|---|---|---|
| AES-GCM (e.g. AES_256_GCM) | Preferred | AEAD, good performance on modern CPU |
| AES-CBC with SHA-256 | Acceptable if policy allows | Older than GCM; still common |
| 3DES / RC4 / NULL | Deprecated—disable | Compliance failures; remove from estate |
| RSA key exchange suites | Varies by hash and enc | Match PKI key size (2048+) |
The TLS client sends ClientHello with supported protocols and ciphers. The server responds with ServerHello picking one suite from the intersection of client list and server SSLCIPH configuration. MQ does not magically upgrade weak partners—you must change both sides or the channel definition on the stricter side to include a shared option for migration windows only.
Cipher suites apply within a TLS protocol version. Disabling TLS 1.0 at the GSKit or queue manager level removes suites tied to old protocols. Some enterprises set global minimum TLS 1.2 in addition to per-channel SSLCIPH. Client Java versions ship with their own disabled algorithms—an old JRE may not offer GCM even when MQ does.
Cipher suite is the secret language two walkie-talkies agree to speak so nobody else understands. If one radio only speaks French and the other only German, they never connect—even if they are standing next to each other.
Cluster channels multiply cipher alignment work. Standardize one approved SSLCIPH per environment tier (prod, test) in infrastructure-as-code. During MQ version upgrades, re-run cipher compatibility matrix against top ten partners. Document exceptions for vendors who lag crypto updates with dated sunset plans.
High-volume channels benefit from AES-NI capable hardware and GCM suites. Profiling during load test reveals CPU spent in GSKit versus message processing. Cipher changes during incidents should be tested on a clone queue manager before production ALTER CHANNEL.
Cipher suites are the secret handshake code you and your friend agree on before sharing secrets. If you pick different codes, the secrets stay locked.
Document approved SSLCIPH for prod SVRCONN and SDR pairs.
Explain failure when Java client offers only TLS 1.0 ciphers.
Compare AES-GCM versus AES-CBC for a 5000 msg/sec channel.
1. SSLCIPH is set on:
2. Cipher mismatch causes:
3. Weak ciphers should be:
4. Partner must support: