SSL/TLS and clusters

When configuring TLS for clusters, be aware a CLUSRCVR channel definition is propagated to other queue managers as an auto-defined CLUSSDR channel. If a CLUSRCVR channel uses TLS, we must configure TLS on all queue managers that communicate using the channel.

For more information about TLS, see TLS security protocols in IBM MQ. The advice there is generally applicable to cluster channels, but you might want to give some special consideration to the following:

In an IBM MQ cluster a particular CLUSRCVR channel definition is frequently propagated to many other queue managers where it is transformed into an auto-defined CLUSSDR. Subsequently the auto-defined CLUSSDR is used to start a channel to the CLUSRCVR. If the CLUSRCVR is configured for TLS connectivity the following considerations apply:

• All queue managers that want to communicate with this CLUSRCVR must have access to TLS support. This TLS provision must support the CipherSpec for the channel.
• The different queue managers to which the auto-defined cluster-sender channels have been propagated will each have a different distinguished name associated. If distinguished name peer checking is to be used on the CLUSRCVR it must be set up so all of the distinguished names that can be received are successfully matched.

  For example, let us assume that all of the queue managers that will host cluster-sender channels which will connect to a particular CLUSRCVR, have certificates associated. Let us also assume that the distinguished names in all of these certificates define the country as UK, organization as IBM, the organization unit as IBM MQ Development, and all have common names in the form DEVT.QMnnn, where nnn is numeric.

  In this case an SSLPEER value of C=UK, O=IBM, OU=IBM MQ Development, CN=DEVT.QM* on the CLUSRCVR will allow all the required cluster-sender channels to connect successfully, but will prevent unwanted cluster-sender channels from connecting.

• If custom CipherSpec strings are used, be aware that the custom string formats are not allowed on all platforms. An example of this is that the CipherSpec string RC4_SHA_US has a value of 05 on IBM i but is not a valid specification on UNIX, Linux or Windows systems. So if custom SSLCIPH parameters are used on a CLUSRCVR, all resulting auto-defined cluster-sender channels should reside on platforms on which the underlying TLS support implements this CipherSpec and on which it can be specified with the custom value. If we cannot select a value for the SSLCIPH parameter that will be understood throughout the cluster we will need a channel auto definition exit to change it into something the platforms being used will understand. Use the textual CipherSpec strings where possible (for example TLS_RSA_WITH_AES_128_CBC_SHA).

An SSLCRLNL parameter applies to an individual queue manager and is not propagated to other queue managers within a cluster.

• 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.
• Disabling SSL/TLS on clustered queue managers and channels
  To turn off TLS, set the SSLCIPH parameter to ' '. Disable TLS on the cluster channels individually, changing all the cluster receiver channels before the cluster sender channels.

Parent topic: Keeping clusters secure