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 IndexMainframe, CICS, TXSeriesz/OS channel SSLCERTU

Post new topicReply to topic
z/OS channel SSLCERTU View previous topic :: View next topic
Author Message
fswarbrick
PostPosted: Wed Jul 08, 2020 8:49 am Post subject: z/OS channel SSLCERTU Reply with quote

Apprentice

Joined: 07 Jul 2014
Posts: 38

One of our peers changed some things with their certs, and even though we (supposedly) did what they requested on our side, we're now getting the following:

CSQX500I :MQD1 CSQXRCTL Channel MQD1.2CXC.QM04 started
CSQX632I :MQD1 CSQXRCTL SSL certificate has no associated user ID,
remote channel MQD1.2CXC.QM04
connection 199.47.138.39
- channel initiator user ID used

Doing some googling I found the following:

Cause

MQ cannot find a user id from the certificate. The channel will run under the CHINIT user id (this may be a security exposure).


Resolution

There are two solutions:

1) You should install the peer certificates. Extract the peer certificates and install them in the RACF database. The label must match z/OS requirements (that is, ibmWebSphereMQ<qmgr>, not ibmwebspheremq<qmgr>). The certificate must be in the queue managers key ring.

OR

2) Create a RACF map. This JCL maps a certificate to a user id:

RACDCERT ID(EMIR) DELMAP (LABEL(MQMAP))
RACDCERT ID(EMIR) MAP +
IDNFILTER(CN=MQCA.O=IBM.C=GB) WITHLABEL(MQMAP) TRUST
SETROPTS RACLIST(DIGTNMAP) REFRESH
RACDCERT ID(EMIR) LISTMAP (LABEL(MQMAP))

