Certificate renewal is the operational discipline of replacing TLS certificates before they expire on every IBM MQ queue manager, channel, and mutual-TLS client. Expired certificates cause sudden handshake failures that look like network outages—channels in RETRY, SVRCONN clients failing MQCONNX, and batch windows missed because nobody tracked notAfter dates in the kdb. Renewal is more than importing a file: it coordinates corporate PKI, runmqakm import, CERTLABL and SSLCERTLABL updates, partner trust stores, CHLAUTH SSLPEERMAP when distinguished names change, and controlled channel restarts. This tutorial walks through inventory and monitoring, generating CSRs and receiving signed chains, parallel-label cutover strategy, partner notification, DR queue managers, rollback plans, and post-renewal validation checklists for beginners managing their first enterprise renewal weekend.
Export certificate expiry from every SSLKEYR: runmqakm -cert -list -db path -stashed and parse notAfter, or use enterprise monitoring that probes TLS endpoints. Record queue manager name, hostname, CERTLABL, channel names using SSLCERTLABL, and business owner. Alert at 90, 60, and 30 days. Include mutual-TLS client certificates stored in partner repositories—not only queue manager server certs.
| Phase | Activities | Risk if skipped |
|---|---|---|
| Plan | CSR, maintenance window, partner notice | Unplanned outage |
| Build | Import to kdb with new label | Bad chain, wrong key |
| Test | Clone channel, test handshake | Prod failure |
| Cutover | ALTER CERTLABL, cycle channels | Brief disconnect |
| Verify | AMQERR01 clean, apps connect | Silent partial failure |
| Retire | Remove old label after soak | Confusion next year |
123456runmqakm -cert -create -db key.kdb -stashed -label qm1_2027 -dn 'CN=qm1.prod.example,O=Corp,C=US' -size 2048 * Submit CSR to PKI; receive signed chain + intermediates runmqakm -cert -add -db key.kdb -stashed -label ca_int -file intermediate.cer runmqakm -cert -receive -db key.kdb -stashed -label qm1_2027 -file qm1_signed.cer ALTER QMGR CERTLABL('qm1_2027') * Test channel before prod cutover
Import intermediates before the personal cert so chain validation succeeds. If PKI delivers PKCS12, use -cert -import with -type pkcs12. Protect files during transfer—use secure ticket attachments, not email without encryption.
Keep qm1_2026 and qm1_2027 both in the kdb during migration. Point a test SVRCONN to SSLCERTLABL('qm1_2027') while production channels remain on 2026. After validation, ALTER production channels or swap default CERTLABL and restart channels in batches by business priority. Soak one week before deleting the old label from kdb.
Notify partners of new public cert or CA if trust changes. They import into their SSLKEYR trust store. If CN or O in the DN changes, update SET CHLAUTH SSLPEERMAP rules on both sides before cutover. Mutual-TLS clients need new personal certs distributed to application keystores with the same lead time.
Renewal is getting a new library card before the old one expires. If the new card has a different number (DN), tell every librarian (CHLAUTH) the new number or they will not let you in.
Renew every cluster member and DR standby—drift causes failover to a node with expired cert. Automate kdb sync to DR site with encrypted replication. Test failover after renewal on DR, not only on primary.
Your hall pass expires Friday. Get a new pass on Wednesday and test it on one door before all doors switch on Friday morning.
Write a renewal runbook with rollback for one queue manager.
List partner notifications when only the CA issuer changes.
Design parallel-label test plan for SVRCONN.
1. Renewal should start before:
2. New cert often uses:
3. Expired cert causes:
4. CHLAUTH SSLPEER update needed when: