| Author |
Message
|
| bbburson |
 Posted: Tue Dec 04, 2007 1:26 pm Post subject: Merging clusters with conflicting SSLPEER requirements |
 |
|
Partisan
Joined: 06 Jan 2004
Posts: 378
Location: Nowhere near a queue manager
|
Consider this situation:
Company ABC has a cluster named ABCCLUSTER consisting of three queue managers, ABCFR1, ABCFR2, ABCPR1. The cluster sender/receiver channels are defined for SSL and require SSLPEER to be CN=ABCCLUSTER*. Each queue manager has a digital certificate with the correct attributes for this arrangement. All is well in Company ABC.
Company XYZ has a cluster named XYZCLUSTER consisting of three queue managers, XYZFR1, XYZFR2, XYZPR1. The cluster sender/receiver channels are defined for SSL and require SSLPEER to be CN=XYZCLUSTER*. Each queue manager has a digital certificate with the correct attributes for this arrangement. All is well in Company XYZ.
Then one day the two companies merge and the hapless WMQ support staff is charged with (a) merging the WMQ clusters while (b) maintaining the cluster security provided by the SSL configuration.
If SSL were not a requirement it would be easy to either define a separate set of CLUSSDR/CLUSRCVR channels for the second cluster, or use a NAMELIST to hold the names of the clusters and modify CLUSNL attributes appropriately.
The problem is that each queue manager can have one and only one digital certificate for itself (label 'ibmwebspheremqqmgrname'). And if the attributes on the certificates conflict then it is hard/impossible to match them up using SSLPEER.
I see two possible solutions, neither of which is ideal:
1) remove SSLPEER checking from the CLUSSDR/CLUSRCVR definitions; this defeats the primary purpose of using SSL in the first place, which is to limit cluster membership.
2) replace *ALL* queue manager certificates with new ones using a new scheme for SSLPEER matching; I think this would have to be a flash-cut all-at-the-same-time conversion which gives me chills just thinking about it.
Questions: Is there another way to approach this problem that I am not seeing? How would you go about trying to solve this dilemma?
I'm looking forward to your insights.
Thanks, |
|
| Back to top |
|
 |
