| Author |
Message
|
| wattle9 |
 Posted: Mon Sep 30, 2013 10:20 pm Post subject: 2393 SSL unable to initialize - check SSL parms |
 |
|
Newbie
Joined: 30 Sep 2013
Posts: 6
|
Hi, I am trying to connect to a remote MQ channel (using RfhUtilV7.0.2) and getting this error,
"2393 SSL unable to initialize - check SSL parms".Seem the channel is secured.
Can anybody tell how to access queues in that MQ channel and read the contents? |
|
| Back to top |
|
 |
| exerk |
| Posted: Mon Sep 30, 2013 11:57 pm Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
Post the SSL parms you're using for RfhUtil, post the SSL attributes of the channel through which you're trying to connect, and then we might have a fighting chance of helping you.
_________________
It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys. |
|
| Back to top |
|
|
| Vitor |
| Posted: Tue Oct 01, 2013 4:27 am Post subject: Re: 2393 SSL unable to initialize - check SSL parms |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| wattle9 wrote: |
| Can anybody tell how to access queues in that MQ channel and read the contents? |
Correctly configure the SSL your end?
Seriously.
If you're uncertain what configuration you need, contact the MQ Admin at the other end (who's set up the SSL configuration you need to match) for details.
The channel's been secured with SSL to keep people out that the MQ Admin doesn't believe should be connecting to that queue manager. If you're able to obtain access without his assistance (i.e. via tips on this forum) then it's not that well secured is it.....?
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| JosephGramig |
| Posted: Tue Oct 01, 2013 5:05 am Post subject: |
|
|
Grand Master
Joined: 09 Feb 2006
Posts: 1231
Location: Gold Coast of Florida, USA
|
It is likely you are missing the Qmgr's signer cert.
This message indicates:
1) You have connected to the Qmgr
2) Probably specified the right cypher spec
3) Missing a CA cert for the other end
Ask who signed the Qmgrs cert and see if you have that CA. I have to guess that you are signed by a different CA. If this is so and the Qmgr requires SSl Authentication for the client, then the Qmgr will also need your CA in its keystore.
This is why life is easier when you use one CA to rule them all!
Use SSL Peer and/or CHLAUTH rules to manage the channel usage. |
|
| Back to top |
|
|
| wattle9 |
| Posted: Tue Oct 01, 2013 4:43 pm Post subject: |
|
|
Newbie
Joined: 30 Sep 2013
Posts: 6
|
Thanks for all your feedback.According to that, I have missed to enter SSL connection details. Up to now, I have not dealth with SSL enabled MQ channels.
If I am correct,I need to enter SSL connection parameters (such as user id,password, security exit data,local address, certificate store location,SSL Client validation etc) in RFHUTIL.
Would you guys be able to tell me whether I need to enter all these information or I just need to get SSL certificate and set the store location?
If I need to set the Certificate store location only, what SSL certification file (with file extension) should I request from the MQ admin? |
|
| Back to top |
|
|
| JosephGramig |
| Posted: Wed Oct 02, 2013 4:58 am Post subject: |
|
|
Grand Master
Joined: 09 Feb 2006
Posts: 1231
Location: Gold Coast of Florida, USA
|
NO. No user ID and no password and no exit.
You need to use a CCDT and the MQCHLLIB environment variable to tell RfhUtilc what channel to use and how it is defined. Read the entire section of that link to get an understanding.
Use the environment variable MQSSLKEYR to tell RfhUtilc where to find the CMS keystore that contains the certificates needed for SSL communication.
Use the GS Kit to construct the CMS keystore and if you need a JKS version, always convert the CMS keystore to a JKS keystore (it just makes a JKS copy).
Last, your MQ Administrator should be holding your hand through all this. |
|
| Back to top |
|
|
| exerk |
| Posted: Wed Oct 02, 2013 5:17 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| JosephGramig wrote: |
| You need to use a CCDT and the MQCHLLIB environment variable... |
Is that strictly true, depending on the version of WMQ being used of course? Would it not be better to encourage the use of the mqclient.ini file as the preferred method?
_________________
It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys. |
|
| Back to top |
|
|
| JosephGramig |
| Posted: Wed Oct 02, 2013 9:09 am Post subject: |
|
|
Grand Master
Joined: 09 Feb 2006
Posts: 1231
Location: Gold Coast of Florida, USA
|
exerk,
With a CCDT, I can tell RfhUtilc about many Qmgrs.
With mqclient.ini, there can only be one (is my understanding).
Of course when using SSL, you may need different keystores for different Qmgrs because they may require you to have different signers but use the same label. Why they don't let you also say what label in the keystore, I don't know. |
|
| Back to top |
|
|
| exerk |
| Posted: Wed Oct 02, 2013 9:53 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| JosephGramig wrote: |
With a CCDT, I can tell RfhUtilc about many Qmgrs.
With mqclient.ini, there can only be one (is my understanding). |
The channel stanzas within the mqclient.ini file specify where the CCDT is, and its name. It's a better way of controlling client applications as the file is looked for first in the working directory of the application,* meaning that the app does not need to set an environment (the client-related variables), or for the variables to be set globally. If you need to connect to different queue managers then a consolidated CCDT can still be used, and if the queue managers use different CA namespaces the mqclient.ini file can be used and the relevant SSL variable set prior to running RfhUtilc.
* provided the MQCLNTCF variable is not set
_________________
It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Wed Oct 02, 2013 12:42 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20697
Location: LI,NY
|
No need for variables...
The MQServer variable value is a well known format that can be used (in the qmgr field ) with RFHUtilc. In the same spirit there is a button on the first tab that will get you to a "security" tab where you can enter all the revelant SSL info... So no channel tables
Have fun 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| JosephGramig |
| Posted: Thu Oct 03, 2013 7:22 am Post subject: |
|
|
Grand Master
Joined: 09 Feb 2006
Posts: 1231
Location: Gold Coast of Florida, USA
|
wattle9,
Seems you have enough answers to get you to only be concerned about what is in your keystore and if this is bidirectional, what is in the Qmgr's keystore.
So, review my first post in this thread about what needs to be in the keystores.
In order to talk to a Qmgr, you must know what CA signed the Qmgr's certificate and have that CA in your keystore. For the Qmgr to trust you, the Qmgr must have the CA that signed you in its keystore.
Last you and the Qmgr channel need to use the same cypher spec. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Thu Oct 03, 2013 8:32 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20697
Location: LI,NY
|
| JosephGramig wrote: |
wattle9,
Seems you have enough answers to get you to only be concerned about what is in your keystore and if this is bidirectional, what is in the Qmgr's keystore.
So, review my first post in this thread about what needs to be in the keystores.
In order to talk to a Qmgr, you must know what CA signed the Qmgr's certificate and have that CA in your keystore. For the Qmgr to trust you, the Qmgr must have the CA that signed you in its keystore.
Last you and the Qmgr channel need to use the same cypher spec. |
And finally you need to have the correct values checked in SSL PEER in your Distinguished Name. Remember that if you have more than one OU values, order matters. You will see that the order is reversed if both systems do not share the same endian-ness.
Have fun
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| JosephGramig |
| Posted: Thu Oct 03, 2013 9:11 am Post subject: |
|
|
Grand Master
Joined: 09 Feb 2006
Posts: 1231
Location: Gold Coast of Florida, USA
|
fjb_saper,
Help me! Why would order matter?
With SSLPEER, you are saying match ALL these things specified exactly.
Or are you saying it is with respect to the order in the cert as well as the order in the SSLPEER value?
Like:
cert: OU=PROD,OU=QMGR
SSLPEER: OU=QMGR,OU=PROD
Those are not a match because of order? |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Thu Oct 03, 2013 1:45 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20697
Location: LI,NY
|
| JosephGramig wrote: |
fjb_saper,
Help me! Why would order matter?
With SSLPEER, you are saying match ALL these things specified exactly.
Or are you saying it is with respect to the order in the cert as well as the order in the SSLPEER value?
Like:
cert: OU=PROD,OU=QMGR
SSLPEER: OU=QMGR,OU=PROD
Those are not a match because of order? |
The latter would be a match if the client is on Windows and the server on AIX i.e. order is reversed because endian-ness is different.
However if both client and server are on AIX it would not be a match... You have to experiment a little. If you define 3 different OU entries on the DNS and in SSLPEER you can play around a little and see for yourself. And yes the OU entries in SSLPEER are order sensitive.
When experimenting be sure to look at the order on the Cert when the store was created in Unix and then the store was copied to Windows...
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| JosephGramig |
| Posted: Fri Oct 04, 2013 6:00 am Post subject: |
|
|
Grand Master
Joined: 09 Feb 2006
Posts: 1231
Location: Gold Coast of Florida, USA
|
Imagine that... It is even documented but they make no mention that the order is affected by the bitness of the platform that created the Certificate Request and/or the platform applying the SSLPEER rules. They do make it clear that this only affects the OU attribute. Of course, whenever order comes into effect, the bitness of the platform always plays a role (well, unless overridden by other code).
You know, I would have thought the bitness would have worked itself out like VHS vs Betamax or BlueRay vs HDDVD formats... |
|
| Back to top |
|
|
|
|
