Morag

I am very glad you responded on this one.  I need some help understanding
this.
How would SSL help control Java Client access where any userid can be
passed?

Should the Chinit not be allowed access to the SSL controlled objects?

Thanks
    Frank


-----Original Message-----
From: MQSeries List [mailto:[EMAIL PROTECTED] On Behalf Of Morag
Hughson
Sent: Tuesday, November 23, 2004 7:05 AM
To: [EMAIL PROTECTED]
Subject: Re: MQ on z/OS security (SSL) question.






SSL authentication has still happened.

The client-connection channel still has a copy of it's personal certificate
on the client machine even though you removed it from the server-connection
machine. The client will still send over this certificate. The fact that the
channel has started means that you must have the CA certificate that signed
the client's certificate in your queue manager key ring.

The message you are seeing tells you that neither a copy of the certificate
(since you removed it), nor a Certifiate Name Filter (CNF) was found
matching the DN of the certificate, so no user could be mapped to it. The
default behaviour when no mapped user ID is found is to use the CHINIT user
ID. This is described in the z/OS System Set-up Guide. This message is an
informational message to let you know a user ID mapping could not be made
(because otherwise it would very difficult to spot mapping failures if you
were trying to use CNF's) it does not indicate that SSL authentication
failed.

Cheers
Morag

Morag Hughson
WebSphere MQ for z/OS Development
Telephone: +44 (0) 1962 816900
Internet: [EMAIL PROTECTED]




             Peter Gersak
             <[EMAIL PROTECTED]
             N.SI>                                                      To
             Sent by: MQSeries         [EMAIL PROTECTED]
             List                                                       cc
             <[EMAIL PROTECTED]
             N.AC.AT>                                              Subject
                                       MQ on z/OS security (SSL) question.

             23/11/2004 10:16


             Please respond to
               MQSeries List







Hello,
I noticed strange MQ SVRCONN channel behavior. Channel is enabled for SSL
encryption and SSL client certificate is enforced. The client certificate's
public keys are stored in RACF. The channel parameters are: DEFINE CHANNEL
('CHLA') +
       CHLTYPE(SVRCONN) +
       TRPTYPE(TCP) +
       DESCR('MQ SVRCONN chl for users') +
       QSGDISP(QMGR) +
       PUTAUT(DEF) +
       MAXMSGL(104857600) +
       MCAUSER(' ') +
       RCVDATA(' ') +
       RCVEXIT(' ') +
       SCYDATA(' ') +
       SCYEXIT(' ') +
       SENDDATA(' ') +
       SENDEXIT(' ') +
       SSLCAUTH(REQUIRED) +
       SSLCIPH('TRIPLE_DES_SHA_US') +
       SSLPEER(' ') +
       KAINT(AUTO) +
       REPLACE

>From RACF I have removed a public certificate user and got the following
message:

+CSQX632I +MQ1 CSQXRESP SSL certificate has no associated user ID, 315
 remote channel ????
 - channel initiator user ID used
+CSQX500I +MQ1 CSQXRESP Channel MQCHANN1 started

So, the certificate could not be located, so the CHINIT user id was used.
But my understanding is that this connection should fail (because of the
parameter SSLCAUTH(REQUIRED)). The PUTAUT(DEF) parameter is left blank
intentionally because many users with different userIDs are using the same
channel.

Any suggestions? Is this normal behavior? What should I do in order to
enforce SSL authentication?

Best Regards, Peter

Peter GerE!ak
3Gen d.o.o., TrE>aE!ka 21, 1000 Ljubljana
M: +386 31 332 787
T: +386 1 42 10 475
E: [EMAIL PROTECTED]"{--J    ~
jvx2
j)b     b.n+bvz'^v)  .a  Z K nW i^jm %rI b` =m`6 f  ` 7 I z r

-----------------------------------------
This e-mail message and any attachments contain confidential information
from Medco. If you are not the intended recipient, you are hereby notified
that disclosure, printing, copying, distribution, or the taking of any
action in reliance on the contents of this electronic information is
strictly prohibited. If you have received this e-mail message in error,
please immediately notify the sender by reply message and then delete the
electronic message and any attachments.

Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive

Reply via email to