0

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:

  • Use Microsoft MQ Client : Yes
  • SSL Cipher Specification: TLS_RSA_WITH_AES_256_CBC_SHA
  • SSL Key Repository Location: D:\Somepathtocert
  • Transport Type: TCP
  • SSL Peer name is kept empty.
  • User Id is kept empty.

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.

r3verse
  • 1,000
  • 8
  • 19
  • Do you have any other tls SVRCONN channels that are working on the same queue manager? – JoshMc Apr 17 '19 at 08:39
  • The following link indicates the queue manager cert may have a problem: https://www-01.ibm.com/support/docview.wss?uid=ibm10794723 – JoshMc Apr 17 '19 at 08:49
  • Yes, a few others. Some with the same Cipher spec, some with another Cipher spec and some without SSL configured. – r3verse Apr 17 '19 at 08:56
  • @JoshMc If the cert has a problem, why did it work on the IBM owned client then? I'm willing to try, but it sounds weird. – r3verse Apr 17 '19 at 08:58
  • In that case do you have a client cert specified? – JoshMc Apr 17 '19 at 09:13
  • Yeah it's configured as the 'SSL Key Repository Location', which i kept identical to the IBM client configuration. – r3verse Apr 17 '19 at 09:21
  • Does the process that connects to MQ run under the same user name in both working and non working setups? – JoshMc Apr 17 '19 at 09:29
  • That's a tricky one, it's probably a different user. Does it matter? – r3verse Apr 17 '19 at 09:38
  • @r3verse There's more to it than just changing the client. You also have to configure the certs for the MQSC client because it works different than the IBM client. Did you follow those instructions? – Johns-305 Apr 17 '19 at 11:52
  • What is the cert label in the key store? – JoshMc Apr 17 '19 at 11:54
  • There is no cert label, at least not when i look in MQ Explorer. What do you exactly mean with the "You also have to configure the certs for the MQSC client because it works different than the IBM client." I don't see how it's different. – r3verse Apr 17 '19 at 14:07
  • I'm asking about the cert label in the kdb for the clients private key. – JoshMc Apr 18 '19 at 00:10
  • Note without @pinging someone they will not get alerted to your response, I just happened to check this question again today. – JoshMc Apr 18 '19 at 00:13
  • Did you resolve this? – JoshMc Apr 23 '19 at 08:56
  • @JoshMc i didn't solve it since it doesn't have any priority. I am by no means an MQ expert so could you maybe clarify the "it works different than the IBM client" part? – r3verse May 19 '19 at 18:18
  • I didn't make that comment. @Johns-305 did. I asked you to list the certs in the kdb and tell me the label of the client cert – JoshMc May 19 '19 at 19:39
  • Sorry @JoshMc, got you mixed up. So the label name is 'ibmwebspheremqtest'. – r3verse May 20 '19 at 08:57
  • Is the user that the process making the mq connection runs under called "test"? – JoshMc May 20 '19 at 10:31
  • @JoshMc .. I'm sorry, it's the cert label from the server key. How can i easily obtain the label name for the client? – r3verse May 20 '19 at 11:18
  • @JoshMc so i found out the label is ibmwebspheremqmqq050 because that's the only one returned by 'runmqckm -cert -list -db keyfilename.kdb'. I guess that's incorrect? You have any idea why this works on the IBM client and not on the Microsoft one? – r3verse May 20 '19 at 12:05
  • Is the user name of the process `mqq050`? If not, the label should replace that with the username in lowercase. Is this a self-signed cert? If it is not you should have any signers also. Normally a intermediate and root cert. – JoshMc May 20 '19 at 13:31
  • @JoshMc, it isn't. If i'd make a certificate with the right username, then i should add it to te server cert store as well as the client store as well, right? – r3verse May 20 '19 at 13:53
  • Cross adding certs is only required if they are not signed by a CA. If the existing cert is trusted by the queue manager you can always "rename" the label to the right label, or added a cert label reference to the mqclient.ini file to tell MQ what the label is. I don't have those references handy, but check out the link to [[tag:ibm-mq]] and select "Learn More" and find the link to the IBM MQ Knowledge center for v9.1. You can search this. – JoshMc May 20 '19 at 14:24

2 Answers2

2

SSL Cipher Specification is not considered in the MSFT MQ client, while the IBM MQ client use the configured cipher.

The MS MQ client only use default Windows cipher (first choice in the adapter list), so you have to set the same cipher in the MQ channel that you use.

so depends on the default Cipher in Windows, your IBM should be configured.

Thanks for my colleague Niklas Engfelt for testing this.

Ahmed Kelani
  • 21
  • 3
1

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.

Lopofsky
  • 518
  • 6
  • 15
r4v3n6
  • 26
  • 1