Upgrading clustered queue managers and channels to TLS

This task helps you to upgrade to TLS successfully, while causing the least impact to currently running cluster channels. Upgrade the full repositories before the partial repositories, and upgrade the CLUSRCVR channels before the CLUSSDR channels.

Before you begin

The following considerations might affect your choice of CipherSpec for a cluster:
  • Some CipherSpecs are not available on all platforms. Take care to choose a CipherSpec that is supported by all of the queue managers in the cluster.
  • Some CipherSpecs might be new in the current IBM® MQ release and not supported in older releases. A cluster containing queue managers running at different MQ releases can only use the CipherSpecs supported by all releases in the cluster. To use a new CipherSpec within a cluster, you must first migrate all of the cluster queue managers to the current release.
  • Some CipherSpecs require a specific type of digital certificate to be used, notably those that use Elliptic Curve Cryptography. You cannot use a mixture of Elliptic Curve-signed certificates and RSA-signed certificates on queue managers that you want to join together as part of a cluster. Queue managers in a cluster must all use RSA-signed certificates, or all use EC-signed certificates, not a mixture of both. See Digital certificates and CipherSpec compatibility in IBM MQ for more information.
Before you can upgrade to, or use, any of the alias CipherSpecs (ANY_TLS13, ANY_TLS13_OR_HIGHER, ANY_TLS12, ANY_TLS12_OR_HIGHER, and so on) you must upgrade your queue managers. Distribute the certificates and keys so that TLS works from each of them.
  • [UNIX, Linux, Windows, IBM i]Upgrade all IBM MQ for Multiplatforms queue managers in the cluster to IBM MQ 9.1.4 or later.
  • [z/OS]Upgrade all IBM MQ for z/OS® queue managers in the cluster to IBM MQ for z/OS 9.2.0 or later.

This upgrade is simpler if you don't use cluster namelists. If you do use them, consider splitting your CLUSRCVR channels out into one per cluster while you're changing things. See Managing channel definitions.

About this task

To enable cipher specs on all cluster channels, complete the following steps. Note that the keys to a successful upgrade are these:
  • Upgrade the full repositories before the partial repositories.
  • Upgrade the CLUSRCVR channels before the CLUSSDR channels.

Procedure

  1. Switch the CLUSRCVR channels to TLS, changing one CLUSRCVR at a time, and allow the changes to flow through the cluster before changing the next.
    Important: Make sure that you do not change the reverse path until the changes for the current channel have been distributed throughout the cluster.
  2. Switch all manual CLUSSDR channels to TLS.

    This ensures the matching CLUSSDRs are updated in a timely manner.

    This does not have any effect on the operation of the cluster, unless you use the REFRESH CLUSTER command with the REPOS(YES) option.

    Note: For large clusters, using the REFRESH CLUSTER command can be disruptive to the cluster while it is in progress, and again at 27 day intervals thereafter when the cluster objects automatically send status updates to all interested queue managers. See Refreshing in a large cluster can affect performance and availability of the cluster.
  3. Use the DISPLAY CLUSQMGR command to ensure that the new security configuration has been propagated throughout the cluster.
  4. Restart the channels to use TLS then run REFRESH SECURITY TYPE(SSL).
  5. Verify that the repositories are talking to each other using ciphers.
    Run the following commands:
    Display chs () where (chltype eq clussdr) all or SSLCIPH STATUS
Display chs () where (chltype eq clusrcvr) all or SSLCIPH STATUS
    Status is displayed for both manual and auto-defined cluster senders.