Relationship between alias CipherSpec settings

This information describes the expected behavior with different combinations of alias CipherSpecs in client and server configurations. Here, a client refers to the entity initiating communication, for example a client application or a queue manager sender channel, and server refers to the entity receiving the communication from the client, for example a server-connection channel or a receiver channel.

Minimum protocol versus fixed protocol CipherSpecs

IBM® MQ supports two different types of CipherSpecs:

Minimum protocol: Minimum protocol CipherSpecs are those that do not set an upper bound, for example ANY, ANY_TLS12_OR_HIGHER or ANY_TLS13_OR_HIGHER.
Fixed protocol: Fixed protocol CipherSpecs are those that identify a specific protocol, for example ANY_TLS12 and ANY_TLS13, or a specific algorithm such as ECDHE_ECDSA_3DES_EDE_CBC_SHA256.

From IBM MQ 9.2.0, minimum and fixed protocol CipherSpecs are supported on all platforms.

To maximize simplicity of configuration whilst maintaining security, the use of minimum protocol CipherSpecs is recommended on both sides of the channel. This allows your communications to automatically support and use a higher TLS protocol version when both sides support a new version without the need for changing either side's configuration.

Using a minimum protocol CipherSpec on the initiating side, but a fixed protocol CipherSpec on the receiving side could result in the connection being rejected, and

Messages AMQ9631 and AMQ9641 being issued.
Messages CSQX631E and CSQX641E being issued.

The following tables show the relationship between different alias CipherSpec settings and the expected outcome. Table 1 shows the expected behavior when TLS 1.3 is not enabled on either the client, server, or both. Table 2 shows the expected behavior when TLS 1.3 is enabled on both the client and server. In both cases, the CipherSpecs for the client are shown in the Y axis of the table, and the CipherSpecs for the server are shown in the X axis of the table.

Note: In the following tables, cells marked Likely to fail indicate the potential for conflict when you specify a minimum protocol CipherSpec for one part of a connection, and a specific (fixed protocol) CipherSpec for another part.

For example, suppose the client and server are set to use ANY CipherSpec, and the server channel is set to use a specific CipherSpec:

If the strongest supported CipherSpec for both the client and server matches the specific CipherSpec configured on the channel, the TLS handshake resolves successfully.
If, however, there is a stronger CipherSpec that both the client and Server support, the TLS handshake resolves to using this, even though it does not match the CipherSpec specified on the channel, and the TLS handshake fails.

Table 1. Expected behavior when TLS 1.3 is not enabled on either the client, server, or both
	Server
Client	Specific TLS 1.2 CipherSpec	ANY	ANY_ TLS12	ANY_TLS12_ OR_HIGHER
Specific TLS 1.2 CipherSpec	Connects	Connects	Connects	Connects
ANY	Likely to fail	Connects	Connects	Connects
ANY_ TLS12	Likely to fail	Connects	Connects	Connects
ANY_TLS12_ OR_HIGHER	Likely to fail	Connects	Connects	Connects

Table 2. Expected behavior when TLS 1.3 is enabled on both the client and server
	Server
Client	Specific TLS 1.2 CipherSpec	Specific TLS 1.3 CipherSpec	ANY	ANY_TLS12	ANY_TLS13	ANY_TLS12_ OR_HIGHER	ANY_TLS13_ OR_HIGHER
Specific TLS 1.2 CipherSpec	Connects	Fails	Connects	Connects	Fails	Connects	Fails
Specific TLS 1.3 CipherSpec	Fails	Connects	Connects	Fails	Connects	Connects	Connects
ANY	Fails	Likely to fail	Connects	Fails	Connects	Connects	Connects
ANY_TLS12	Likely to fail	Fails	Connects	Connects	Fails	Connects	Fails
ANY_TLS13	Fails	Likely to fail	Connects	Fails	Connects	Connects	Connects
ANY_TLS12_ OR_HIGHER	Fails	Likely to fail	Connects	Fails	Connects	Connects	Connects
ANY_TLS13_ OR_HIGHER	Fails	Likely to fail	Connects	Fails	Connects	Connects	Connects