| Author |
Message
|
| bbburson |
 Posted: Mon May 16, 2005 8:23 am Post subject: WMQ Cluster with SSL - not working |
 |
|
Partisan
Joined: 06 Jan 2004
Posts: 378
Location: Nowhere near a queue manager
|
I am trying to set up a WMQ cluster to use SSL between the queue managers and I'm hitting a brick wall. Nothing I've found in the manuals or on this site has helped yet, so I'm hoping somebody else has tamed this beast already.
The environment: Sun 5.9, WMQ 5.3, csd08. Two queue managers defined on the same server, both are full repositories for the cluster, listeners binding to separate ports.
First I set up the cluster and verified the cluster channels run and messages get moved around the cluster as they should.
Then on both queue managers I stopped the CLUSRCVR and CLUSSDR channels. Stopped/started the queue managers themselves just to make sure the cluster would be down.
On both queue managers I altered the CLUSRCVR and CLUSSDR definitions to include SSLCIPH(NULL_MD5). Then I started the CLUSRCVRs and then started the CLUSSDRs. Both CLUSSDRs show RETRYING status. The error logs for each queue manager show "AMQ9641: Remote CipherSpec error for channel ..."
I've tried lots of combinations of SSLCIPH (defined on both CLUSSDR and CLUSRCVR, defined on CLUSRCVR only, defined on CLUSSDR only); and I've tried specifying/not specifying SSLPEER in the various combinations as well.
The only way I can get the cluster channels to run is by removing SSLCIPH altogether and letting them be "normal" (nonSSL) channels.
Just to make sure my certificates are correct, I created point-to-point SDR/RCVR channel pairs between these same two queue managers and defined SSLCIPH(NULL_MD5) on all of them. The channels come up fine and display the correct SSLPEER value in "DIS CHS".
What am I missing? How can I get SSL activated between the queue managers in the cluster?
Thanks in advance for any help or suggestions. |
|
| Back to top |
|
 |
| fjb_saper |
| Posted: Mon May 16, 2005 10:58 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
Could it be that in the automatically created cluster sender (pair to your cluster receiver) the crypto protocol (SSLCIPH)is not set ?
Check both ends of the channel pairs and make sure that the SSL characteristics appear on both of them.
As the channels are generic, may be you are not allowed a mix of cipher / non cipher or even ciphers with different protocols on the same cluster channel comming from potentially 2 different qmgrs.
You might need to have a security exit on the channel. But then again I don't know how that comes to play into consideration when we look at the part of the channel that's created dynamically....
Enjoy  |
|
| Back to top |
|
|
| Anirud |
| Posted: Mon May 16, 2005 12:00 pm Post subject: |
|
|
Master
Joined: 12 Feb 2004
Posts: 285
Location: Vermont
|
How about doing this...
Alter your SYSTEM.DEF.CLUSRCVR and SYSTEM.DEF.CLUSSDR for SSLCIPH value and then define your cluster receiver channels on both the queue managers (not sure if this will work if you already have a cluster setup).
Not sure if this will work as I haven't tried it... just a thought.
Hope this helps. |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Mon May 16, 2005 12:43 pm Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
I suspect you have to do a complete refresh of the cluster.
I did a search in this forum for 'ssl' and found an old message from JasonE in which he said you had to enable SSL on all the CLSRCVRs, allow that to propagate through the cluster and then enable SSL on the CLSSDRS.
It makes some sense - if you think about how senders are based on receiver models in a cluster. How can I update the cluster about my changed receivers until I've been updated about the FR's changed receivers? And I can't do that until I can ask for an update!
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| bbburson |
| Posted: Mon May 16, 2005 12:59 pm Post subject: |
|
|
Partisan
Joined: 06 Jan 2004
Posts: 378
Location: Nowhere near a queue manager
|
Thanks for the rapid responses. I worked on this all afternoon Friday and all morning today and then posted my questions here. After lunch I tried one more time modifying the channel definitions to include sslciph -- the only difference is this time I did not stop the channels first. And what do you know, THEY WORK now!!
I guess the channel definitions are dynamic enough that the sslciph change can flow across the cluster if the channels are up when the change is made; but if they are stopped to begin with then the queue managers are not able to connect to let each other know about the changes.
For what it's worth, I did not have to make any changes to the SYSTEM... objects, nor did I have to RESET or REFRESH the cluster. |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Mon May 16, 2005 1:22 pm Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
Ah.
Okay. So, the channels were running at the time of the change... so the change could be propagated around the network - and presumably the channels were then restarted to use the new defs (either by you or the system).
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
|
|
