I have to remember to look at the IBM-MAIN list rather than the archives.
Thanks, everybody, for your help. I'm glad to have another means of tracing for
the (shudder) next time around.
Steve
Steve Pryor
DTS Software, LLC
st...@dtssoftware.com
Well, after considerable struggle involving setting up a completely new FTP
server and experimenting with virtually every possible setting on both sides,
it seems that this can occur if the TLS level used by the z/OS client isn't
supported by the Linux ProFTPD server. Some settings rejiggering
Re: "The format is gsktrace > gskfile.trc > gsk.out "
John is right--it's just gsktrace gskfile.trc > gsk.out
Sorry guys.
Wendell
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to
I've always just did:
gskstrace gsktrace.trc > gsktrace.txt
But I do generally use the gsktrace to try and figure out issues with ssl
negotiation.
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email
connecting to this
server?
From: IBM Mainframe Discussion List on behalf of
John S. Giltner, Jr.
Sent: Monday, March 1, 2021 4:49 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: FTP-SSL from z/OS client to Linux
Well in the data you sent out on the client hello I only
Well in the data you sent out on the client hello I only see two x'35', on is
at byte 3,which is part of the length field. The other is at 2C which really
starts at 2B which is cipher x'0035'
In your 1st post the trace showed part of a error message that I think you were
receiving which as
Hi Steve.
I've found the SSL trace information written into a USS file to be somewhat
easier to use. You can turn on GSK_TRACE flags and specify a trace file using
STDENV similar to the example below IF you specify the
PARM=('ENVAR("_CEE_ENVFILE_S=DD:STDENV") (the _S is crucial or the DD *
I thought perhaps that was it, since I didn't (previously) have the entire CA
certificate chain on the keyring and I don't think the certificate was being
presented. But I've corrected that and it seems to be using the correct
certificate according to the trace below. But I'm still getting the
It's been awhile, but it looks like the Linux server is requesting your SSL
certificate as a client, but is not passing a list of CA's that it trusts.
When the server requests the client to send it's client cert, it supposed to
tell the client what CA's is trusts. Some clients will ignore the
I'm sure I must be missing something here. I'm trying to FTPS from the z/OS 2.2
client to a linux system but failing the handshake. The FTP session indicates:
SC2852 sendCmd: entered
EZA1701I >>> AUTH TLS
10 matches
Mail list logo