| jefflowrey |
| Posted: Tue Dec 04, 2007 1:28 pm Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
I thought SSLPEER took multiple entries?
Edit: 
Nope.
Security exit, to map sslpeer values?
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Tue Dec 04, 2007 3:36 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
Is the purpose of SSL here really an authentication of the sending qmgr or more about preventing a qmgr without the relevant certificate (non encrypted) access?
Have you thought about creating an additional cluster receiver chl on ABC for the XYZ cluster with CN=XYZ* in essence keeping the cluster channels separate each servicing a different cluster? (and vice versa in XYZ)
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Tue Dec 04, 2007 4:07 pm Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
| fjb_saper wrote: |
| Have you thought about creating an additional cluster receiver chl on ABC for the XYZ cluster with CN=XYZ* in essence keeping the cluster channels separate each servicing a different cluster? (and vice versa in XYZ) |
You'd end up with a partially or fully overlapped set of clusters this way (i.e., require the CLUSNL).
And the requirement still exists to install ABC certs on all XYZ machines, and vice versa.
bbburson rejected this, due to some notion of SSL conflicts in doing so.
I can't personally think of a reason why it wouldn't work, but I haven't tried it.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Tue Dec 04, 2007 4:21 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| jefflowrey wrote: |
| fjb_saper wrote: |
| Have you thought about creating an additional cluster receiver chl on ABC for the XYZ cluster with CN=XYZ* in essence keeping the cluster channels separate each servicing a different cluster? (and vice versa in XYZ) |
You'd end up with a partially or fully overlapped set of clusters this way (i.e., require the CLUSNL).
|
Did not quite understand your remark.
i.e. cluster qmgr in ABC
cluster rcvr chl= TO.MYQMGR cluster(ABC) sslpeer(CN=ABC*)
cluster rcvr chl= TO.MYQMGR.XYZ cluster(XYZ) sslpeer(CN=XYZ*)
now add a cluster sender to the XYZ full repository and you should be member of both clusters... talking on different channels...
The cluster name list only works if you need/want to keep the same channel name...
I don't know that there is anything in MQ that forces you to use the same cluster channel receiver name on a qmgr for all the clusters you are a member of.
You will have to use a cluster name list for queues however if you have any queues that are to be part of both clusters... and be addressed through the same name (no diff name through aliases)...
And yes you will have the overhead of adding certificates etc to the other side of the cluster... might be easier and less disturbing than a big bang until you can clear it all up...
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| bbburson |
| Posted: Mon Dec 10, 2007 8:35 am Post subject: |
|
|
Partisan
Joined: 06 Jan 2004
Posts: 378
Location: Nowhere near a queue manager
|
Thanks for the ideas and suggestions. Sorry for being so slow responding but last week was busy and it took some time to try out the various options.
What I have figured out from all my experimentation is that joining the clusters using the *existing* SSL certificates and SSLPEER rules is not possible. No matter what extra channels get defined, sooner or later it comes down to each queue manager having access to one and only one digital certificate for itself and when that certificate is presented for the channel connection it must meet the SSLPEER rules on the other end. |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Mon Dec 10, 2007 9:36 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
FJ's response... should... have functioned, although you would also have seen error messages that suggested it didn't function.
That is, if there are two clusrcvrs "TO.QMGR1ABC" and "TO.QMGR1XYZ", with different CLUSTER attributes and different SSLPeer values on the QMGR1.
Then when QMGR2, which is in XYZ cluster and using XYZ cert and SSLPeer, tries to connect... it should FAIL on TO.QMGR1ABC, and SUCCEED on TO.QMGR1XYZ.
So it should work, but be very noisy and leave lots of channels in retry.
Edit: Thinking about it... QMGR1 is never going to start channels that are not using the SSLPeer that belongs to it's cert, I think.
So if QMGR1 is in ABC Cluster and using ABC cert, then I guess it might never be able to accept a cert for XYZ, and thus start the channel for XYZ?
Argh.
Time to retreat to your empirical evidence!
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Mon Dec 10, 2007 3:05 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| Quote: |
| Then when QMGR2, which is in XYZ cluster and using XYZ cert and SSLPeer, tries to connect... it should FAIL on TO.QMGR1ABC, and SUCCEED on TO.QMGR1XYZ |
And here I thought that it would not want to connect on TO.QMGR1ABC as this is clearly an ABC cluster chl. I would have expected it to use the XYZ cluster chl only... Maybe not.... Has anybody tried this out? 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| JosephGramig |
| Posted: Tue Dec 11, 2007 11:44 am Post subject: |
|
|
Grand Master
Joined: 09 Feb 2006
Posts: 1244
Location: Gold Coast of Florida, USA
|
So, let's see...
Requirement: Have QMGRs in multiple clusters with multiple CA's.
Constraint: A QMGR can only have one CA.
So, if both QMGR key stores have both the CA keys, then this should work. Did you try this with both the CA keys in the QMGR key stores?
This issue should exist between any two QMGRs with different CAs clustered or not. Or even a client and a QMGR with different CAs. Don't you think?
Sounds like the same thing described here http://publib.boulder.ibm.com/infocenter/wmqv6/v6r0/topic/com.ibm.mq.csqzas.doc/sy11710_.htm.
What I "think" is going on, is that the QMGR checks its key store to see if it knows the signer of the inbound key. It should allow inbound traffic from anybody that is signed by a known CA. Then the SSLPEER is being used to restrict that further.
If I get a chance, I will try that scenario. Note that the InfoCenter is demo-ing two different signers in the "Task 1" section.
So, what is to prevent somebody in your organization from generating a cert request with CN="ABCCLUSTER FlyingPigs" and joining their QMGR to your cluster?
_________________
Joseph
Administrator - IBM WebSphere MQ (WMQ) V6.0, IBM WebSphere Message Broker (WMB) V6.1 & V6.0
Solution Designer - WMQ V6.0
Solution Developer - WMB V6.1 & V6.0, WMQ V5.3 |
|
| Back to top |
|
|
| JosephGramig |
| Posted: Tue Dec 11, 2007 11:47 am Post subject: |
|
|
Grand Master
Joined: 09 Feb 2006
Posts: 1244
Location: Gold Coast of Florida, USA
|
|
| Back to top |
|
|
| bbburson |
| Posted: Tue Dec 11, 2007 1:47 pm Post subject: |
|
|
Partisan
Joined: 06 Jan 2004
Posts: 378
Location: Nowhere near a queue manager
|
Joseph,
Thanks for your thoughts, but it is not a question of differing CAs. We can and do allow for multiple CAs throughout the environment. If the certificate could not be accepted at the CA level the connection would never get as far as the SSLPEER checking.
The problem arises from the queue manager certificates not having CN or other attributes in a close enough pattern that a good match can be specified in SSLPEER. Since the queue manager has no way to present more than one certificate for itself (the one with label ibmwebspheremqqmgrname) then we are stuck with the conflicts and cannot get past them without relying on something other than SSLPEER checking for cluster membership restriction.
As for your question:
| JosephGramig wrote: |
| So, what is to prevent somebody in your organization from generating a cert request with CN="ABCCLUSTER FlyingPigs" and joining their QMGR to your cluster? |
Nothing...
I will check the link you provided in case it does indeed shed more light on the situation. |
|
| Back to top |
|
|
| JosephGramig |
| Posted: Tue Dec 11, 2007 2:09 pm Post subject: |
|
|
Grand Master
Joined: 09 Feb 2006
Posts: 1244
Location: Gold Coast of Florida, USA
|
You know, it just occurred to me that there are several public CAs put in the key store by default.
Doh!
_________________
Joseph
Administrator - IBM WebSphere MQ (WMQ) V6.0, IBM WebSphere Message Broker (WMB) V6.1 & V6.0
Solution Designer - WMQ V6.0
Solution Developer - WMB V6.1 & V6.0, WMQ V5.3 |
|
| Back to top |
|
|
|
|
