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 Version 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. Note: Where the entry states Likely to fail this is because, if the specific CipherSpec configured happens to be the CipherSpec that is strongest for the client and queue manager, the TLS handshake resolves to using it, and so matches the channel SSCIPH value.

If, however, there is a stronger CipherSpec that both client and Server support, even if this is not configured on the SSLCIPH attribute of the server channel, then the TLS handshake will resolve to using this and will not match the SSLCIPH setting of the server channel.

The first table shows the expected behavior when TLS 1.3 is not enabled on either the client (each row), server (each column) or both.

Client /Server
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
The second table shows the expected behavior when TLS 1.3 is enabled on both the client (each row) and server (each column).

Client / Server 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
Parent topic: Enable CipherSpecs


Related concepts


Related information