sslibm-mqbiztalkbiztalk-2016msmqbinding

Microsoft MQ Client binding in BizTalk Server causing handshake failure with SSL connection to IBM MQ


After successfully connecting to IBM MQ 9.1 with the IBM MQ Client with SSL, we're trying to setup the same configuration, but this time, with the Microsoft MQ Client binding.

So this should be straight forward, once HIS 2016 is configured (CU2 is installed). But not in my case.

The following error was thrown on the BizTalk Server 2016 (CU6 installed) with event source 'HIS Microsoft Client for MQ':

Connecting to a Queue Manager failed: Could not Connect the Queue Manager 'test': Could not connect to the target Host/Port, SSL handshake failed.

The following error was thrown on the IBM MQ Server machine:

Internal error on call to SSL function on channel '????' to host '<ip address>'.  
An error indicating a software problem was returned from a function which is used to provide SSL or TLS support. 
The error code returned was '447'. The function call was 'gsk_secure_soc_init'. &P The channel is '????'; in some cases its name cannot be determined  and so is shown as '????'. 
The channel did not start. &P The remote host name is '<ip address>'.  

So it's throwing a 447 error, which IBM explains as follows:

The TLS server or client encountered a communicating partner that does not support a TLS extension that is defined as required.  
Ensure that the TLS extension data is correctly defined, and that both the TLS server and client support the required extension. 
If the problem persists collect a System SSL trace and contact your service representative. 

The MQSC Transport properties on the BizTalk receive location looks something like this:

I did not change anything to the bindings except the 'Use Microsoft MQ Client' part of course. This is a working setup when used with the IBM MQ Client with SSL. So I'm wondering why all of the sudden it will not work with the Microsoft MQ Client.


Solution

  • The Microsoft MQ client can also utilize other certificate stores, such as the Windows computer or user store, instead of the IBM key database. In addition, .NET automatically chooses the cipher. As such, it might be preferable for channels to have the cipher type of ANY_TLS12_OR_HIGHER.

    There have been some known issues with SSL connections between the Microsoft MQ client and the IBM MQ.NET client. However, these issues have been or are being resolved and are planned to be included in the HIS 2020 CU1 MQSC adapter update.

    There is also a private fix available upon support request, which has shown to improve the situation. Hence, it might be best to use the latest IBM MQI client, versions 9.2.x or 9.3.x, and the most recent HIS 2020 MQSC private fix. Alternatively, users can wait until the CU1 update is released.