This seems reasonable. (Haven't done it yet.)

My "issue" is that up to this point we explicitly had the peer certficate mapped to the CHIN user anyway. Based on the above it sounds like this is perhaps not best practice. What is best practice for the userID that should own the certificate?
Back to top
View user's profile Send private message
hughson
PostPosted: Thu Jul 09, 2020 2:49 am Post subject: Reply with quote

Padawan

Joined: 09 May 2013
Posts: 1512
Location: Bay of Plenty, New Zealand

Bear in mind that this is the "Channel User ID" not the "MCAUSER".

Authority on MVS can have two user IDs checked.

Make sure that you understand whether you are using two user ID checking, check RESLEVEL and channel PUTAUT attribute.

I'll write more in an answer later if you need it, but late here, so just wanted to add some initial pointers for you.

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
fswarbrick
PostPosted: Thu Jul 09, 2020 10:27 am Post subject: Reply with quote

Apprentice

Joined: 07 Jul 2014
Posts: 38

hughson wrote:
Bear in mind that this is the "Channel User ID" not the "MCAUSER".

Authority on MVS can have two user IDs checked.

Make sure that you understand whether you are using two user ID checking, check RESLEVEL and channel PUTAUT attribute.

I'll write more in an answer later if you need it, but late here, so just wanted to add some initial pointers for you.

Cheers,
Morag

I'm basically just wondering if its appropriate for the channel's "peer" certificate to be owned by the channel initiator user ID, or if it should be owned by some other user ID. And if the latter, what rights should that user have?
Back to top
View user's profile Send private message
hughson
PostPosted: Thu Jul 09, 2020 5:50 pm Post subject: Reply with quote

Padawan

Joined: 09 May 2013
Posts: 1512
Location: Bay of Plenty, New Zealand

fswarbrick wrote:
hughson wrote:
Bear in mind that this is the "Channel User ID" not the "MCAUSER".

Authority on MVS can have two user IDs checked.

Make sure that you understand whether you are using two user ID checking, check RESLEVEL and channel PUTAUT attribute.

I'll write more in an answer later if you need it, but late here, so just wanted to add some initial pointers for you.

Cheers,
Morag

I'm basically just wondering if its appropriate for the channel's "peer" certificate to be owned by the channel initiator user ID, or if it should be owned by some other user ID. And if the latter, what rights should that user have?

Do you wish to use the this user for your authority checking? If not, then it doesn't matter who it's owned by.
_________________
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
fswarbrick
PostPosted: Thu Jul 09, 2020 7:52 pm Post subject: Reply with quote

Apprentice

Joined: 07 Jul 2014
Posts: 38

hughson wrote:
fswarbrick wrote:
hughson wrote:
Bear in mind that this is the "Channel User ID" not the "MCAUSER".

Authority on MVS can have two user IDs checked.

Make sure that you understand whether you are using two user ID checking, check RESLEVEL and channel PUTAUT attribute.

I'll write more in an answer later if you need it, but late here, so just wanted to add some initial pointers for you.

Cheers,
Morag

I'm basically just wondering if its appropriate for the channel's "peer" certificate to be owned by the channel initiator user ID, or if it should be owned by some other user ID. And if the latter, what rights should that user have?

Do you wish to use the this user for your authority checking? If not, then it doesn't matter who it's owned by.
So if we do use this user for authority checking, what might be the issues with this?
Thanks.
Back to top
View user's profile Send private message
hughson
PostPosted: Thu Jul 09, 2020 8:35 pm Post subject: Reply with quote

Padawan

Joined: 09 May 2013
Posts: 1512
Location: Bay of Plenty, New Zealand

Using a user ID associated with a certificate for authority checks is certainly a suitable thing to want to do.

I would argue that setting up a RACF MAP in order to get a user ID associated with the certificate is a more complex way of achieving it than using CHLAUTH mapping rules for the simple reason that you have to set up the rules in RACF rather than in MQ. However you could argue that you are setting up the certificates and the MQ authorities in RACF as well, so why not.

I don't see that there are any issues with doing this, it's just one option available to you.

You can use RACF MAP + RESLEVEL + PUTAUT(DEF) + "Channel User ID" or
you can use CHLAUTH SSLPEERMAP + RESLEVEL + PUTAUT(ONLYMCA) + MCAUSER

The latter one ignores the "Channel User ID" and will (IIRC) remove the CSQX632I message from being emitted too.

Do you currently do authority checks on your channels based on the DN in the certificate? Say by using CHLAUTH ?

Is your aim here to get rid of the CSQX632I message?

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
fswarbrick
PostPosted: Tue Jul 14, 2020 1:32 pm Post subject: Reply with quote

Apprentice

Joined: 07 Jul 2014
Posts: 38

We got the peer to give us the missing cert, and once we added that to the channel initiator's user the problem was resolved. Thanks.
Back to top
View user's profile Send private message
hughson
PostPosted: Tue Jul 14, 2020 9:33 pm Post subject: Reply with quote

Padawan

Joined: 09 May 2013
Posts: 1512
Location: Bay of Plenty, New Zealand

fswarbrick wrote:
We got the peer to give us the missing cert, and once we added that to the channel initiator's user the problem was resolved. Thanks.

This seems like the worse of all possible options. Now you have a copy of the cert that when it changes, you have to get a new copy, negating the use of a certificate being a CA signed one in the first place. It also means that if the certificate is revoked, you have an extra manual step to delete it from your system which is going to keep accepting it on the basis of the installed copy.

You say this resolved the problem, but you never did describe what the problem was? If the problem was "We are getting information message CSQX632I and we want it to go away" which is what I suspect, then there were much easier ways to solve that "problem", like just altering the channel to use PUTAUT(ONLYMCA).

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
fswarbrick
PostPosted: Wed Jul 15, 2020 9:10 am Post subject: Reply with quote

Apprentice

Joined: 07 Jul 2014
Posts: 38

Hi Morag. You are right, I didn't really explain that. My question had been about which user should own the cert, not if that was the correct thing to do at all. I didn't (and even now really don't) have enough knowledge of all of the options and why one might be chosen over another. The point you just made about not storing the cert itself certainly makes sense now that you bring it up, but it's not something I would have realized on my own.

One thing I did not mention is that the channel that had the issue was our SENDER channel. The RECEIVER channel did not not have a similar issue, even though the SSLPEER value is the same for both. My guess is that a RCVR channel sends a cert and a SDR channel validates a cert. Does that make sense? In any case, since a SDR channel does not use the PUTAUT parameter I don't think your PUTAUT solution would work. But it sounds like one of your earlier ideas would work, so I'll take a look at those.

Thanks!
Back to top
View user's profile Send private message
Display posts from previous:
Post new topicReply to topic Page 1 of 1

MQSeries.net Forum IndexMainframe, CICS, TXSeriesz/OS channel SSLCERTU
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.