| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| MCAUSER not in effect with client connection? |
« View previous topic :: View next topic » |
| Author |
Message
|
| rickard75 |
 Posted: Fri Sep 21, 2012 7:27 am Post subject: MCAUSER not in effect with client connection? |
 |
|
Newbie
Joined: 21 Sep 2012
Posts: 3
|
Hi -- I am having an issue configuring SSL connection using the base MQ client -- the issue seems to be that even though I have specified an MCAUSER for the svrconn channel, that the userid is not 'effective' when the server connection channel starts up. This causes the client to try to authenticate under the 'mqm' id, which then causes the client to fail to present a valid key to key manager.
I have successfully setup other java-based applications previously, and have had no trouble specifying alternate MCAUSERS and the clients using certificates related to those ids, but this is the first time I am using CCDT tables and the native MQ client (v7.0.1.2 on AIX).
Here is my channel configuration (svrconn and clntconn):
| Code: |
AMQ8414: Display Channel details.
CHANNEL(DS.SSL.CLIENTS) CHLTYPE(SVRCONN)
ALTDATE(2012-09-21) ALTTIME(08.47.39)
COMPHDR(NONE) COMPMSG(NONE)
DESCR( ) HBINT(300)
KAINT(AUTO) MAXINST(999999999)
MAXINSTC(999999999) MAXMSGL(104857600)
MCAUSER(srmds) MONCHL(QMGR)
RCVDATA( ) RCVEXIT( )
SCYDATA( ) SCYEXIT( )
SENDDATA( ) SENDEXIT( )
SHARECNV(10) SSLCAUTH(REQUIRED)
SSLCIPH(RC4_SHA_US)
SSLPEER(CN=XXXXXXX,O=XXX,OU=XXXXXX,L=XXX,ST=XX,C=XX)
TRPTYPE(TCP)
AMQ8414: Display Channel details.
CHANNEL(DS.SSL.CLIENTS) CHLTYPE(CLNTCONN)
AFFINITY(PREFERRED) ALTDATE(2012-09-21)
ALTTIME(09.12.09) CLNTWGHT(0)
COMPHDR(NONE) COMPMSG(NONE)
CONNAME(xxx.xxx.xxx.xxx(8200))
DESCR( ) HBINT(300)
KAINT(AUTO) LOCLADDR( )
MAXMSGL(104857600) MODENAME( )
PASSWORD( ) QMNAME(XXXXXX)
RCVDATA( ) RCVEXIT( )
SCYDATA( ) SCYEXIT( )
SENDDATA( ) SENDEXIT( )
SHARECNV(10) SSLCIPH(RC4_SHA_US)
SSLPEER(CN=XXXXXXX,O=XXX,OU=XXXXXXX,L=XXX,ST=XX,C=XX)
TPNAME( ) TRPTYPE(TCP)
USERID(srmds) |
I have configured keystores, added certificates, etc. similar to other applications that have worked fine in the past. When I attempt connection from 'amqsputc' command, I get an error in the logs, but the channel logs indicate that the channel is starting under 'mqm' and not 'srmds' as defined in the channel definition.
amqsputc output:
| Code: |
/home/xxxxxxx/mq_client> amqsputc q1 XXXXXX
Sample AMQSPUT0 start
MQCONN ended with reason code 2393 |
AMQERR01.LOG output for QM:
| Code: |
09/21/12 10:30:59 - Process(811212.5) User(mqm) Program(amqrmppa)
Host(xxxxxxxx)
AMQ9637: Channel is lacking a certificate.
EXPLANATION:
The channel is lacking a certificate to use for the SSL handshake. The channel
name is 'DS.SSL.CLIENTS' (if '????' it is unknown at this stage in the SSL
processing). The channel did not start. |
So of course, because I don't have a 'ibmwebspheremqmqm' certificate in my keystore the client does not have one to produce for that id and fails. Is this behaviour different in the native client than we would see in the java-based client api/WebSphere? Will the native client only retrieve the certificate for the userid that the process is running under on the local system?
As a further test, I did go ahead and create an 'ibmwebspheremqm' certificate and try amqsputc using the mqm id on the client machine and it worked fine. But I don't want clients using 'mqm' for obvious reasons. Any pointers or ideas would be fantastic! Let me know if you need more information.
Thanks! |
|
| Back to top |
|
 |
