We have two connections (as a .NET/Windows client) to an IBM MQ endpoint (let's say non-Windows).
We use SSL, which is supported by a pair of certificates (client and server) and correctly labelled in the Windows Certificate Store to ensure we pick the right certificate.
Everything in Queue A works fine.
Queue B has recently stopped working. We now get a 2538 error. Nothing has changed.
It feels like there may be a communication error inhibiting successful SSL handshake.
The problem is exacerbated by the WebSphereMqClient
NuGet package we use (8.0.0.7 - latest version) not giving us anything other than a 2538 error on calling:
_mqQueueManager = new MQQueueManager((string)queueManager, (Hashtable)connectionProperties);
Connection Properties being (redacted):
<IbmMqConnection server="ipaddress"
portNumber="1234"
channel="SOME.CHANNEL"
queueManager="QUEUE_MANAGER">
<SecureConnection enabled="True"
cipherSuite="TLS_RSA_WITH_AES_256_CBC_SHA256"
cipherSpec="TLS_RSA_WITH_AES_256_CBC_SHA256"
peerName="CN=trusted-parties-cn"
certificateLabel="ibmwebspheremq"
/>
Is there anything an expert could give us a clue on? Is there a way to get any diagnostics out of the NuGet black box?
Update 1:
The server is running 8.0.0.9.
Update 2:
@JoshMc suggested I turn on logging.
From this, I learn:
mqclient.ini
file in the binary folder or my personal folder.System.ComponentModel.Win32Exception (0x80004005): The credentials supplied to the package were not recognized
MQTCPConnection.ConnectSocket(string,string,MQLONG) rc=OK
00000174 10:29:28.917526 5748.1 CompCode: 2, Reason: 2538
AMQ9202: Remote host 'x.x.x.x(y)' not available, retry later.
CompCode: 2, Reason: 2538
System.ComponentModel.Win32Exception (0x80004005): The credentials supplied to the package were not recognized
I have double checked that the user does have permission to the Private Key.
Update 3
Issue found.
The issue was highlighted by the text System.Security.Authentication.AuthenticationException: The remote certificate is invalid according to the validation procedure.
. On investigation it turns out that the permissions on the Private Key had been removed during a certificate renewal. I know the above says the permissions were confirmed to be there, but for a different certificate. I've left it in to retain history/honesty.
Issue was resolved by enabling the logging, as suggested by @JoshMc.
The log entry:
000001C9 11:16:51.194536 2072.1 System.Security.Authentication.AuthenticationException: The remote certificate is invalid according to the validation procedure.
at IBM.WMQ.Nmqi.MQEncryptedSocket.MakeSecuredConnection()
at IBM.WMQ.Nmqi.MQEncryptedSocket..ctor(NmqiEnvironment env, MQTCPConnection conn, Socket socket, MQChannelDefinition mqcd, MQSSLConfigOptions sslConfigOptions)
at IBM.WMQ.MQTCPConnection.ConnectSocket(String localAddr, String connectionName, Int32 options)
... led us straight to the issue, which was that the credentials used to access the private keys in the Windows Certificate Store were invalid. On investigation, they were not present.
Make sure that you include this step as part of your procedures for renewing SSL certificates.
The NuGet package is just the stand-alone amqmdnet.dll
that IBM lets you relocate from a full MQ client install or download via the redistributable client zip file.
If you want to have them turn on a trace for a stand-alone Managed .NET MQ Client you need to follow the instructions at Developing applications > Developing .NET applications > Writing and deploying IBM MQ .NET programs > Using the stand-alone IBM MQ .NET client.
You start by adding the following to your app.config and point the value to a directory that you can create a file in.
<appSettings> <add key="MQTRACECONFIGFILEPATH" value="C:\MQTRACECONFIG" /> </appSettings>
You then create a file called trace.config
in the above directory with the following contents where the MQTRACEPATH
and MQERRORPATH
point to a directory that the user running your application can write to.
<?xml version="1.0" encoding="utf-8"?> <traceSettings> <MQTRACELEVEL>2</MQTRACELEVEL> <MQTRACEPATH>C:\MQTRACEPATH</MQTRACEPATH> <MQERRORPATH>C:\MQERRORLOGPATH</MQERRORPATH> </traceSettings>
Note that you can toggle the MQTRACELEVEL
between 2
and 0
to dynamically turn tracing on or off for a running program.
On the MQIPT side of things if you use the stock mqipt.ske
to start your MQIPT instance you can set the env variable MQIPT_JVM_OPTIONS="-Djavax.net.debug=ssl"
before you start MQIPT, this will cause java to provide TLS debug logging to mqipt.stdout.log
in the logs
directory.
User contributions licensed under CC BY-SA 3.0