Since IBM MQ was first released in 1993 the security landscape has continuously evolved. From new security deployments, certifications and minimum requirements; the expectations on products and deployments have changed drastically in the past 30 years.

If you have been running IBM MQ for a while, you may have grown accustomed to a long list of supported cipher specifications covering everything from SSLv3 through to TLS 1.3. 
However, it is important for you to be aware that IBM MQ 10 removes support for SSLv3 and TLS 1.0 entirely on Distributed platforms. These protocols are no longer negotiable, no longer configurable, and no longer available as a fallback. If your queue managers, channels, or client applications are still relying on them, they will fail to connect after upgrading.

You must take action to ensure you can continue to operate once you migrate. This post explains why IBM MQ made this decision and how to migrate safely.

Note: While support for SSLv3 and TLS 1.0 has been withdrawn from Distributed platforms, it is still possible to use SSLv3 and TLS 1.0 on Z queue managers and Java/JMS applications connecting to z queue managers. However, the direction the industry is moving means that this is a transitory period and it is likely that in the (near) future SSLv3 and TLS 1.0 support will disappear from other platforms and client technologies. As such regardless of what platform or client technology you use, it is worthwhile reading this blog post if you still use SSLv3 and TLS 1.0 to understand what options you have should more support be withdrawn.

SSLv3 and TLS 1.0 timeline

Below is a timeline of both the SSLv3 and TLS 1.0 protocols' life, adoption into IBM MQ and when and where we put deprecation and removal notices.

Why SSLv3 and TLS 1.0 were removed

Support for cryptographic operations within IBM MQ is entirely dependent on the various cryptographic libraries we use, for example: GSKit, SystemSSL, JSSE, .NET. While most of the cryptographic functions we use are available across all the differing cryptographic libraries, sometimes we do see differences in availability of function. For example, not every library supports the ML-KEM algorithms we use for Quantum Safe TLS functionality. Previously we also saw a different rate of adoption of TLS 1.3.

For SSLv3 and TLS 1.0, the cryptographic library we use on Distributed queue manager, c and unmanaged .NET clients has removed support. And this support has been dropped following advice from the IETF, industry sentiment and SSLv3 and TLS 1.0 having been deprecated and weak since 2015 and 2021.

What steps do I need to take to migrate to version 10 of IBM MQ?

Before upgrading to MQ 10, audit your queue managers for channels still using removed cipher specs. One way is via runmqsc:

DISPLAY CHANNEL(*) SSLCIPH

Look for any channel where SSLCIPH is set to one of the removed values. You can also check client connection tables (.tab / .json CCDT files) and any application connection strings that specify a cipher directly.

Once you know which channels need updating you have a few options:

1. Modify the channels to use TLS 1.2 or above Cipherspecs. You will need to update both sides of the channel which could require code changes to your applications depending on how you implemented TLS communications. When upgrading, it is recommended to migrate to Alias CipherSpecs like ANY_TLS12_OR_HIGHER as these provide greater flexibility on CipherSpec selection and can future-proof your deployments if more CipherSpecs are removed in the future.
2. If it is not possible to change your CipherSpec then another option is to use IBM MQ Internet Pass-Thru (MQIPT) or any other TLS termination system to provide a communication re-encryption service. For example if your client application cannot be updated to use a modern CipherSpec, you can place MQIPT between the application and queue manager and configure the MQIPT route to accept the SSLv3 communication from the application and route it to the queue manager where it will convert it to a TLS 1.3 communication. However, please note, that this is available as of time of writing. As the SSLv3 and TLS 1.0 deprecation is a global industry statement it is possible that in future releases Java will remove support for SSLv3 and TLS 1.0 and at that point MQIPT will not be an option.
3. Another option if your application is running with IBM MQ 7.1 or newer and is unable to be updated via CCDT or programmatically; is to use a PreConnect exit to modify the MQCONN call to inject a stronger TLS 1.2 or higher CipherSpec. You can find example code of a PreConnect exit that can achieve this here.

Conclusions

The removal of SSLv3 and TLS 1.0 in IBM MQ 10 has been long coming - it is the end of a journey that began with the POODLE vulnerability in 2015, was formalised by the IETF in 2021, and has been signalled by IBM MQ in two announcement letters. The underlying cryptographic libraries have simply reached the point where they will no longer carry these protocols, and IBM MQ follows suit.

The key takeaway is straightforward: if you are running channels on SSLv3 or TLS 1.0 cipher specs today, you must act before upgrading to MQ 10. The recommended path is to migrate to an alias CipherSpec such as ANY_TLS12_OR_HIGHER, which gives you modern security and the flexibility to absorb future cipher changes without revisiting every channel definition. Where that is not immediately possible, MQIPT provides a short-term bridge, and the PreConnect exit offers a targeted escape hatch for legacy applications that cannot be recompiled.

The broader message is that keeping pace with cryptographic standards is now a routine part of MQ operations. TLS 1.3 is already the gold standard, and quantum-safe TLS is slowly being rolled out as an expected minimum way of operation. Auditing your cipher specs before an upgrade and favouring alias CipherSpecs over hardcoded values are habits that will serve you well beyond this particular change.