They also need the resource that allows for listing of keyrings. Important: Any z/OS-based client or server that uses an RACF key ring issues internal RACDCERT LIST and RACDCERT LISTRING commands. The RACF user ID associated with the server must therefore be granted READ access to the RACF profiles controlling these commands, which are IRR.DIGTCERT.LIST and IRR.DIGTCERT.LISTRING.
PERMIT IRR.DIGTCERT.LIST CLASS(FACILITY) ID(TCPIP) ACCESS(READ) PERMIT IRR.DIGTCERT.LISTRING CLASS(FACILITY) ID(TCPIP) ACCESS(READ) SETR RACLIST(FACILITY) REFRESH Rob On Wed, Feb 23, 2011 at 11:08 AM, Jim McAlpine <jim.mcalp...@gmail.com> wrote: > On Wed, Feb 23, 2011 at 9:04 AM, Jim McAlpine <jim.mcalp...@gmail.com>wrote: > >> On Wed, Feb 23, 2011 at 7:42 AM, Andrew Armstrong < >> androidarmstr...@gmail.com> wrote: >> >>> Jim, >>> >>> The EZY1300E message reports that errno 54 (Connection Reset by Peer) was >>> returned on a RECV socket call by the CICS listener (CSKL). I'd conclude >>> that the remote client has, for one reason or another, decided to drop the >>> connection - probably after the SSL handshake as completed since the >>> listener wouldn't see any action until after that (this would be the >>> "Application Transparent" part of AT-TLS). >>> >>> I've found in the past that using Wireshark (www.wireshark.org) really >>> helps >>> in situations like this. I either use Wireshark to capture the trace on >>> the >>> client side, or take a CTRACE on z/OS (SYSTCPDA) and use IPCS to format >>> the >>> trace into SNIFFER format which I download (in binary) to my PC and let >>> Wireshark decode it. >>> >>> At least you will see how far the SSL handshake progressed. Unfortunately, >>> after you have an encrypted connection decoding the payload is >>> difficult...but not impossible - if you can feed Wireshark your >>> certificate >>> info then it can decrypt the payload too! Although I have to admit to >>> never >>> getting that to work. >>> >>> Another thing you can try is to temporarily turn off encryption by >>> allowing >>> CipherSpec NULL to be negotiated during the SSL handshake. >>> >>> BTW what version of z/OS do you have? I remember trying to set up AT-TLS >>> on >>> a 1.7 system only to find that certificates with keys longer than 1024 >>> bits >>> were not supported by RACF at that level. >>> >>> Cheers, >>> Andrew. >>> >>> ---------------------------------------------------------------------- >>> For IBM-MAIN subscribe / signoff / archive access instructions, >>> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO >>> Search the archives at http://bama.ua.edu/archives/ibm-main.html >>> >> >> >> Andrew, thanks for that good info. We are on z/OS 1.11. Also, I've found >> another message which I missed previously which is this - >> >> EZD1286I TTLS Error GRPID: 00000001 ENVID: 00000006 CONNID: 00000000 >> LOCAL: **N/A** REMOTE: **N/A** JOBNAME: **N/A** USERID: Z30DUSR RULE: >> **N/A** RC: 202 Environment Master Init 00000000 >> The 202 RC is a permission error on the keyring which is much better. I'll >> check out that this afternoon. >> >> Thanks again. >> >> Jim McAlpine >> > > > This is doing my head in. I'm using the redbook to set up the certificates > and keyring. I'm using section 3.4.2 Shared site certificate and shared > keyring so I've run the 6 jobs specified. So I've then ftp'd the self > signed CA certificate to the client but when I try and connect I get the 202 > error which says - > "The key ring cannot be opened because the user does not have permission. " > > > However the error message says - > > BPXF024I (TCPIP) Feb 21 10:03:11 TTLSÝ65578¨: 11:03:11 TCPIP 158 > EZD1286I TTLS Error GRPID: 00000001 ENVID: 00000002 CONNID: 00000000 > LOCAL: **N/A** REMOTE: **N/A** JOBNAME: **N/A** USERID: Z30DUSR RULE: > **N/A** RC: 202 Environment Master Init 00000000 > > which includes the userid of Z30DUSR, and if I do RACDCERT LISTRING, I get > the following - > > RACDCERT LISTRING(*) ID(Z30DUSR) > > Digital ring information for user Z30DUSR: > > Ring: > >SHAREDRING1< > Certificate Label Name Cert Owner USAGE DEFAULT > -------------------------------- ------------ -------- ------- > S0W1 CA1 CERTAUTH CERTAUTH NO > > S0W1 SHAREDSITE1 SITE PERSONAL YES > > which would seem to be OK. Can anyone tell me what I may be missing, or > what else I can check. > > Jim McAlpine > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO > Search the archives at http://bama.ua.edu/archives/ibm-main.html > -- Rob Schramm Senior Systems Engineer w: 513.305.6224 ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
