Migrating existing security configurations to use an alias CipherSpec
Migrating existing secure channel definitions to use an alias CipherSpec, for example, ANY_TLS12_OR_HIGHER, ANY_TLS13_OR_HIGHER, and so on, 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 an alias CipherSpec is no different from the process we 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, we need to update manually defined channel definitions to a full repository one at a time.
To simplify migration, you make the change to specify an alias CipherSpec on a channel definition pairing on the responding message channel agent (that is SVRCONN, RCVR, and so on) first. For example, if the channel definition currently uses a specific TLS 1.2 CipherSpec, then modifying the responding message channel agent to use ANY_TLS12_OR_HIGHER allows the sending message channel agent to continue using the specific TLS 1.2 cipher.
If we plan to change an existing cluster to use alias CipherSpecs, you first need to ensure that all members of the cluster are at IBM MQ Version 9.1.4, or higher, and if there are z/OS queue managers in the cluster, these need to be at IBM MQ Version 9.2.0 or higher, in order 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 use an alias CipherSpec, the negotiation of the TLS cipher varies, based on the availability of different algorithms on platform and maintenance levels.
Note, that although no assurance can be made on the exact CipherSpec that is chosen, the channel will only use the TLS protocol allowed by the alias CipherSpec considering FIPS, SUITEB, and weak CipherSpec deprecations and re-enablement on both peers.Attention: Alias CipherSpecs do not guarantee that a specific CipherSpec will be used on a running channel, only that the negotiated CipherSpec is enabled and acceptable to IBM MQ on both ends of the channel. To request that a specific CipherSpec is used by a channel, we must specify that specific value on both ends of the channel.If you add support for a new CipherSpec to the IBM MQ installations on the initiating and responding ends of the channel, the alias CipherSpec will allow this new CipherSpec to be used automatically without making any configuration changes.
Parent topic: Migrating IBM MQ
Related information