Migrating existing security configurations to use the ANY_TLS12_OR_HIGHER CipherSpec
Migrating to the ANY_TLS12_OR_HIGHER CipherSpec means that your enterprise can adapt to cipher additions and deprecations without needing to make further invasive configuration changes in the future.
In general terms, the migration step to use the ANY_TLS12_OR_HIGHER CipherSpec is no different from the process you use to change any CipherSpec. That is, change the value of the CipherSpec for the channel definition at each end, and then restart the channels for the change to take effect.
The procedure described in the preceding text can be particularly challenging in clustering environments. Typically, you need to update manually defined channel definitions to a full repository one at a time.
To simplify migration, you make the change to specify ANY_TLS12_OR_HIGHER on a channel definition pairing on the responding message channel agent (that is SVRCONN, RCVR, and so on) first. This approach allows any channels that were previously designed to use a specific TLS 1.2 cipher to continue to work using that specific CipherSpec.
If you plan to change an existing cluster to use ANY_TLS12_OR_HIGHER, you first need to ensure that all members of the cluster are at IBM® MQ 9.1.4, or higher, to understand the new CipherSpec value. The procedure for migration is the same as migrating from plaintext to SSL or TLS. See Upgrading clustered queue managers and channels to SSL/TLS for more information.
Once both initiating and responding channel definitions have ANY_TLS12_OR_HIGHER set as the CipherSpec, the negotiation of the cipher to use varies, based on the availability of different algorithms based on platform and maintenance levels.
If you add support for a new CipherSpec to the IBM MQ installations on the initiating and responding ends of the channel, the ANY_TLS12_OR_HIGHER CipherSpec will allow this new CipherSpec to be used automatically without making any configuration changes.