| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Getting SSL error on using dmpmqmsg in client mode |
« View previous topic :: View next topic » |
| Author |
Message
|
| krypton |
 Posted: Sat May 25, 2019 2:11 am Post subject: Getting SSL error on using dmpmqmsg in client mode |
 |
|
Disciple
Joined: 14 Mar 2010
Posts: 186
|
I am trying to use dmpmqmsg -c on client mode, I am running this on our MQ server and connecting to another MQ server queue manager.
I tested it without SSL enabled on SVRCONN channel and it worked fine.
But after I enabled SSL on the other side SVRCONN channel, I am getting SSL_INITIALIZATION error.
I have set SSLCIPH and made SSLAUTH as OPTIONAL.
and I have added the remote QMGR certificate and root , intermediate certificate on the key.kdb file on my local MQ server and then I ran following env variable.
export MQSERVER=ABC.TO.XYZ/TCP/'22.333.4.555(1416)'
export MQSSLKEYR=/var/mqm/qmgrs/ABC/ssl/serverkey
But I am getting error.
Is there a way to verify if my certificate chains are correct, surprising thing is other applications are using same SSL certificates and able to connect to same SVRCONN channel. I am wondering what am I missing? |
|
| Back to top |
|
 |
| bruce2359 |
| Posted: Sat May 25, 2019 4:10 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
MQ errors result in ReasonCodes and/or AMQnnnn type errors being issued. What RC's/AMQnnnn errors did you receive?
What IBM-supplied documentation are your following for implementing SSL/TLS? What versions of MQ? What o/s's?
_________________
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 |
|
|
| hughson |
| Posted: Sat May 25, 2019 9:07 am Post subject: Re: Getting SSL error on using dmpmqmsg in client mode |
|
|
Padawan
Joined: 09 May 2013
Posts: 1959
Location: Bay of Plenty, New Zealand
|
| krypton wrote: |
But after I enabled SSL on the other side SVRCONN channel, I am getting SSL_INITIALIZATION error.
I have set SSLCIPH and made SSLAUTH as OPTIONAL.
and I have added the remote QMGR certificate and root , intermediate certificate on the key.kdb file on my local MQ server and then I ran following env variable.
export MQSERVER=ABC.TO.XYZ/TCP/'22.333.4.555(1416)'
export MQSSLKEYR=/var/mqm/qmgrs/ABC/ssl/serverkey |
You say that your have set SSLCIPH, but you are using MQSERVER which does not have the capability to set SSLCIPH. You need to use a CCDT for your client channel, and unset MQSERVER.
Cheers,
Morag
_________________
Morag Hughson @MoragHughson
IBM MQ Technical Education Specialist
Get your IBM MQ training here!
MQGem Software |
|
| Back to top |
|
|
| exerk |
| Posted: Sat May 25, 2019 9:09 am Post subject: Re: Getting SSL error on using dmpmqmsg in client mode |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| krypton wrote: |
| I am trying to use dmpmqmsg -c on client mode...I tested it without SSL enabled on SVRCONN channel and it worked fine... |
Sensible. It proves initial connectivity.
| krypton wrote: |
| ...But after I enabled SSL on the other side SVRCONN channel, I am getting SSL_INITIALIZATION error... |
It would help greatly if you posted the exact error reported, i.e. the MQRC code.
| krypton wrote: |
| ...I have added the remote QMGR certificate and root , intermediate certificate on the key.kdb file on my local MQ server... |
My assumption is that by "...my local MQ server..." you mean where you run the MQ Client from, and that you do not mean you copied out the queue manager's 'personal' certificate and added it to the MQ Client key store instead of using one specific to the user you're running your MQ Client under, and did not set the appropriate environment variable for the MQ Client to use a non-default certificate*? I ask as you state:
| krypton wrote: |
...and then I ran following env variable.
export MQSERVER=ABC.TO.XYZ/TCP/'22.333.4.555(1416)'
export MQSSLKEYR=/var/mqm/qmgrs/ABC/ssl/serverkey |
| krypton wrote: |
| ...But I am getting error... |
No surprises there as the Knowledge Centre clearly states "...You cannot use MQSERVER to define a TLS channel or a channel with channel exits...", so you need a CCDT, or a run-time build of the channel definition.
| krypton wrote: |
| ...Is there a way to verify if my certificate chains are correct...? |
Yes. Run the appropriate GSKit command.
| krypton wrote: |
| ...surprising thing is other applications are using same SSL certificates and able to connect to same SVRCONN channel... |
What same certificates? You have not provided sufficient detail for us to know what those certificates are, so see "...But I am getting error..." above.
| krypton wrote: |
| ...I am wondering what am I missing? |
Again, see "...But I am getting error..." above.
* Caveat: Depending on your MQ version(s), which you have omitted to mention
_________________
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 |
|
|
| krypton |
| Posted: Sun May 26, 2019 10:02 am Post subject: |
|
|
Disciple
Joined: 14 Mar 2010
Posts: 186
|
I am sorry if I was not clear.
What I am trying to do is we have 2 servers and both of them we have MQ installed and QMGR created.
Following are the configuration on Server 1,
QMGR Name - XYZQM1, IP address - 22.333.4.555(1416), SVRconn channel-ABC.TO.XYZ
Server 2 is the one on which I am trying to run "dmpmqmsg -c" command to connect to server1. Server 2 also has a qmgr created with name - ABC
I took Server1 QMGR XYZQM1 certificate + Intermediate certifcate+ ROOT ca & add all these on SERVER 2 QMGR ABC KEY DB file.
and then I set the following environment variables on SERVER 2
export MQSERVER=ABC.TO.XYZ/TCP/'22.333.4.555(1416)'
export MQSSLKEYR=/var/mqm/qmgrs/ABC/ssl/serverkey
I am logged as "mqm' user on server 2 while running the command "dmpmqmsg -c"
and I am getting following error
| Quote: |
[mqm@hostmq~]$ /opt/mqm/bin/dmpmqmsg -c -iAPHA.BETA.QUEUE.REP -ds
5724-H72 (C) Copyright IBM Corp. 1994, 2018.
WebSphere MQ Queue Load/Unload Utility
MQCONNX on object '' returned 2393 SSL initialisation error. |
|
|
| Back to top |
|
|
| exerk |
| Posted: Sun May 26, 2019 10:29 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
As Morag (hughson) and I pointed out - you cannot initiate a TLS-secured connection if you have set the MQSERVER variable, so regarding your current set-up in regard to key stores and certificates, IT WON'T WORK!
You do NOT need to copy the certificate from QM1 to QM2, and to do so is bad practice as you will then have one certificate, which, if it is revoked or expires, neither of your queue managers will work. Also, you will have to fudge one of the queue managers' CERTLABL attribute (unless you changed the label name during the import) for it to be used.
Create a key store for user 'mqm', request a certificate for user 'mqm', set the MQSSLKEYR variable to use that key store, create a CCDT and set the appropriate environment variables to address it, or better still, create an mqclient.ini file that does the same thing - that way you won't have to worry about setting the variables every time.
You stated that other MQ Client applications are successfully using TLS to connect to the queue manager - compare and contrast your attempt at setting up a TLS connection with one of those MQ Client applications, which should provide you with a template of how to do it successfully.
Best Practice: Queue manager key stores should contain only the personal certificate(s) for the queue manager; Client key stores should contain only the certificates for the clients that invoke SVRCONN channels.
_________________
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 |
|
|
| krypton |
| Posted: Mon May 27, 2019 12:16 am Post subject: |
|
|
Disciple
Joined: 14 Mar 2010
Posts: 186
|
| exerk wrote: |
You do NOT need to copy the certificate from QM1 to QM2, and to do so is bad practice as you will then have one certificate, which, if it is revoked or expires, neither of your queue managers will work. Also, you will have to fudge one of the queue managers' CERTLABL attribute (unless you changed the label name during the import) for it to be used.
. |
Hi Exerk, thank you for reply. But I am still not clear with the part where copying QMGR - XYZQM1 certificates to QMGR-ABC kdb.
how could that be a problem, these are additional certificates I am adding, the QMGR ABC already has its own ssl cert and that is also defined in CERTLABL parameter of QMGR ABC.
How come expiring of QMGR-XYZQM1 cert would cause problem for ABC qmgr? This part is not understandable for me. |
|
| Back to top |
|
|
| krypton |
| Posted: Mon May 27, 2019 3:22 am Post subject: |
|
|
Disciple
Joined: 14 Mar 2010
Posts: 186
|
| exerk wrote: |
Create a key store for user 'mqm', request a certificate for user 'mqm', set the MQSSLKEYR variable to use that key store, create a CCDT and set the appropriate environment variables to address it, or better still, create an mqclient.ini file that does the same thing - that way you won't have to worry about setting the variables every time.
You stated that other MQ Client applications are successfully using TLS to connect to the queue manager - compare and contrast your attempt at setting up a TLS connection with one of those MQ Client applications, which should provide you with a template of how to do it successfully.
. |
Yes, we have other application using TLS sucessfully connected but there also in the keydb , we have added QMGR XYZQM1 cert + corresponding intermediate and root cert.
but you are mentioning that we don't need to add QMGR cert at all in the client key repositorY? |
|
| Back to top |
|
|
| exerk |
| Posted: Mon May 27, 2019 3:56 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| krypton wrote: |
Hi Exerk, thank you for reply. But I am still not clear with the part where copying QMGR - XYZQM1 certificates to QMGR-ABC kdb. how could that be a problem, these are additional certificates I am adding, the QMGR ABC already has its own ssl cert and that is also defined in CERTLABL parameter of QMGR ABC.
How come expiring of QMGR-XYZQM1 cert would cause problem for ABC qmgr? This part is not understandable for me. |
Because in your original post you stated "...I have added the remote QMGR certificate and root , intermediate certificate on the key.kdb file on my local MQ server...", which implied that you were using the same certificate for both queue managers. You did not clearly state that each queue manager has its own 'personal' certificate.
In brief, what you need is:
Queue Manager ABC key store -
1. Queue manager personal certificate;
2. Root and any Intermediate certificates from the CA that signed the above;
3. Any other Root and Intermediate certificates from CAs that sign other certificates that may be used by other connections, e.g. external parties.
Queue Manager XYZ key store -
4. Queue manager personal certificate;
5. Root and any Intermediate certificates from the CA that signed the above.
6. Any other Root and Intermediate certificates from CAs that sign other certificates that may be used by other connections, e.g. external parties.
You do NOT need to copy out the personal certificate from each queue manager and add it to any other queue managers' key store, or MQ Client key store.
Ideally you should have separate key stores for the MQ Client applications and NOT store them in a queue managers' key store - what would you do if the MQ Client application needs to move to another server?
_________________
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 |
|
|
| krypton |
| Posted: Wed May 29, 2019 4:11 am Post subject: |
|
|
Disciple
Joined: 14 Mar 2010
Posts: 186
|
| exerk wrote: |
You do NOT need to copy out the personal certificate from each queue manager and add it to any other queue managers' key store, or MQ Client key store.
|
Hi Exerk, it seems then that every time we have been doing it wrong for the past couple of years, every time a new CLIENT application on-board or another instance of them getting added to a new application server, we always provide them with QMGR personal certificate + intermediate + Root to connect to QMGR via SVRCONN.
As you are saying there is no need of it, I will try removing QMGR related certs from application keystore and test it and see how it works. |
|
| Back to top |
|
|
| exerk |
| Posted: Wed May 29, 2019 4:47 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| krypton wrote: |
| Hi Exerk, it seems then that every time we have been doing it wrong for the past couple of years, every time a new CLIENT application on-board or another instance of them getting added to a new application server, we always provide them with QMGR personal certificate + intermediate + Root to connect to QMGR via SVRCONN... |
Think through the logic - Certificates are flowed down a channel and verified against the CA certificates held in each key store; a 'personal' certificate is for the use of the entity it applies to, in this case your queue manager, so what utility will it have for other entities, unless you force them to use that certificate?
| krypton wrote: |
| As you are saying there is no need of it, I will try removing QMGR related certs from application keystore and test it and see how it works. |
Make sure you take a back-up of each key store, just in case.
_________________
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 |
|
|
| Vitor |
| Posted: Wed May 29, 2019 4:54 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| krypton wrote: |
| exerk wrote: |
You do NOT need to copy out the personal certificate from each queue manager and add it to any other queue managers' key store, or MQ Client key store.
|
Hi Exerk, it seems then that every time we have been doing it wrong for the past couple of years, every time a new CLIENT application on-board or another instance of them getting added to a new application server, we always provide them with QMGR personal certificate + intermediate + Root to connect to QMGR via SVRCONN.
As you are saying there is no need of it, I will try removing QMGR related certs from application keystore and test it and see how it works. |
Think about it from a more abstract point of view; the point of having a CA (and associated intermediates) is that you can trust a certificate trusted by that CA. Imagine if every browser client had to download and add Amazon's personal certificate, or your bank's.
For the record, and to support my worthy associate, this site's PKI is set up exactly how he describes. We have an internally managed CA (to save money!) that signs all our certs, and all the WAS / MQ / you name it clients have that CA (and intermediates) added to their trust store at build time. Thus all the internal only servers trust each other, can encrypt connections and enjoy themselves.
(Subject to the odds, ends, weirdos and other exceptions)
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| exerk |
| Posted: Wed May 29, 2019 9:03 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| Vitor wrote: |
| ...(Subject to the odds, ends, weirdos and other exceptions) |
That's no way to speak of yourself 
_________________
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 |
|
|
| Vitor |
| Posted: Wed May 29, 2019 9:14 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| exerk wrote: |
| Vitor wrote: |
| ...(Subject to the odds, ends, weirdos and other exceptions) |
That's no way to speak of yourself |
I'm routinely called worse.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| 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
|
|
|
|
