[prev in list] [next in list] [prev in thread] [next in thread] 

List:       racf-l
Subject:    Re: Looking for help with Certificate error 428
From:       Joel Tilton <nytamparug () GMAIL ! COM>
Date:       2022-04-12 19:49:34
Message-ID: CAO-bg__pkvE3-ukk3GhLNXpe9=uWmB5m3-b_Vm9jMgJbU9=bLA () mail ! gmail ! com
[Download RAW message or body]

Charles
As I said a couple of times these are FTP CLIENT parms

Please put all the parms in your ftp client config member or flat file you
point to with the SYSFTPD DD card.

TRACE mentioned below goes into your FTP client side parm file
And has nothing to do with the SSL trace you are mentioning
Those are two different things

And you're incorrect the TRACE parm used by the FTP client is better and
gives your more detail in my practical experience.

You will get tracing messages in your batch job from the FTP client that
are actually helpful.

Try a batch job on the system next time with these parms coded and you'll
get more detailed information that even the system ssl trace.

Hope that helps
Joel

On Tue, Apr 12, 2022 at 15:22 Charles Mills <charlesm@mcn.org> wrote:

> As I thought I said a couple of times, I was running with DEBUG SEC and
> System SSL trace.
>
> System SSL trace is as good as it gets. There is no further detail beyond
> that.
>
> FWIW, the client was not z/OS (in my testing -- just easier to use my
> Windows client.)
>
> Charles
>
>
> -----Original Message-----
> From: RACF Discussion List [mailto:RACF-L@LISTSERV.UGA.EDU] On Behalf Of
> Joel Tilton
> Sent: Tuesday, April 12, 2022 11:44 AM
> To: RACF-L@LISTSERV.UGA.EDU
> Subject: Re: Looking for help with Certificate error 428
>
> Charles
> Here are some FTP client parms I recommend that will take the guesswork
> out of debugging this next time
>
> TRACE
> (When combined with debug sec you will get detailed trace messages showing
> each certificate invoked during the handshake process
> Then you can really tell why something is failing
> I think you will also get the key ring names as well
> This made debugging ftp connections painless for me)
>
> LOGCLIENTERR TRUE
> This puts a clear message EZZ9830I at the top of the Job letting you know
> which FTP command fails
>
> CLIENTERRCODES EXTENDED
> (Ensures the full 4 digit error code is passed to the job stream
> This can be cross referenced in comm server manuals to tell you exactly
> what went wrong also)
>
> CLIENTEXIT TRUE
> (Endures the job exits with the overall return code of the error)
>
> I've been in shops where they just exit 12 for all ftp errors and that's
> just so unhelpful to mask the real error codes.
>
> Try those next time
> And let me know how that works out for you
>
> The tracing with debug sec is great
> You can see each certificate as its being evaluated
>
> Thanks
> Joel
>
> Sent from my iPad
>
> > On Mar 30, 2022, at 18:08, Charles Mills <charlesm@mcn.org> wrote:
> >
> > Been running with DEBUG=SEC and posted the messages here twice.
> >
> > Been running the System SSL trace and posted some of those messages here.
> >
> > The problem is solved.
> >
> > IMHO the problem could have been solved in about two minutes if instead
> of saying "Key entry does not contain a private key" the message were
> something more like "Keyring usage is incorrect."
> >
> > Charles
> >
> >
> > -----Original Message-----
> > From: RACF Discussion List [mailto:RACF-L@LISTSERV.UGA.EDU] On Behalf
> Of Joel Tilton
> > Sent: Wednesday, March 30, 2022 2:55 PM
> > To: RACF-L@LISTSERV.UGA.EDU
> > Subject: Re: Looking for help with Certificate error 428
> >
> > There's every specific client side parms to enable ftp debugging that
> will
> > provide exactly the messages you will to get output in your ftp job to
> > figure this out
> >
> > I know
> > DEBUG SEC
> > Is one of them
> >
> > I'll logon later and look up the others
> >
> > Trust me this is the way to go
> >
> > Or we'll just be guessing to figure it out
> >
> >> On Wed, Mar 30, 2022 at 17:53 Charles Mills <charlesm@mcn.org> wrote:
> >>
> >> Signing Algorithm: sha256RSA
> >> Key Type: RSA
> >> Key Size: 2048
> >> Private Key: YES
> >>
> >> Charles
> >>
> >>
> >> -----Original Message-----
> >> From: RACF Discussion List [mailto:RACF-L@LISTSERV.UGA.EDU] On Behalf
> Of
> >> Bell, Robbie (PERATON) (PERM-RES)
> >> Sent: Wednesday, March 30, 2022 11:27 AM
> >> To: RACF-L@LISTSERV.UGA.EDU
> >> Subject: re : Looking for help with Certificate error 428
> >>
> >> Charles
> >>
> >> I noticed this in the trace
> >>
> >> 03/30/2022-11:20:55 Thd-1 ERROR gsk_get_local_certificates(): Record
> >> 'xxxxx.TEST.FTP.ATTLS' does not have a private key
> >>
> >> I dont know if its pertinent or not but
> >> can you list the cert again with a list cert command, and see if there
> is a
> >> difference.
> >> Private keys (or lack thereof) have messed me up big time in the
> past.....
> >>
> > --
> > ----
> > Sent from Gmail
> > Please excuse any typos as I am human.
> >
> > Sincerely,
> > Joel Tilton, Manager
> > NY & TampaBay RACF Users Group
> > May the "z" be with you.
> >
> > This e-mail is confidential and the information contained in it is
> > privileged.  It should not be read, copied or used by anyone other than
> the
> > intended recipient.  If you have received it in error, please contact the
> > sender immediately by return e-mail, delete the e-mail and do not
> disclose
> > its contents to any person.
>
-- 
----
Sent from Gmail
Please excuse any typos as I am human.

Sincerely,
Joel Tilton, Manager
NY & TampaBay RACF Users Group
May the "z" be with you.

This e-mail is confidential and the information contained in it is
privileged.  It should not be read, copied or used by anyone other than the
intended recipient.  If you have received it in error, please contact the
sender immediately by return e-mail, delete the e-mail and do not disclose
its contents to any person.
[prev in list] [next in list] [prev in thread] [next in thread]