|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
![Reply to topic](templates/DAJ_Glass/images/lang_english/reply.gif) |
|
z/OS channel SSLCERTU |
« View previous topic :: View next topic » |
Author |
Message
|
fswarbrick |
Posted: Wed Jul 08, 2020 8:49 am Post subject: z/OS channel SSLCERTU |
|
|
Apprentice
Joined: 07 Jul 2014 Posts: 42
|
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 manager’s 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 |
|
![](templates/DAJ_Glass/images/spacer.gif) |
hughson |
Posted: Thu Jul 09, 2020 2:49 am Post subject: |
|
|
![](images/avatars/810794940518bb946528b3.jpg) Padawan
Joined: 09 May 2013 Posts: 1916 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 |
|
![](templates/DAJ_Glass/images/spacer.gif) |
fswarbrick |
Posted: Thu Jul 09, 2020 10:27 am Post subject: |
|
|
Apprentice
Joined: 07 Jul 2014 Posts: 42
|
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 |
|
![](templates/DAJ_Glass/images/spacer.gif) |
hughson |
Posted: Thu Jul 09, 2020 5:50 pm Post subject: |
|
|
![](images/avatars/810794940518bb946528b3.jpg) Padawan
Joined: 09 May 2013 Posts: 1916 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 |
|
![](templates/DAJ_Glass/images/spacer.gif) |
fswarbrick |
Posted: Thu Jul 09, 2020 7:52 pm Post subject: |
|
|
Apprentice
Joined: 07 Jul 2014 Posts: 42
|
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 |
|
![](templates/DAJ_Glass/images/spacer.gif) |
hughson |
Posted: Thu Jul 09, 2020 8:35 pm Post subject: |
|
|
![](images/avatars/810794940518bb946528b3.jpg) Padawan
Joined: 09 May 2013 Posts: 1916 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 |
|
![](templates/DAJ_Glass/images/spacer.gif) |
fswarbrick |
Posted: Tue Jul 14, 2020 1:32 pm Post subject: |
|
|
Apprentice
Joined: 07 Jul 2014 Posts: 42
|
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 |
|
![](templates/DAJ_Glass/images/spacer.gif) |
hughson |
Posted: Tue Jul 14, 2020 9:33 pm Post subject: |
|
|
![](images/avatars/810794940518bb946528b3.jpg) Padawan
Joined: 09 May 2013 Posts: 1916 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 |
|
![](templates/DAJ_Glass/images/spacer.gif) |
fswarbrick |
Posted: Wed Jul 15, 2020 9:10 am Post subject: |
|
|
Apprentice
Joined: 07 Jul 2014 Posts: 42
|
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 |
|
![](templates/DAJ_Glass/images/spacer.gif) |
|
|
![Reply to topic](templates/DAJ_Glass/images/lang_english/reply.gif) |
|
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
|
|
|
|