| Author |
Message
|
| wjn777 |
 Posted: Wed Dec 07, 2011 7:35 am Post subject: SSL with client auth not working |
 |
|
Newbie
Joined: 07 Dec 2011
Posts: 5
|
Hi,
I am trying to get SSL working on WebSphere MQ and the client MUST be authenticated - the server must not allow clients without certificates to connect.
I've taken these steps:
1. Generated my own CA and created a self-signed certificate for the queue manager. It is named appropriately and placed in a *.kdb keystore file. (using the runmqckm utility).
2. I've referenced the keystore on the queue manager.
3. Created a new channel, specified a new port, SSLCIPH(RC4_MD5_US) and SSLCAUTH(REQUIRED).
4. I've downloaded the supportPac containing 'amqsslchk', which states everything is fine.
5. Java JMS client, subscribing to a topic with no client certificate can connect and subcribe without a problem.
Am I missing something here? Should the java client not have had an exception during the connect? Is there anything I am missing? Is there some fallback normal TCP channel servicing the client connection?
I am stumped - no use enabling SSL debugging on the client as I've not specified key or trust stores on the client, I want it to not be able to connect.
Any help would be greatly appreciated!
Details:
Platform: WinXP SP2 running WebSphere MQ 7.0 (trail version)
Output from runmcsc:
DIS CHL(SSL2)
2 : DIS CHL(SSL2)
AMQ8414: Display Channel details.
CHANNEL(SSL2) CHLTYPE(SVRCONN)
ALTDATE(2011-12-07) ALTTIME(16.41.25)
COMPHDR(NONE) COMPMSG(NONE)
DESCR( ) HBINT(300)
KAINT(AUTO) MAXINST(999999999)
MAXINSTC(999999999) MAXMSGL(4194304)
MCAUSER( ) MONCHL(QMGR)
RCVDATA( ) RCVEXIT( )
SCYDATA( ) SCYEXIT( )
SENDDATA( ) SENDEXIT( )
SHARECNV(10) SSLCAUTH(REQUIRED)
SSLCIPH(RC4_MD5_US) SSLPEER( )
TRPTYPE(TCP)
DIS QMGR
AMQ8408: Display Queue Manager details.
QMNAME(QM_SSL) ACCTCONO(DISABLED)
ACCTINT(1800) ACCTMQI(OFF)
ACCTQ(OFF) ACTIVREC(MSG)
ALTDATE(2011-12-07) ALTTIME(13.20.4
AUTHOREV(DISABLED) CCSID(437)
CHAD(DISABLED) CHADEV(DISABLED)
CHADEXIT( ) CHLEV(DISABLED)
CLWLDATA( ) CLWLEXIT( )
CLWLLEN(100) CLWLMRUC(999999999)
CLWLUSEQ(LOCAL) CMDEV(DISABLED)
CMDLEVEL(701) COMMANDQ(SYSTEM.ADMIN.COMMAND.QUEUE
CONFIGEV(DISABLED) CRDATE(2011-12-07)
CRTIME(12.58.21) DEADQ( )
DEFXMITQ( ) DESCR( )
DISTL(YES) INHIBTEV(DISABLED)
IPADDRV(IPV4) LOCALEV(DISABLED)
LOGGEREV(DISABLED) MARKINT(5000)
MAXHANDS(256) MAXMSGL(4194304)
MAXPROPL(NOLIMIT) MAXPRTY(9)
MAXUMSGS(10000) MONACLS(QMGR)
MONCHL(OFF) MONQ(OFF)
PARENT( ) PERFMEV(DISABLED)
PLATFORM(WINDOWSNT) PSRTYCNT(5)
PSNPMSG(DISCARD) PSNPRES(NORMAL)
PSSYNCPT(IFPER) QMID(QM_SSL_2011-12-07_12.58.21)
PSMODE(ENABLED) REMOTEEV(DISABLED)
REPOS( ) REPOSNL( )
ROUTEREC(MSG) SCHINIT(QMGR)
SCMDSERV(QMGR) SSLCRLNL( )
SSLCRYP( ) SSLEV(DISABLED)
SSLFIPS(NO) SSLKEYR(C:\Install\SSL-J\myqmgr)
SSLRKEYC(0) STATACLS(QMGR)
STATCHL(OFF) STATINT(1800)
STATMQI(OFF) STATQ(OFF)
STRSTPEV(ENABLED) SYNCPT
TREELIFE(1800) TRIGINT(999999999) |
|
| Back to top |
|
 |
| mqjeff |
| Posted: Wed Dec 07, 2011 7:45 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
Sorry to ask this, but it's not clear from what you've posted.
Did you ensure that the JMS client is using the SSl2 channel to connect, and not some other unsecure channel? |
|
| Back to top |
|
|
| wjn777 |
| Posted: Wed Dec 07, 2011 8:01 pm Post subject: |
|
|
Newbie
Joined: 07 Dec 2011
Posts: 5
|
| mqjeff wrote: |
Sorry to ask this, but it's not clear from what you've posted.
Did you ensure that the JMS client is using the SSl2 channel to connect, and not some other unsecure channel? |
Hi, sorry about that, a very valid question.
Yes, I am running the WMQ on a virtual machine - I closed the hole in the firewall for the unsecure channel that was running on a different port.
This channel is listening on port 1415 - which is the only firewall port rule in place and I've confirmed that I am connecting to the correct queue manager.
As an additional test I publish a message on this queue manager to see if the unsecured client receives it - which it does. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Thu Dec 08, 2011 2:30 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
sorry to be unclear.
The JMS client must be specifying EXACTLY the name of the SSL2 channel, as well as the hostname and proper port. |
|
| Back to top |
|
|
| wjn777 |
| Posted: Thu Dec 08, 2011 7:10 am Post subject: |
|
|
Newbie
Joined: 07 Dec 2011
Posts: 5
|
| mqjeff wrote: |
sorry to be unclear.
The JMS client must be specifying EXACTLY the name of the SSL2 channel, as well as the hostname and proper port. |
I am specifying the queue manager from the client side - not the channel. Could that be the issue? When I check WMQ explorer I only see the one channel for the queue manager though?
It is using the exact name, ip address and port. I've even changed the port number on the queue manager's channel to a high range port - still connecting as though SSL is not configured properly. From the parameters I've posted from runmqsc can you see anything that is not configured correctly? |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Thu Dec 08, 2011 7:14 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9399
Location: US: west coast, almost. Otherwise, enroute.
|
You might want to take a look at supportpac MH03: WebSphere MQ SSL Configuration Checker.
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| wjn777 |
| Posted: Thu Dec 08, 2011 11:50 pm Post subject: |
|
|
Newbie
Joined: 07 Dec 2011
Posts: 5
|
| bruce2359 wrote: |
| You might want to take a look at supportpac MH03: WebSphere MQ SSL Configuration Checker. |
Hi,
I did that. In my original post:
"I've downloaded the supportPac containing 'amqsslchk', which states everything is fine. "
Really stumped with this. I've used ActiveMQ, MSMQ, etc before and SSL is not such a mission to configure. The problem in the IBM world is most of the articles were written 5 years ago and is not 100% applicable anymore. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Fri Dec 09, 2011 2:36 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
Client applications use a unique set of hostname, channel name, and port # to establish a connection to a queue manager. The name of the queue manager is useful but not necessary.
Client connections *can* use the queue manager name as a lookup field into a client channel definition table.
It sounds the most like to me that you are NOT specifying the SSL2 channel name in your code, and thus a default channel is being used - very likely SYSTEM.DEFAULT.SVRCONN. This channel will a) not have SSLCAUTH(REQUIRED), b) not show up on the queue manger in MQ Explorer unless you has to show system objects. |
|
| Back to top |
|
|
| wjn777 |
| Posted: Mon Dec 12, 2011 12:32 am Post subject: |
|
|
Newbie
Joined: 07 Dec 2011
Posts: 5
|
| mqjeff wrote: |
Client applications use a unique set of hostname, channel name, and port # to establish a connection to a queue manager. The name of the queue manager is useful but not necessary.
Client connections *can* use the queue manager name as a lookup field into a client channel definition table.
It sounds the most like to me that you are NOT specifying the SSL2 channel name in your code, and thus a default channel is being used - very likely SYSTEM.DEFAULT.SVRCONN. This channel will a) not have SSLCAUTH(REQUIRED), b) not show up on the queue manger in MQ Explorer unless you has to show system objects. |
Thank you. That is definitely a possible explanation. I will attempt to specify a channel and see if I can get it working
EDIT:
This was the problem. Client is now throwing an exception when it tries to connect, and it was trying to connect via SYSTEM.DEF.SVRCONN
Thank you again. |
|
| Back to top |
|
|
|
|
