| Author |
Message
|
| Ross |
 Posted: Tue Feb 11, 2014 5:39 pm Post subject: MO72 with SSL |
 |
|
Centurion
Joined: 15 Jun 2005
Posts: 127
Location: Ireland
|
Hi.
Does anyone use MO72 over an MQ Client Channel with SSL.
Without SSL, it is doing everything we need. We are adding the connection information into the statement.
mqsc –m QM1 –l –c CHL.SVRCONN –h myhostname(1414)
I would like to enable SSL on the channel, so the connection information would stay the same, but I would need to include keystore information.
Does anyone know how best to achieve this?
Not sure if environment variables can be used.
I'd prefer not to use a CCDT if possible.
Thanks,
Ross. |
|
| Back to top |
|
 |
| JosephGramig |
| Posted: Wed Feb 12, 2014 7:53 am Post subject: |
|
|
Grand Master
Joined: 09 Feb 2006
Posts: 1244
Location: Gold Coast of Florida, USA
|
First, you must tell it where the CMS key store can be found:
SET MQSSLKEYR=C:\KeepMeSafe\MyKeyStore
Where you built a CMS key store called MyKeyStore.kdb in C:\KeepMeSafe directory where you also put a stash file. The label of your key must be very specific (ibmwebspheremq concatenated with the ID (all in lower case) you are using with this process).
I always use a CCDT to specify the cypherspec and don't know if there is an environment variable. My commands look something like:
mqsc -l -m MyQmgr -t C:\CCDTs\MyQmgrCCDT.TAB
You can use this very same tool to build that CCDT by:
mqsc -n -t C:\CCDTs\MyQmgrCCDT.TAB
DEF CHL('BLA') CHLTYPE(CLNTCONN) and so on with your values
Seems simple enough to me... You know, there is a PDF that comes with this tool... |
|
| Back to top |
|
|
| Ross |
| Posted: Wed Feb 12, 2014 8:38 am Post subject: |
|
|
Centurion
Joined: 15 Jun 2005
Posts: 127
Location: Ireland
|
Thanks Joseph.
Had got close to the same conclusion today.
Using mqclient.ini, rather than MQSSLKEYR, but might use your option.
Had hoped to avoid the CCDT, but is seems necessary for the Cypherspec value, so have created that, including QMNAME value.
I can't see anything in the MO72 guide about SSL. Unless I have an old version.
I had been using a jks for the MQ Explorer connections, so had to convert this, using gsk7cmd. (gsk8capicmd doesn't support jks).
Just working through a couple of issues now, and hope to have a successful test soon!
Thanks for the information.
Ross. |
|
| Back to top |
|
|
| PaulClarke |
| Posted: Wed Feb 12, 2014 9:07 am Post subject: |
|
|
Grand Master
Joined: 17 Nov 2005
Posts: 1002
Location: New Zealand
|
MO72 uses can either connect as a local connection or as an MQ Client. Like all applications, when connecting as an MQ Client it therefore inherits all the capabilities of an MQ Client. SSL is, of course, one of those. When I wrote the MO72 manual it didn't seem worth reproducing all the information in the MQ Client manual which is why it doesn't mention all the MQ Client features. After all, as new versions of MQ are released it would only go out of date.
Cheers,
Paul.
_________________
Paul Clarke
MQGem Software
www.mqgem.com |
|
| Back to top |
|
|
| Ross |
| Posted: Wed Feb 12, 2014 9:19 am Post subject: |
|
|
Centurion
Joined: 15 Jun 2005
Posts: 127
Location: Ireland
|
Thanks Paul.
That makes sense.
I hadn't realised it.
Hopefully when I sort an SSL cert issue, I'll get a test completed. |
|
| Back to top |
|
|
| JosephGramig |
| Posted: Wed Feb 12, 2014 11:27 am Post subject: |
|
|
Grand Master
Joined: 09 Feb 2006
Posts: 1244
Location: Gold Coast of Florida, USA
|
| Ross wrote: |
| ... (gsk8capicmd doesn't support jks)... |
This would indicate you are using GS Kit 8 and the command is runmqckm on UNIX instead of gsk7cmd and does support JKS. Should be available with your default instance or set the MQ instance. I always start with a CMS key store and convert to JKS once I've got what I want. Oddly enough when using JKS, the label does not matter for your key. I only have one key in my key store at a time, so it either takes the first or default one.
For CAs, it will search until it finds or runs out of certs in the key store.
SSL basics:
- must have CA that signs your key
- your key
- CA that signed thing you are trying to talk to (other Qmgr)
- If this is two way, other end must have CA that signed you in their key store
That's about the size of it. |
|
| Back to top |
|
|
| Ross |
| Posted: Wed Feb 12, 2014 1:56 pm Post subject: |
|
|
Centurion
Joined: 15 Jun 2005
Posts: 127
Location: Ireland
|
Thanks for the information Joseph.
I had started with jks, as this was originally intended for MQ Explorer. Now the scope is expanding.
It makes sense to start with kdb.
Obviously we have a kdb on the server side.
Thanks. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Wed Feb 12, 2014 3:07 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
@Joseph
I had the same problem that mqsc did not build a ccdt that 7.5 recognized.
My work around was to create the env variables to point the ccdt to a known place, use runmqsc against that env and a qmgr (7.5) And thus my table got built...
A little bit annoying but manageable. 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| JosephGramig |
| Posted: Thu Feb 13, 2014 5:53 am Post subject: |
|
|
Grand Master
Joined: 09 Feb 2006
Posts: 1244
Location: Gold Coast of Florida, USA
|
@fjb_saper,
I had the same problem but only with the mqsc-75 version, so I used an old version. BTW: The AIX mqsc75 is built for AIX 7.1 and does not work with lower levels. Truth be told, building a CCDT is only supported through runmqsc or PCF. MO72 is "as is" CAT2. |
|
| Back to top |
|
|
| JosephGramig |
| Posted: Thu Feb 13, 2014 6:07 am Post subject: |
|
|
Grand Master
Joined: 09 Feb 2006
Posts: 1244
Location: Gold Coast of Florida, USA
|
If you think about it, if you add MS0S: WebSphere MQ Explorer MQSC Editor Plug-In, you will get the scripting functionality to make a set of changes at once to one or more Qmgrs.
If you add MS0P: WebSphere MQ Explorer – Extended Management Plug-ins, Then you will get many useful features:
- SaveQmgr
- Ability to unload (save contents) of a queue
- Move msgs from one queue to another
- Ability to delete selected browsed msgs
- lots more...
I would like to have other features of IH03: rfhutilc added, but hey that is just me. Maybe also add DLQ processing features... |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Thu Feb 13, 2014 6:14 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| JosephGramig wrote: |
@fjb_saper,
I had the same problem but only with the mqsc-75 version, so I used an old version. BTW: The AIX mqsc75 is built for AIX 7.1 and does not work with lower levels. Truth be told, building a CCDT is only supported through runmqsc or PCF. MO72 is "as is" CAT2. |
Sure but I could not use the CCDT created under 7.0 (mqsc pre-upgrade) with a 7.5 qmgr.
So I had to create it at 7.5 level..., ( which of course does not work at the 7.0 level of the qmgrs ), but did not want to change the default 7.5 CCDT.... So I set the env vars for where I wanted my ccdt and ran the commands using runmqsc. This did the trick for me...
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| JosephGramig |
| Posted: Thu Feb 13, 2014 7:04 am Post subject: |
|
|
Grand Master
Joined: 09 Feb 2006
Posts: 1244
Location: Gold Coast of Florida, USA
|
| fjb_saper wrote: |
...
Sure but I could not use the CCDT created under 7.0 (mqsc pre-upgrade) with a 7.5 qmgr... |
Really... My old CCDTs worked with MQ 7.5.0.2 Client from the server media on both Windows 7 and AIX (didn't try others).
Back to what you did on some command prompt:
SET MQCHLLIB=C:\TEMP\JUNKQMGR
SET MQCHLTAB=MyCCDT.TAB
runmqsc JUNKQMGR
DEF CHL...
END
What that does is build the channel object in that JUNKQMGR but direct the CCDT entries to the file you specifed. It creates a vaild CCDT but leaves objects in the JUNKQMGR that don't and won't even after a Qmgr restart, match what is in the AMQCLCHL.TAB that goes with the JUNKQMGR. What's more is the runmqsc is displaying what is in the Qmgr and not what is in the CCDT. Too bad runmqsc does not have a -n switch to let you work with CCDTs only and the one you are pointing to independent of any Qmgr. I guess we would need switches to also tell it what level of CCDT to build. |
|
| Back to top |
|
|
| Ross |
| Posted: Wed Feb 19, 2014 4:46 am Post subject: |
|
|
Centurion
Joined: 15 Jun 2005
Posts: 127
Location: Ireland
|
Does anyone ever get an MQRC 2011 when using MO72?
I am getting no valid hits in google, this site, or manuals (so far).
I am running the command as follows:
mqsc -m QM1 -l -c TEST.SVRCONN -h aix1(1414)
But getting the following error.
Error opening queue 'QM1/SYSTEM.DEFAULT.MODEL.QUEUE' RC(2011) Dynamic queue name error.
I'm assuming I have a local issue, as otherwise I'd expect an easier search!
I've tried with -r and that same model queue, or creating a new one.
I've tried with and without a CCDT. And with no SSL.
This test statement above is no CCDT, no SSL.
I've also tried a different qmgr.
The actual Reason Code doesn't really apply here, as model/reply queue is entered by the product, and is specified correctly.
Nothing in AMQERR01.LOG or Event Queues.
Any hints appreciated.
Thanks,
Ross. |
|
| Back to top |
|
|
| PaulClarke |
| Posted: Wed Feb 19, 2014 5:06 am Post subject: |
|
|
Grand Master
Joined: 17 Nov 2005
Posts: 1002
Location: New Zealand
|
As far as I cam remember by default MO72 will use a model queue for it's reply. It uses the prefix MQMON.<USERNAME>.*
I could imagine getting an error like this if you have a strange userid.....what is it ?
I don't really understand you comment....
| Quote: |
| The actual Reason Code doesn't really apply here, as model/reply queue is entered by the product, and is specified correctly. |
What do you mean by this ? Read Codes are your best way of determining what went wrong.
Cheers,
Paul.
_________________
Paul Clarke
MQGem Software
www.mqgem.com |
|
| Back to top |
|
|
| Ross |
| Posted: Wed Feb 19, 2014 6:28 am Post subject: |
|
|
Centurion
Joined: 15 Jun 2005
Posts: 127
Location: Ireland
|
Thank you very much Paul.
I was taking the error to be an issue with the model queue name, as it mentioned this model queue by name. I misread it.
Thanks for clarifying that the issue was with the dynamic queue coming back.
Yes, the user name is a ridiculous userID! So that's the issue.
I had only specified the -r option. I used -R and it sorted my problem.
I'm now connecting correctly.
Thanks for your help. I appreciate it.
Apologies for not taking the RC seriously enough!
Thanks,
Ross. |
|
| Back to top |
|
|
|
|
