ASG
IBM
Zystems
Cressida
Icon
Netflexity
 
  MQSeries.net
Search  Search       Tech Exchange      Education      Certifications      Library      Info Center      SupportPacs      LinkedIn  Search  Search                                                                   FAQ  FAQ   Usergroups  Usergroups
 
Register  ::  Log in Log in to check your private messages
 
RSS Feed - WebSphere MQ Support RSS Feed - Message Broker Support

MQSeries.net Forum Index » General IBM MQ Support » Getting SSL error on using dmpmqmsg in client mode

Post new topic  Reply to topic
 Getting SSL error on using dmpmqmsg in client mode « View previous topic :: View next topic » 
Author Message
krypton
PostPosted: Sat May 25, 2019 2:11 am    Post subject: Getting SSL error on using dmpmqmsg in client mode Reply with quote

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
View user's profile Send private message
bruce2359
PostPosted: Sat May 25, 2019 4:10 am    Post subject: Reply with quote

Poobah

Joined: 05 Jan 2008
Posts: 9394
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
View user's profile Send private message
hughson
PostPosted: Sat May 25, 2019 9:07 am    Post subject: Re: Getting SSL error on using dmpmqmsg in client mode Reply with quote

Padawan

Joined: 09 May 2013
Posts: 1914
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
View user's profile Send private message Visit poster's website
exerk
PostPosted: Sat May 25, 2019 9:09 am    Post subject: Re: Getting SSL error on using dmpmqmsg in client mode Reply with quote

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
View user's profile Send private message
krypton
PostPosted: Sun May 26, 2019 10:02 am    Post subject: Reply with quote

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
View user's profile Send private message
exerk
PostPosted: Sun May 26, 2019 10:29 am    Post subject: Reply with quote

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
View user's profile Send private message
krypton
PostPosted: Mon May 27, 2019 12:16 am    Post subject: Reply with quote

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
View user's profile Send private message
krypton
PostPosted: Mon May 27, 2019 3:22 am    Post subject: Reply with quote

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
View user's profile Send private message
exerk
PostPosted: Mon May 27, 2019 3:56 am    Post subject: Reply with quote

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
View user's profile Send private message
krypton
PostPosted: Wed May 29, 2019 4:11 am    Post subject: Reply with quote

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
View user's profile Send private message
exerk
PostPosted: Wed May 29, 2019 4:47 am    Post subject: Reply with quote

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
View user's profile Send private message
Vitor
PostPosted: Wed May 29, 2019 4:54 am    Post subject: Reply with quote

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
View user's profile Send private message
exerk
PostPosted: Wed May 29, 2019 9:03 am    Post subject: Reply with quote

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
View user's profile Send private message
Vitor
PostPosted: Wed May 29, 2019 9:14 am    Post subject: Reply with quote

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
View user's profile Send private message
Display posts from previous:   
Post new topic  Reply to topic Page 1 of 1

MQSeries.net Forum Index » General IBM MQ Support » Getting SSL error on using dmpmqmsg in client mode
Jump to:  



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
Protected by Anti-Spam ACP
 
 


Theme by Dustin Baccetti
Powered by phpBB © 2001, 2002 phpBB Group

Copyright © MQSeries.net. All rights reserved.