| rickard75 |
| Posted: Fri Sep 21, 2012 10:37 am Post subject: Update to original |
|
|
Newbie
Joined: 21 Sep 2012
Posts: 3
|
One more update: I created the userid I wanted to use (same as specified in MCAUSER -- srmds) on the client machine. Finds the right client cert, works fine, so I know my keys are good. So basically just the one question:
Does the native MQ client ignore MCAUSER in favor of the local user when it comes to which cert to retrieve from the keystore to be presented to the QM for client authentication? Because it sure seems like it must be, I just can't find any definitive answer to that question one way or the other and I have google every combination I can think of and gone through the infocenter till my eyes are bleeding.
Thanks! |
|
| Back to top |
|
|
| exerk |
| Posted: Fri Sep 21, 2012 12:39 pm Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
All the MCAUSER is for is to specify which objects can be accessed, and what can be done with those objects. When the client invokes the channel, the queue manager is expecting the client to flow a certificate, which the queue manager will check. The only certificate the queue manager will use is it's own 'personal' certificate, not that of any user specified in a channel.
From what you have posted I think all you have proved is that the application is not flowing a certificate. The MCAUSER is a 'proxy' for whomever connects, the SSL certificate is merely a way of securing who can connect, i.e. someone with a valid certificate and matching the SSLPEER.
_________________
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 |
|
|
| rickard75 |
| Posted: Fri Sep 21, 2012 1:18 pm Post subject: |
|
|
Newbie
Joined: 21 Sep 2012
Posts: 3
|
Didn't really think I had 'proved' anything. I understand what you are saying, but this is completely the opposite behavior I had ever observed before, having only dealt with JMS/Java based connections over the last few years.
I have several other JMS/Java based clients connecting to the same queue manager under similarly configured channels (each mapped to its own mcauser specific to the application's needs). In their case, the userid the client process is 'running' under is irrelevant, and the only 'ibmwebspheremq<user>' certificate I have in the client keystore (jks) is the one associated with MCAUSER. This works fine from whatever userid is actually executing the process -- even if it is not MCAUSER (which it isn't). It seems as if the server actually communicates the MCAUSER back to the client in the case of the java apps and tells it 'I need the cert associated with 'mcauser''.
The whole point of all this in the first place, is that I don't want to care what userid someone else runs the client under (since it will be a completely separate team talking to my application). I want to provide them with a dedicated channel and a keyset and let them go at it and leave the implementation on their side up to them. So I suppose I had assumed that the native clients would work in the same way as the java-based ones which had previously allowed me to do this. This really does not seem to be the case with the c-based client. Thanks for your time. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Fri Sep 21, 2012 4:22 pm Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
The thing to keep in mind is that the MCAUSER only ever takes effect is on the server side, not ever on the client side.
Your java solutions work because the JVM is not tightly coupled to the OS, which the C runtime can take full advantage of. So, to be a bit more clear - the JVM is *less* secure because the *application code* can essentially choose what identity it is, rather than forcing that decision to be made by the OS. So when it 'works' with the label matching the mcauser from java, it's really very likely because the label isn't used at all.
From the point of view of the queue manager, the important bits for security are who has signed the client certificate and what the distinguished name of the certificate is - the label of the certificate in the keystore is completely irrelevant.
So you can create one client certificate, that has a known signer and a known distinguished name - and use SSLPEER to enforce the DN and MCAUSER to replace whatever id is presented.
Then the app teams can install the certificate into a keystore under whatever label is appropriate for the user that is running the application.
Alternatively you can just tell them to create an OS id of the name that matches the label you've stuck the key into the keystore with. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Fri Sep 21, 2012 9:37 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
remember however that if you use somebody else's cert / keystore on the client machine, said keystore needs to be accessible to the process trying to connect to MQ... Often times those files are locked with the windows SID for the user and not accessible to other user, even if they are visible...
Best practice says give each client it's own cert and check on the channel on the OU part of the DN. This way you can have different clients grouped with the same access.
Have fun 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
|
|
|
| |
|
Page 1 of 1 |
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
|
|
