Use SSL
In a WebSphere 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 SSL connectivity the following considerations apply:
- All queue managers that want to communicate with this CLUSRCVR must have access to SSL support. This SSL provision must support the CipherSpec for the channel.
- The different queue managers to which the auto-defined CLUSSDRs 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 CLUSSDRs 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 WebSphere MQ Development, and all have common names in the form DEVT.QMxxx, where xxx is numeric.
In this case an SSLPEER value of C=UK, O=IBM, OU=WebSphere MQ Development, CN=DEVT.QM* on the CLUSRCVR will allow all the required CLUSSDRs to connect successfully, but will prevent unwanted CLUSSDRs from connecting.
- If custom CipherSpec strings are used, be aware that the string formats are different on different platforms. An example of this is the CipherSpec string RC4_SHA_US has a value of 05 on z/OS and 0x6801, 128, 0x8004 on Windows. So if custom SSLCIPH parameters are used on a CLUSRCVR, all resulting auto-defined CLUSSDRs should reside on platforms on which the underlying SSL support implements this CipherSpec and on which it can be specified with the custom value. If you cannot select a value for the SSLCIPH parameter that will be understood throughout your WebSphere MQ cluster you 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 RC4_MD5_US).
When upgrading the queue managers in a cluster to WebSphere MQ V5.3, users are advised to upgrade their full repository queue managers first. The new SSL parameters are flowed through the cluster. If not all parts of the cluster are running WebSphere MQ V5.3, these parameters are discarded by the first queue manager not at V5.3 they encounter. The following example describes what happens if you do not upgrade your full repository queue managers first.
- Say you have a queue on a V5.3 partial repository queue manager and you want to access it from another V5.3 partial repository queue manager. You specify a CLUSRCVR on the first partial repository and give it SSL parameters. This flows to the second partial repository through a full repository.
- If the full repository is on a V5.3 queue manager, the SSL parameters are passed through it and a successful SSL connection is established between the two partial repositories. If the full repository is not on a V5.3 queue manager, it discards the SSL parameters without error and forwards the depleted auto-defined CLUSSDR object to the second partial repository. This is then used to attempt a connection to the SSL CLUSRCVR which will fail.
An SSLCRLNL parameter applies to an individual queue manager and is not propagated to other queue managers within a cluster.
WebSphere is a trademark of the IBM Corporation in the United States, other countries, or both.
IBM is a trademark of the IBM Corporation in the United States, other countries, or both.