Message signing in IBM MQ answers a different question than encryption: not “can anyone read this?” but “was this message changed, and did it come from the expected sender?” In payment, healthcare, and government messaging, integrity failures are as serious as confidentiality leaks—a swapped amount field or forged instruction can move money or expose personal data even when the wire was TLS-protected. IBM MQ Advanced Message Security (AMS) applies digital signatures through policies so producers sign on put and consumers verify on get. Operators with queue browse authority may still see cleartext if encryption is not also enabled, but they cannot silently alter a signed message and pass verification without the sender’s private key. This tutorial explains what signing guarantees, how it differs from encryption and channel TLS, AMS policy attributes for signing, key and certificate roles, common deployment patterns, failure handling, compliance language for auditors, and troubleshooting when verification fails in test or production.
A digital signature is computed over the message (and associated protected headers per AMS rules) using the sender’s private key. The consumer uses the sender’s public certificate to verify the signature. If a single byte changes in storage, on a backup tape, or during a malicious edit, verification fails. Signing supports non-repudiation in the business sense when key custody is controlled: the organization that holds the private key is accountable for messages that verify successfully. Signing does not hide field values from someone with +browse on the queue—that requires encryption. Signing does not replace OAM: a user without +get still cannot consume the message, but signing adds assurance that the payload they receive is authentic when they do get it.
| Control | Protects against | Does not |
|---|---|---|
| Channel TLS | Network eavesdropping, weak peer identity on wire | Tampering after QM stores message |
| AMS signing | Undetected alteration on queue; wrong sender (with PKI) | Hide payload from browser |
| AMS encryption | Confidentiality at rest on queue | Prove sender without signing policy |
| OAM (+get) | Unauthorized applications opening queue | Crypto integrity of bytes |
When an AMS policy marks a queue (or name pattern) as requiring signing, the AMS-enabled client or queue manager extension computes the signature at MQPUT time and stores the signed envelope with the message. The queue manager persists the signed form like any other message; backup and replication copy the signature with the payload. On MQGET, AMS verifies before returning plaintext to the application. If the producer did not sign, or used an expired certificate, or the message was corrupted, the get fails with a reason the application must handle—typically no partial delivery of tampered content. Batch consumers and microservices must use AMS-aware libraries consistently; a “plain” get client against a signed queue fails even when OAM grants +get.
123456/* Conceptual AMS signing flow (not executable MQSC) */ /* Policy: Queue PAYMENT.IN requires Sign */ /* 1. Producer MQPUT -> AMS signs with producer private key */ /* 2. Message on queue includes signature block */ /* 3. Consumer MQGET -> AMS verifies with producer public cert */ /* 4. Application receives payload only if verify OK */
AMS policies are deployed to queue managers and name the queues or patterns, the required protection (sign, encrypt, or both), algorithms approved by your security team, and how recipients or verifiers are identified. A sign-only policy is appropriate for audit trails on non-secret events (status codes, public market data) where integrity matters more than secrecy. A sign-and-encrypt policy is standard for PCI or HIPAA payloads. Algorithm choice affects performance and compliance: legacy algorithms may be disabled by corporate standard even if IBM still lists them for backward compatibility—always align with your security architecture document. Policy changes are change-control events: altering a queue from unsigned to signed without updating all producers causes sudden put failures in production.
Signing keys are asymmetric: the producer signs with a private key stored in a keystore (AMS keystore or enterprise HSM integration per your platform). Verifiers hold the matching public certificate, often distributed via internal PKI. Rotation requires overlapping trust: deploy new producer cert, update policy trust stores, run dual-sign or dual-verify window, retire old keys. Lost private keys mean you cannot produce new valid signatures for that identity; compromised private keys require revocation and incident response. Never embed private keys in source control. On z/OS and distributed platforms, the operational model is the same even if keystore file names differ—document which team owns signing certs for each application ID.
Message signing is like sealing a letter with wax stamped with your ring. Anyone can read the letter if the envelope is transparent (no encryption), but if the wax is broken or the stamp wrong, the recipient knows someone opened or changed it. Encryption is putting the letter in a locked box; signing is the wax seal on the box or the paper itself.
Point-to-point queues with one producer and one consumer are the easiest signing story. Hub queue managers that forward messages may re-put messages; whether the signature survives depends on AMS and forwarding behavior in your release—often the consuming application on the final queue verifies the original producer’s signature only if the message was forwarded without stripping AMS envelope. Clustering and alias queues do not magically re-sign; architects document which hop is the “system of record” for signature verification. When a bridge application reads and writes without AMS, integrity is lost unless the bridge re-signs with its own identity (changing non-repudiation semantics—document that the bridge attests, not the original core banking system).
Auditors ask whether a downstream system can prove message origin. Successful AMS verification plus controlled key custody supports that narrative. Logs should correlate MQ message identifiers, signing certificate distinguished names, and application transaction IDs. Signing does not replace database audit tables—it strengthens the messaging layer. Legal and compliance teams distinguish technical non-repudiation from contractual liability; your security officer defines which certificate authorities and key lengths are acceptable.
Compare one unsigned test queue with a signed production queue. Capture AMQ and client reason codes. Use DISPLAY QSTATUS and application logging around the failing MQGET. Escalate to PKI team when cert chains are incomplete.
Some teams add HMAC or JSON Web Signature in the payload before MQPUT. That can work but duplicates effort: OAM does not understand app-level signatures, and support staff may not know to verify them. AMS centralizes policy on the queue manager and standardizes client behavior. Application-level signing still appears in hybrid cloud integrations where AMS is not licensed on every node—document the boundary clearly in integration architecture.
Signing adds CPU per message and a small size overhead for the signature block. High-throughput queues need load testing with signing enabled. MAXMSGL must accommodate growth. Consider signing only on boundaries that need audit (settlement files) while leaving high-volume telemetry unsigned unless regulation requires otherwise.
Signing is your special sticker on your homework so the teacher knows nobody else changed your answers before they read it.
Draw put and get flow for a queue with sign-only AMS policy. Label where TLS ends and where verify runs.
List three production incidents signing would detect that TLS alone would not.
Write a change plan for enabling signing on an existing cleartext queue with ten producers.
1. Message signing primarily provides:
2. Signing without encryption means:
3. AMS verifies signatures on:
4. TLS plus AMS signing is: