Understanding CipherSpec mismatches
A CipherSpec identifies the combination of the encryption algorithm and hash function. Both ends of a WebSphere MQ SSL channel must use the same CipherSpec, although they can specify that CipherSpec in a different manner. Mismatches can be detected at two stages:
- During the SSL handshake
- The SSL handshake fails when the CipherSpec specified by the SSL client is unacceptable to the SSL support at the SSL server end of the connection. A CipherSpec failure during the SSL handshake arises when the SSL client proposes a CipherSpec that is not supported by the SSL provision on the SSL server. For example, when an SSL client running on AIX proposes the TLS_RSA_WITH_AES_128_CBC_SHA CipherSpec to an SSL server running on i5/OS.
- During channel startup
- Channel startup fails when there is a mismatch between the CipherSpec defined for the responding end of the channel and the CipherSpec defined for the calling end of channel. Channel startup also fails when only one end of the channel defines a CipherSpec.
Refer to Specifying CipherSpecs for more information.
If Global Server Certificates are used, a mismatch can be detected during channel startup even if the CipherSpecs specified on both channel definitions match.
Global Server Certificates are a special type of certificate which require that a minimum level of encryption is established on all the communications links with which they are used. If the CipherSpec requested by the WebSphere MQ channel configuration does not meet this requirement, the CipherSpec is renegotiated during the SSL handshake. This is detected as a failure during WebSphere MQ channel startup as the CipherSpec no longer matches the one specified on the channel.
In this case, change the CipherSpec at both sides of the channel to one which meets the requirements of the Global Server Certificate. To establish whether a certificate that has been issued to you is a Global Server Certificate, contact the certificate authority which issued that certificate.
SSL servers do not detect mismatches in the following circumstances:
- When an SSL client channel on UNIX or Windows (at WebSphere MQ V6.0 or higher) specifies the DES_SHA_EXPORT1024 CipherSpec, and the corresponding SSL server channel on UNIX or Windows (at WebSphere MQ V6.0 or higher) is using the DES_SHA_EXPORT CipherSpec
- When an SSL client channel on UNIX or Windows (at WebSphere MQ V6.0 or higher) specifies the DES_SHA_EXPORT1024 CipherSpec and the corresponding SSL server channel on Windows (at WebSphere MQ V5.3) is using the DES_SHA_EXPORT CipherSpec
- When an SSL client channel on Windows (at WebSphere MQ V5.3) specifies the DES_SHA_EXPORT CipherSpec and the corresponding SSL server channel on UNIX or Windows (at WebSphere MQ V6.0 or higher) is using the DES_SHA_EXPORT1024 CipherSpec
WebSphere MQ does not detect these mismatches for one or both of the following reasons:
- At V5.3, WebSphere MQ cannot change the handshake key size at channel start on Windows systems, so WebSphere MQ for Windows does not support the DES_SHA_EXPORT1024 CipherSpec. The operating system SSL support might set the handshake key size to 1024 bits based, for example, on information held in the certificates.
- On all platforms, the SSL support cannot detect which platform is at the other end of the SSL channel.
In these circumstances, the channel runs normally.
Parent topic:
Working with CipherSpecs
sy12930_