| Author |
Message
|
| huwgb |
 Posted: Mon May 20, 2013 9:39 pm Post subject: SSL on Solaris with Websphere MQ 7.0.1.3 |
 |
|
Novice
Joined: 07 May 2013
Posts: 21
|
Hello there,
I am getting close to my wits end in troubleshooting an SSL Server-connection channel between Datapower and Solaris.
Datapower running XI52.5.0.0.5
Websphere MQ Running 7.0.1.3 on SunOS 5.10 i386
SSL was initially setup as follows on them both:
Cipher Spec: TLS_RSA_WITH_AES_128_CBC_SHA
This gave me the following error:
| Quote: |
There is a mismatch between the CipherSpecs on the local and remote ends of the channel 'DP.CHL'. The channel will not run until this mismatch is resolved. The CipherSpec required in the local channel definition is 'TRIPLE_DES_SHA_US'. The name of the CipherSpec negotiated during the
SSL handshake is 'RC4_MD5_US'. A code is displayed if the name of the negotiated CipherSpec cannot be determined.
ACTION:
Change the channel definitions for 'DP.CHL' so the two ends have matching CipherSpecs and restart the channel. If the certificate in use by one end of the channel is a Global Server Certificate, then the negotiated CipherSpec may not match that specified on either end of the channel. This is because the SSL protocol allows a Global Server Certificate to automatically negotiate a higher level of encryption. In these cases specify a CipherSpec which meets the requirements of the Global Server Certificate.
|
I went ahead and changed the CipherSpecs on both sides to match 'RC4_MD5_US' and I got the same error (just with the CipherSpec Required being 'RC4_MD5_US' and the CipherSpec Negotiated being 'RC4_MD5_US').
I than cracked open RFHUtilC, created a DP.TBL.CHL, configured SSL and attempted the same connection. Only to get the following exception:
| Quote: |
The SSL connection was closed by the remote end of the channel during the SSL handshake. The channel is '????'. The channel did not start.
ACTION:
Check the remote end of the channel for SSL-related errors. Fix them and restart the channel. |
When I disable SSL both RFHUtil and Datapower successfully connect.
At the moment I am trying to figure out how to determine if I have a Global Server Certificate. I have created a self-signed certificate for WebSphere MQ on the solaris box and exported the public key to Datapower but get the same error.
Switching to SupportPac ma0t I tried again and got a little more information out of it:
| Quote: |
15:21:48 E041 MQCONNX client connection to QMgr="<qmgr>" failed, CC=2, RC=2393.
15:21:48 E197 MQBACK from ConnQMgr="<qmgr>" failed, CC=2, RC=2018
15:21:48 E043 MQDISC from ConnQMgr="<qmgr>" failed, CC=2, RC=2018. |
I have had no issues establishing connections between windows machines running WMQ 7.5.0.0 and the Datapower box and I do not believe I have permission to upgrade WMQ on Solaris to a newer version without proof that the version of WMQ is causing me grief.
I started an WMQ trace and tried again. As expected it produced many files but I am honestly not sure what I should be looking for in them.
Any ideas of what I can do next to troubleshoot or what I should look for in the trace?
It does appear as if I have two separate issues here, one with datapower and one with any other client... any hints about either issue would be appreciated. |
|
| Back to top |
|
 |
| fjb_saper |
| Posted: Tue May 21, 2013 4:39 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
What parts of the DN (Distinguished Name ) are you checking in SSLPEER if any?
Also for the correct exchange:
MQ needs the public cert of the client (flowed over the channel) and the CA cert that signed the public cert of the client (in it's keystore as a CA cert).
The client needs the public cert of the qmgr (flowed over the channel) and the CA cert that signed the qmgr's cert in it's truststore.
Now understand that CA Cert here means the whole signer chain from root cert to last intermediate signer cert.
Also can you specify how the different certs were created and what encryption algorithms are supported?
Have fun 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| huwgb |
| Posted: Tue May 21, 2013 3:52 pm Post subject: |
|
|
Novice
Joined: 07 May 2013
Posts: 21
|
Cracked it (at least for the RFHUtil and ma0t client connection)
A fresh day a fresh mind as they say.
First off, Thank you fjb_saper for your quick response.
I grabbed both sets of key/truststores and went through each CA cert one at a time and noticed the following:
Even though all CA's were in both key/trust stores and both specified valid timestamps and the IBM key manager tool recognised them as the same CA's. I noticed the dates between the two were different. I deleted the CA's that were created earlier and replaced them so both sets matched.
Hey presto, SSL connection worked straight away...
I can only assume that someone re-issued the CA certificates at some point in the last two years and forgot to update the MQ server I have been trying to connect to...
I would have thought if the CA certs still presented a valid date it would just work.
Something I should have checked first instead of trying to understand the very confusing error message I was seeing.
Now I just need to get the Datapower guy to turn on SSL so we can verify that the CipherSpec error I was seeing was caused by the same issue. Very confusing error message if it is... |
|
| Back to top |
|
|
| huwgb |
| Posted: Wed Jun 05, 2013 5:36 pm Post subject: |
|
|
Novice
Joined: 07 May 2013
Posts: 21
|
Turns out I was having two separate issues.
After fixing the CA certificates it would appear that I am still getting CipherSpec mismatches.
Another developer mentioned that last time this happened is was because the versions of GSKit did not match (GSKit7 on the Solaris server and whatever Datapower uses for cryptography configured on it's own server).
That would mean upgrading WMQ to a fixpack with GSKit8 and creating another Queue Manager instance linked to GSKit8 (To prevent problems with the other clients connecting on the existing queue manager).
Has anyone come across an issue like this before? Does the explanation sound even feasible?
I must admit I have not been able to put as much time as I wish to investigating this as it is only a very small part of my duties here =( |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Thu Jun 06, 2013 6:52 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
If it is due to the version of gskit I would be surprised. It might be due to the type of certs and algorithms supported by them.
Usually using RSA is a good start. However and depending on environment you may have to use other algorithms.
Make sure the compatibility is there. Also consider the imperatives of FIPS...
If FIPS is mandatory, or used, a non FIPS connection is not authorized to anywhere else...
Have fun
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| huwgb |
| Posted: Thu Jun 06, 2013 3:02 pm Post subject: |
|
|
Novice
Joined: 07 May 2013
Posts: 21
|
Hahaha,
The Datapower Admins gave me access to the box to play with the SSL Proxy configuration.
First thing I noticed:
SSL CipherSpec on the Connections tab of the QM config correctly stated: TLS_RSA_WITH_AES_128_CBC_SHA
However, an SSL Proxy Profile was defined
Which Had Ciphers set to: HIGH:MEDIUM:!aNULL:!eNULL:@STRENGTH
I modified that to: AES128-SHA
and set: Permit Connections to Insecure SSL Servers to On
And Bang. Connected straight away.
There is another datapower QM Object (connecting to MQ 7.5) configured in the same way. Ciphers set to HIGH:MEDIUM:!aNULL:!eNULL:@STRENGTH and using an SSLProxy rather than a GSKit artifact. It had no problem establishing a connection, Possibly because the way Cipherspecs are negotiated during handshakes changed between GSKit7 and 8?? Or changed between MQ 7.0.1.3 and 7.5?
Link below shows the correlation between CipherSpecs and CipherSuites for Datapower SSL Proxies
http://pic.dhe.ibm.com/infocenter/wsdatap/v5r0m0/topic/com.ibm.dp.xi.doc/commandreference.xi50934.htm?path=4_4_0_63_23#ssl_mqqm
Thank you fjb_saper for all your suggestions and help. |
|
| Back to top |
|
|
|
|
