Upgrading clustered queue managers and channels to SSL/TLS
Upgrade the cluster channels one at a time, changing all the CLUSRCVR channels before the CLUSSDR channels.
Before starting
Consider the following considerations, as these 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 is only be able to use the CipherSpecs supported by each release.
To use a new CipherSpec within a cluster, we 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.
Attention: It is not possible to use a mixture of Elliptic Curve-signed certificates and RSA-signed certificates on queue managers that we 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.
Upgrade all queue managers in the cluster to IBM MQ V8 or higher, if they are not already at these levels. Distribute the certificates and keys so that TLS works from each of them.
To upgrade to, or use any of the alias CipherSpecs (ANY_TLS13, ANY_TLS13_OR_HIGHER, ANY_TLS12, ANY_TLS12_OR_HIGHER, and so on), we must upgrade all IBM MQ for Multiplatforms queue managers in the cluster to Version 9.1.4 or higher, and all IBM MQ for z/OS queue managers in the cluster to Version 9.2.0 or higher.
Change the CLUSRCVR channels before the CLUSSDR channels.
Procedure
- Switch the CLUSRCVR channels to TLS in any order you like, changing one CLUSRCVR at a time, and allow the changes to flow through the cluster before changing the next. Important: Make sure that we do not change the reverse path until the changes for the current channel have been distributed throughout the cluster.
- Optional: Switch all manual CLUSSDR channels to TLS. This does not have any effect on the operation of the cluster, unless we use the REFRESH CLUSTER command with the REPOS(YES) option. Note: For large clusters, use of 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.
- Use the DISPLAY CLUSQMGR command to ensure that the new security configuration has been propagated throughout the cluster.
- Restart the channels to use TLS and run REFRESH SECURITY (SSL).
Parent topic: SSL/TLS and clusters
Related concepts
Related information