Re: z/OS FTPS Client & Linux FTP server
I'm delayed by the daily digest but did anyone mention the BpxMText suggested Action? To me, it indicates the solution might rely on the other end. TSO BPXMTEXT 77B17343 TCPIP JrTtlsClearTxtReceived: AT-TLS received clear text data when secure data was expected. Action: Enable the remote application for secure connections. Retry the connection. ps. *definitely* a n00b for both tcp/ip & at-tls and probably not helping any. > signature = 6 lines follows < Neil Duffee, Joe Sysprog, uOttawa, Ottawa, Ont, Canada telephone:1 613 562 5800 x4585 fax:1 613 562 5161 mailto:NDuffee of uOttawa.ca http:/ /aix1.uOttawa.ca/ ~nduffee “How *do* you plan for something like that?” Guardian Bob, Reboot “For every action, there is an equal and opposite criticism.” “Systems Programming: Guilty, until proven innocent” John Norgauer 2004 -Original Message- From: Mark Pace [mailto:pacemainl...@gmail.com] Sent: May 12, 2014 14:42 Subject: Re: z/OS FTPS Client & Linux FTP server EZA1554I Connecting to: 10.6.0.10 port: 21. [snip] EDC8121I Connection reset. (errno2=0x77B17343) EZA2897I Authentication negotiation failed EZA1534I *** Control connection with 10.6.0.10 dies. If I read this right the 7343 part of the errno2 says that it expected a secure response, but it was sent clear text. I've tried SECUREIMPLICITZOS both TRUE and FALSE - with true I don't see the 220- messages, but still get the same error. [snip] -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS FTPS Client & Linux FTP server
Donald - I really don't understand this whole certificate thing. And only working with them once every couple of years, I quickly forget what little bit I learned. However I was able to follow your logic about the certificates, root and intermediate. I added the intermediate cert and now I can connect with TLS. Still no joy trying to use AT-TTLS even with the corrected certs. I give up on AT-TTLS. I'll come back to it one day when I TLS no longer works. On Mon, May 12, 2014 at 3:44 PM, Donald J. wrote: > A GSK trace is most likely needed. > Did you ever resolve the intermediate certificate issue I mentioned on > my May 8 message? > > Your ftp.s390.mainline.com server certificate is issued by the GoDaddy > intermediate cert: > Issuer: C=US, ST=Arizona, L=Scottsdale, O=GoDaddy.com, Inc., > OU=http://certificates.godaddy.com/repository, CN=Go Daddy Secure > Certification Authority/ > serialNumber=07969287 > > The GoDaddy intermediate cert above is issued by the root cert : > Issuer: C=US, O=The Go Daddy Group, Inc., OU=Go Daddy Class 2 > Certification Authority > > It appears you do not have the intermediate cert in the keyring at > either end. If you have 100 clients and 1 server, it would be easier to > put in the one server keystore. But you can probably put it in your > z/OS client keystore instead. > > If you can't find it, you can download it from the 3rd cert > (gd_intermediate.crt) on this page: > https://certs.godaddy.com/anonymous/repository.pki > > -- > Donald J. > dona...@4email.net > > > > FC2903 authServerAttls: ioctl() failed on SIOCTTLSCTL - EDC8121I > > Connection > > reset. (errno2=0x77B17343) > > EZA2897I Authentication negotiation > > failed > > EZA1534I *** Control connection with 10.6.0.10 > > dies. > > > > If I read this right the 7343 part of the errno2 says that it expected a > > secure response, but it was sent clear text. > > I've tried > > SECUREIMPLICITZOS both TRUE and FALSE - with true I don't see the 220- > > messages, but still get the same error. > > > > > -- > http://www.fastmail.fm - A fast, anti-spam email service. > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- The postings on this site are my own and don’t necessarily represent Mainline’s positions or opinions Mark D Pace Senior Systems Engineer Mainline Information Systems -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS FTPS Client & Linux FTP server
A GSK trace is most likely needed. Did you ever resolve the intermediate certificate issue I mentioned on my May 8 message? Your ftp.s390.mainline.com server certificate is issued by the GoDaddy intermediate cert: Issuer: C=US, ST=Arizona, L=Scottsdale, O=GoDaddy.com, Inc., OU=http://certificates.godaddy.com/repository, CN=Go Daddy Secure Certification Authority/ serialNumber=07969287 The GoDaddy intermediate cert above is issued by the root cert : Issuer: C=US, O=The Go Daddy Group, Inc., OU=Go Daddy Class 2 Certification Authority It appears you do not have the intermediate cert in the keyring at either end. If you have 100 clients and 1 server, it would be easier to put in the one server keystore. But you can probably put it in your z/OS client keystore instead. If you can't find it, you can download it from the 3rd cert (gd_intermediate.crt) on this page: https://certs.godaddy.com/anonymous/repository.pki -- Donald J. dona...@4email.net > FC2903 authServerAttls: ioctl() failed on SIOCTTLSCTL - EDC8121I > Connection > reset. (errno2=0x77B17343) > EZA2897I Authentication negotiation > failed > EZA1534I *** Control connection with 10.6.0.10 > dies. > > If I read this right the 7343 part of the errno2 says that it expected a > secure response, but it was sent clear text. > I've tried > SECUREIMPLICITZOS both TRUE and FALSE - with true I don't see the 220- > messages, but still get the same error. > -- http://www.fastmail.fm - A fast, anti-spam email service. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS FTPS Client & Linux FTP server
EZA1554I Connecting to: 10.6.0.10 port:
21.
220-Welcome to Mainline's FTP
Server.
220-
220-This FTP server is limited to use by Mainline employees,
customers
220-and authorized business
partners.
220-
220-NOTE: All files may be deleted after 30
days.
220
GU5349 ftpSetApplData:
entered
FC0254 ftpAuth: security values: mech=TLS, tlsmech=ATTLS, sFTP=R, sCC=P,
sDC=P
FC2738 ftpAuthAttls: AT-TLS policy set as application
controlled.
FU1810 TTLSRule:
Secure_Ftp_client
FU1816 TTLSGroupAction:
grp_Production
FU1822 TTLSEnvironmentAction:
Secure_Ftp_Client_Env
FC2894 authServerAttls: Start
Handshake
FC2903 authServerAttls: ioctl() failed on SIOCTTLSCTL - EDC8121I Connection
reset. (errno2=0x77B17343)
EZA2897I Authentication negotiation
failed
EZA1534I *** Control connection with 10.6.0.10
dies.
If I read this right the 7343 part of the errno2 says that it expected a
secure response, but it was sent clear text.
I've tried
SECUREIMPLICITZOS both TRUE and FALSE - with true I don't see the 220-
messages, but still get the same error.
On Mon, May 12, 2014 at 1:39 PM, Donald J. wrote:
> You need ApplicationControlled On as well as SecondaryMap On.
>
> Issue this command to see your resultant config:
> pasearch -p TCPIP > tcpip.pagent.dat
>
>
> --
> Donald J.
> dona...@4email.net
> > > TTLSEnvironmentAdvancedParms
> > > {
> > > SecondaryMap On
>
>
> --
> http://www.fastmail.fm - The way an email service should be
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
--
The postings on this site are my own and don’t necessarily represent
Mainline’s positions or opinions
Mark D Pace
Senior Systems Engineer
Mainline Information Systems
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS FTPS Client & Linux FTP server
You need ApplicationControlled On as well as SecondaryMap On.
Issue this command to see your resultant config:
pasearch -p TCPIP > tcpip.pagent.dat
--
Donald J.
dona...@4email.net
> > TTLSEnvironmentAdvancedParms
> > {
> > SecondaryMap On
--
http://www.fastmail.fm - The way an email service should be
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS FTPS Client & Linux FTP server
t; >> > On Fri, May 9, 2014 at 4:09 PM, Gibney, Dave wrote: >> > >> > > On looking at it, I think the >> > > > TLSRFCLEVEL CCCNONOTIFY ; >> > > And/or the >> > > > EPSV4 TRUE >> > > Are newish (in that they were what I had to put in to make it work the >> > > last time it broke :) It tends to break when maintenance is put on >> Linux >> > or >> > > vsftp :) >> > > >> > > > -Original Message- >> > > > From: IBM Mainframe Discussion List [mailto: >> IBM-MAIN@LISTSERV.UA.EDU] >> > > > On Behalf Of Mark Pace >> > > > Sent: Friday, May 09, 2014 1:00 PM >> > > > To: IBM-MAIN@LISTSERV.UA.EDU >> > > > Subject: Re: z/OS FTPS Client & Linux FTP server >> > > > >> > > > WOAH, WOAH, WOAH, what the hell? I copied and pasted your >> FTP.DATA >> > > > file >> > > > into my FTP.DATA file and now it works. >> > > > >> > > > Now I just have to determine what was different on yours than every >> > > iteration >> > > > that I have been through so far. >> > > > >> > > > THANKS, I think. ;) >> > > > >> > > > >> > > > On Fri, May 9, 2014 at 2:28 PM, Gibney, Dave >> wrote: >> > > > >> > > > > Well, for what it is worth, I use the following in my >> userid.FTP.DATA >> > > > > and successfully talk to vsftp with SSL Encryption: >> > > > > TLSRFCLEVEL CCCNONOTIFY ; >> > > > > EPSV4 TRUE >> > > > > TLSMECHANISM FTP >> > > > > SECURE_MECHANISM TLS >> > > > > SECURE_FTP REQUIRED >> > > > > SECURE_CTRLCONN CLEAR >> > > > > SECURE_DATACONN PRIVATE >> > > > > CIPHERSUITE SSL_NULL_MD5 ; 01 >> > > > > CIPHERSUITE SSL_NULL_SHA ; 02 >> > > > > CIPHERSUITE SSL_RC4_MD5_EX; 03 >> > > > > CIPHERSUITE SSL_RC4_MD5 ; 04 >> > > > > CIPHERSUITE SSL_RC4_SHA ; 05 >> > > > > CIPHERSUITE SSL_RC2_MD5_EX; 06 >> > > > > CIPHERSUITE SSL_DES_SHA ; 09 >> > > > > CIPHERSUITE SSL_3DES_SHA ; 0A >> > > > > >> > > > > KEYRING FTPClientRing >> > > > > >> > > > > My RACF keyring has: >> > > > > Ring: >> > > > > >FTPClientRing< >> > > > > Certificate Label Name Cert Owner USAGE >> DEFAULT >> > > > > >> --- >> > > > > Thawte Premium Server CA CERTAUTH CERTAUTH NO >> > > > > >> > > > > thawte Primary Root CA CERTAUTH CERTAUTH NO >> > > > > >> > > > > Thawte Server CA CERTAUTH CERTAUTH NO >> > > > > >> > > > > Thawte DV SSL CA CERTAUTH CERTAUTH NO >> > > > > >> > > > > I did find it necessary to have the full chain in my keyring. >> > > > > >> > > > > I just use //MVSFTP EXEC PGM=FTP, >> > > > > >> > > > > I don't maintain the Linux server, so I can't quickly get the full >> > > > > vsftp parm deck. I can ask for it. >> > > > > >> > > > > > -Original Message- >> > > > > > From: IBM Mainframe Discussion List >> > > > > > [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Mark Pace >> > > > > > Sent: Friday, May 09, 2014 10:58 AM >> > > > > > To: IBM-MAIN@LISTSERV.UA.EDU >> > > > > > Subject: Re: z/OS FTPS Client & Linux FTP server >> > > > > > >> > > > > > Sorry, confused, again. >> > > > > > >> > > > > > We currently do userid/password authentication - without SSL. >> > > > > > >> > > > > > >> > > > > > On Fri, May 9, 2014 at 1:42 PM, Gibney, Dave >> > wrote: >> > > > > > >> > > > > > > Well, if your are doing the SSL server s
Re: z/OS FTPS Client & Linux FTP server
I'm trying to make the AT-TLS stuff work, but I'm just as confused by this
as the original stuff. The PAGENT setup seemed pretty straight forward.
pagent.conf
TTLSConfig /etc/pagent_TTLS.conf
pagent_TTLS.conf
# Common Production Group that all Rules use
TTLSGroupAction grp_Production
{
TTLSEnabled On
Trace 2 # Log Errors to syslogd
}
###
# #
# FTP Specific Rules and Actions #
# #
###
# FTP data connections must use SecondaryMap
# to access keyring and certificate under server's security context.
# Do not define separate rules for FTP data connections.
TTLSRule Secure_Ftp_client
{
LocalPortRange 21
DirectionOutbound
TTLSGroupActionRef grp_Production
TTLSEnvironmentActionRef Secure_Ftp_Client_Env
}
# Environment Shared by all secure FTP client connections.
# each client must own their own key ring named Client_Ring
TTLSEnvironmentAction Secure_Ftp_Client_Env
{
HandshakeRole Client
TTLSKeyRingParms
{
Keyring Client_Ring
}
TTLSEnvironmentAdvancedParms
{
SecondaryMap On
}
}
It appears that the correct configurations are loaded. - my only question
being if INET is the correct name.
EZZ8432I PAGENT INITIALIZATION COMPLETE
EZD1289I TCPIP ICSF SERVICES ARE CURRENTLY AVAILABLE FOR AT-TLS GROUP
grp_Production
EZZ8771I PAGENT CONFIG POLICY PROCESSING COMPLETE FOR INET : TTLS
EZD1586I PAGENT HAS INSTALLED ALL LOCAL POLICIES FOR INET
Run the FTP and it fails saying there is now matching policy
GU5349 ftpSetApplData:
entered
FC0254 ftpAuth: security values: mech=TLS, tlsmech=ATTLS, sFTP=R, sCC=P,
sDC=P
FC2723 ftpAuthAttls: No AT-TLS policy matched
connection
EZA2897I Authentication negotiation
failed
On Sat, May 10, 2014 at 2:21 PM, Rob Schramm wrote:
> Congrats.
>
> Of course the latest recommendations are to move away from TLS 1.0 because
> of vulnerabilities.
>
> Rob Schramm
> On May 9, 2014 4:48 PM, "Mark Pace" wrote:
>
> > One thing I just noticed as I was documenting this.
> > I had changed my ftp server from using the GoDaddy assigned certificate
> to
> > a self-signed certificate. I had send a copy of the .pem file to z/OS
> and
> > added it to my keyring as Site certificate. - That is what worked.
> >
> > So I went back to the GoDaddy certificate on the server, and I still
> have,
> > what I thought was a good Certauth from GoDaddy on my key ring and now my
> > error is - FC1003 authServer: secure_socket_init failed with rc = 417
> > (Self-signed certificate cannot be validated)
> >
> > So now I need to figure out how to get the Certauth working as I don't
> > really want to have to send my self-signed out.
> >
> > Something to ponder next week.
> >
> >
> > On Fri, May 9, 2014 at 4:09 PM, Gibney, Dave wrote:
> >
> > > On looking at it, I think the
> > > > TLSRFCLEVEL CCCNONOTIFY ;
> > > And/or the
> > > > EPSV4 TRUE
> > > Are newish (in that they were what I had to put in to make it work the
> > > last time it broke :) It tends to break when maintenance is put on
> Linux
> > or
> > > vsftp :)
> > >
> > > > -Original Message-
> > > > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU
> ]
> > > > On Behalf Of Mark Pace
> > > > Sent: Friday, May 09, 2014 1:00 PM
> > > > To: IBM-MAIN@LISTSERV.UA.EDU
> > > > Subject: Re: z/OS FTPS Client & Linux FTP server
> > > >
> > > > WOAH, WOAH, WOAH, what the hell? I copied and pasted your FTP.DATA
> > > > file
> > > > into my FTP.DATA file and now it works.
> > > >
> > > > Now I just have to determine what was different on yours than every
> > > iteration
> > > > that I have been through so far.
> > > >
> > > > THANKS, I think. ;)
> > > >
> > > >
> > > > On Fri, May 9, 2014 at 2:28 PM, Gibney, Dave wrote:
> > > >
> > > > > Well, for what it is worth, I use the following in my
> userid.FTP.DATA
> > > > > and successfully talk to vsftp with SSL Encryption:
> > > > > TLSRFCLEVEL CCCNONOTIFY ;
> > > > > EPSV4 TRUE
> > > > > TLSMECHANISM FTP
> > > > > SECURE_MECHANISM TLS
> > > > > SECURE_FTP REQ
Re: z/OS FTPS Client & Linux FTP server
Congrats. Of course the latest recommendations are to move away from TLS 1.0 because of vulnerabilities. Rob Schramm On May 9, 2014 4:48 PM, "Mark Pace" wrote: > One thing I just noticed as I was documenting this. > I had changed my ftp server from using the GoDaddy assigned certificate to > a self-signed certificate. I had send a copy of the .pem file to z/OS and > added it to my keyring as Site certificate. - That is what worked. > > So I went back to the GoDaddy certificate on the server, and I still have, > what I thought was a good Certauth from GoDaddy on my key ring and now my > error is - FC1003 authServer: secure_socket_init failed with rc = 417 > (Self-signed certificate cannot be validated) > > So now I need to figure out how to get the Certauth working as I don't > really want to have to send my self-signed out. > > Something to ponder next week. > > > On Fri, May 9, 2014 at 4:09 PM, Gibney, Dave wrote: > > > On looking at it, I think the > > > TLSRFCLEVEL CCCNONOTIFY ; > > And/or the > > > EPSV4 TRUE > > Are newish (in that they were what I had to put in to make it work the > > last time it broke :) It tends to break when maintenance is put on Linux > or > > vsftp :) > > > > > -Original Message- > > > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > > > On Behalf Of Mark Pace > > > Sent: Friday, May 09, 2014 1:00 PM > > > To: IBM-MAIN@LISTSERV.UA.EDU > > > Subject: Re: z/OS FTPS Client & Linux FTP server > > > > > > WOAH, WOAH, WOAH, what the hell? I copied and pasted your FTP.DATA > > > file > > > into my FTP.DATA file and now it works. > > > > > > Now I just have to determine what was different on yours than every > > iteration > > > that I have been through so far. > > > > > > THANKS, I think. ;) > > > > > > > > > On Fri, May 9, 2014 at 2:28 PM, Gibney, Dave wrote: > > > > > > > Well, for what it is worth, I use the following in my userid.FTP.DATA > > > > and successfully talk to vsftp with SSL Encryption: > > > > TLSRFCLEVEL CCCNONOTIFY ; > > > > EPSV4 TRUE > > > > TLSMECHANISM FTP > > > > SECURE_MECHANISM TLS > > > > SECURE_FTP REQUIRED > > > > SECURE_CTRLCONN CLEAR > > > > SECURE_DATACONN PRIVATE > > > > CIPHERSUITE SSL_NULL_MD5 ; 01 > > > > CIPHERSUITE SSL_NULL_SHA ; 02 > > > > CIPHERSUITE SSL_RC4_MD5_EX; 03 > > > > CIPHERSUITE SSL_RC4_MD5 ; 04 > > > > CIPHERSUITE SSL_RC4_SHA ; 05 > > > > CIPHERSUITE SSL_RC2_MD5_EX; 06 > > > > CIPHERSUITE SSL_DES_SHA ; 09 > > > > CIPHERSUITE SSL_3DES_SHA ; 0A > > > > > > > > KEYRING FTPClientRing > > > > > > > > My RACF keyring has: > > > > Ring: > > > > >FTPClientRing< > > > > Certificate Label Name Cert Owner USAGE DEFAULT > > > > --- > > > > Thawte Premium Server CA CERTAUTH CERTAUTH NO > > > > > > > > thawte Primary Root CA CERTAUTH CERTAUTH NO > > > > > > > > Thawte Server CA CERTAUTH CERTAUTH NO > > > > > > > > Thawte DV SSL CA CERTAUTH CERTAUTH NO > > > > > > > > I did find it necessary to have the full chain in my keyring. > > > > > > > > I just use //MVSFTP EXEC PGM=FTP, > > > > > > > > I don't maintain the Linux server, so I can't quickly get the full > > > > vsftp parm deck. I can ask for it. > > > > > > > > > -Original Message- > > > > > From: IBM Mainframe Discussion List > > > > > [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Mark Pace > > > > > Sent: Friday, May 09, 2014 10:58 AM > > > > > To: IBM-MAIN@LISTSERV.UA.EDU > > > > > Subject: Re: z/OS FTPS Client & Linux FTP server > > > > > > > > > > Sorry, confused, again. > > > > > > > > > > We currently do userid/password authentication - without SSL. > > > > > > > > > > > > > > > On Fri, May 9, 2014 at 1:42 PM, Gibney, Dave >
Re: z/OS FTPS Client & Linux FTP server
One thing I just noticed as I was documenting this. I had changed my ftp server from using the GoDaddy assigned certificate to a self-signed certificate. I had send a copy of the .pem file to z/OS and added it to my keyring as Site certificate. - That is what worked. So I went back to the GoDaddy certificate on the server, and I still have, what I thought was a good Certauth from GoDaddy on my key ring and now my error is - FC1003 authServer: secure_socket_init failed with rc = 417 (Self-signed certificate cannot be validated) So now I need to figure out how to get the Certauth working as I don't really want to have to send my self-signed out. Something to ponder next week. On Fri, May 9, 2014 at 4:09 PM, Gibney, Dave wrote: > On looking at it, I think the > > TLSRFCLEVEL CCCNONOTIFY ; > And/or the > > EPSV4 TRUE > Are newish (in that they were what I had to put in to make it work the > last time it broke :) It tends to break when maintenance is put on Linux or > vsftp :) > > > -Original Message- > > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > > On Behalf Of Mark Pace > > Sent: Friday, May 09, 2014 1:00 PM > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: Re: z/OS FTPS Client & Linux FTP server > > > > WOAH, WOAH, WOAH, what the hell? I copied and pasted your FTP.DATA > > file > > into my FTP.DATA file and now it works. > > > > Now I just have to determine what was different on yours than every > iteration > > that I have been through so far. > > > > THANKS, I think. ;) > > > > > > On Fri, May 9, 2014 at 2:28 PM, Gibney, Dave wrote: > > > > > Well, for what it is worth, I use the following in my userid.FTP.DATA > > > and successfully talk to vsftp with SSL Encryption: > > > TLSRFCLEVEL CCCNONOTIFY ; > > > EPSV4 TRUE > > > TLSMECHANISM FTP > > > SECURE_MECHANISM TLS > > > SECURE_FTP REQUIRED > > > SECURE_CTRLCONN CLEAR > > > SECURE_DATACONN PRIVATE > > > CIPHERSUITE SSL_NULL_MD5 ; 01 > > > CIPHERSUITE SSL_NULL_SHA ; 02 > > > CIPHERSUITE SSL_RC4_MD5_EX; 03 > > > CIPHERSUITE SSL_RC4_MD5 ; 04 > > > CIPHERSUITE SSL_RC4_SHA ; 05 > > > CIPHERSUITE SSL_RC2_MD5_EX; 06 > > > CIPHERSUITE SSL_DES_SHA ; 09 > > > CIPHERSUITE SSL_3DES_SHA ; 0A > > > > > > KEYRING FTPClientRing > > > > > > My RACF keyring has: > > > Ring: > > > >FTPClientRing< > > > Certificate Label Name Cert Owner USAGE DEFAULT > > > --- > > > Thawte Premium Server CA CERTAUTH CERTAUTH NO > > > > > > thawte Primary Root CA CERTAUTH CERTAUTH NO > > > > > > Thawte Server CA CERTAUTH CERTAUTH NO > > > > > > Thawte DV SSL CA CERTAUTH CERTAUTH NO > > > > > > I did find it necessary to have the full chain in my keyring. > > > > > > I just use //MVSFTP EXEC PGM=FTP, > > > > > > I don't maintain the Linux server, so I can't quickly get the full > > > vsftp parm deck. I can ask for it. > > > > > > > -Original Message- > > > > From: IBM Mainframe Discussion List > > > > [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Mark Pace > > > > Sent: Friday, May 09, 2014 10:58 AM > > > > To: IBM-MAIN@LISTSERV.UA.EDU > > > > Subject: Re: z/OS FTPS Client & Linux FTP server > > > > > > > > Sorry, confused, again. > > > > > > > > We currently do userid/password authentication - without SSL. > > > > > > > > > > > > On Fri, May 9, 2014 at 1:42 PM, Gibney, Dave wrote: > > > > > > > > > Well, if your are doing the SSL server stuff, then the password is > > > > > not flowing in the clear. On the other hand, my interpretation of > > > > > the vsftp parm I sent a few days ago is to NOT do certificate > > > > > based client authentication. > > > > > > > > > > > -Original Message- > > > > > > From: IBM Mainframe Discussion List > > > > > > [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Mark Pace > > > > > > Sent: Friday, May 09, 2014 9:19 AM >
Re: z/OS FTPS Client & Linux FTP server
On looking at it, I think the > TLSRFCLEVEL CCCNONOTIFY ; And/or the > EPSV4 TRUE Are newish (in that they were what I had to put in to make it work the last time it broke :) It tends to break when maintenance is put on Linux or vsftp :) > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > On Behalf Of Mark Pace > Sent: Friday, May 09, 2014 1:00 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: z/OS FTPS Client & Linux FTP server > > WOAH, WOAH, WOAH, what the hell? I copied and pasted your FTP.DATA > file > into my FTP.DATA file and now it works. > > Now I just have to determine what was different on yours than every iteration > that I have been through so far. > > THANKS, I think. ;) > > > On Fri, May 9, 2014 at 2:28 PM, Gibney, Dave wrote: > > > Well, for what it is worth, I use the following in my userid.FTP.DATA > > and successfully talk to vsftp with SSL Encryption: > > TLSRFCLEVEL CCCNONOTIFY ; > > EPSV4 TRUE > > TLSMECHANISM FTP > > SECURE_MECHANISM TLS > > SECURE_FTP REQUIRED > > SECURE_CTRLCONN CLEAR > > SECURE_DATACONN PRIVATE > > CIPHERSUITE SSL_NULL_MD5 ; 01 > > CIPHERSUITE SSL_NULL_SHA ; 02 > > CIPHERSUITE SSL_RC4_MD5_EX; 03 > > CIPHERSUITE SSL_RC4_MD5 ; 04 > > CIPHERSUITE SSL_RC4_SHA ; 05 > > CIPHERSUITE SSL_RC2_MD5_EX; 06 > > CIPHERSUITE SSL_DES_SHA ; 09 > > CIPHERSUITE SSL_3DES_SHA ; 0A > > > > KEYRING FTPClientRing > > > > My RACF keyring has: > > Ring: > > >FTPClientRing< > > Certificate Label Name Cert Owner USAGE DEFAULT > > --- > > Thawte Premium Server CA CERTAUTH CERTAUTH NO > > > > thawte Primary Root CA CERTAUTH CERTAUTH NO > > > > Thawte Server CA CERTAUTH CERTAUTH NO > > > > Thawte DV SSL CA CERTAUTH CERTAUTH NO > > > > I did find it necessary to have the full chain in my keyring. > > > > I just use //MVSFTP EXEC PGM=FTP, > > > > I don't maintain the Linux server, so I can't quickly get the full > > vsftp parm deck. I can ask for it. > > > > > -Original Message- > > > From: IBM Mainframe Discussion List > > > [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Mark Pace > > > Sent: Friday, May 09, 2014 10:58 AM > > > To: IBM-MAIN@LISTSERV.UA.EDU > > > Subject: Re: z/OS FTPS Client & Linux FTP server > > > > > > Sorry, confused, again. > > > > > > We currently do userid/password authentication - without SSL. > > > > > > > > > On Fri, May 9, 2014 at 1:42 PM, Gibney, Dave wrote: > > > > > > > Well, if your are doing the SSL server stuff, then the password is > > > > not flowing in the clear. On the other hand, my interpretation of > > > > the vsftp parm I sent a few days ago is to NOT do certificate > > > > based client authentication. > > > > > > > > > -Original Message- > > > > > From: IBM Mainframe Discussion List > > > > > [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Mark Pace > > > > > Sent: Friday, May 09, 2014 9:19 AM > > > > > To: IBM-MAIN@LISTSERV.UA.EDU > > > > > Subject: Re: z/OS FTPS Client & Linux FTP server > > > > > > > > > > Oh yes. We've been doing it that way for years. > > > > > > > > > > Trying to add the ability to secure the log in process. > > > > > > > > > > > > > > > On Fri, May 9, 2014 at 11:42 AM, Gibney, Dave > > wrote: > > > > > > > > > > > I haven't used SSL client verification by certificate, so you > > > > > > are past my knowledge. As an experiment, can you get a working > > > > > > connection using userid/password authentication. > > > > > > > > > > > > > -Original Message- > > > > > > > From: IBM Mainframe Discussion List > > > > > > > [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Mark Pace > > > > > > > Sent: Friday, May 09, 2014 5:47 AM > > > > > > > To: IBM-MAIN@LISTSERV.UA.EDU > > > > > > > Subject: Re: z/O
Re: z/OS FTPS Client & Linux FTP server
WOAH, WOAH, WOAH, what the hell? I copied and pasted your FTP.DATA file into my FTP.DATA file and now it works. Now I just have to determine what was different on yours than every iteration that I have been through so far. THANKS, I think. ;) On Fri, May 9, 2014 at 2:28 PM, Gibney, Dave wrote: > Well, for what it is worth, I use the following in my userid.FTP.DATA and > successfully talk to vsftp with SSL Encryption: > TLSRFCLEVEL CCCNONOTIFY ; > EPSV4 TRUE > TLSMECHANISM FTP > SECURE_MECHANISM TLS > SECURE_FTP REQUIRED > SECURE_CTRLCONN CLEAR > SECURE_DATACONN PRIVATE > CIPHERSUITE SSL_NULL_MD5 ; 01 > CIPHERSUITE SSL_NULL_SHA ; 02 > CIPHERSUITE SSL_RC4_MD5_EX; 03 > CIPHERSUITE SSL_RC4_MD5 ; 04 > CIPHERSUITE SSL_RC4_SHA ; 05 > CIPHERSUITE SSL_RC2_MD5_EX; 06 > CIPHERSUITE SSL_DES_SHA ; 09 > CIPHERSUITE SSL_3DES_SHA ; 0A > > KEYRING FTPClientRing > > My RACF keyring has: > Ring: > >FTPClientRing< > Certificate Label Name Cert Owner USAGE DEFAULT > --- > Thawte Premium Server CA CERTAUTH CERTAUTH NO > > thawte Primary Root CA CERTAUTH CERTAUTH NO > > Thawte Server CA CERTAUTH CERTAUTH NO > > Thawte DV SSL CA CERTAUTH CERTAUTH NO > > I did find it necessary to have the full chain in my keyring. > > I just use //MVSFTP EXEC PGM=FTP, > > I don't maintain the Linux server, so I can't quickly get the full vsftp > parm deck. I can ask for it. > > > -Original Message- > > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > > On Behalf Of Mark Pace > > Sent: Friday, May 09, 2014 10:58 AM > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: Re: z/OS FTPS Client & Linux FTP server > > > > Sorry, confused, again. > > > > We currently do userid/password authentication - without SSL. > > > > > > On Fri, May 9, 2014 at 1:42 PM, Gibney, Dave wrote: > > > > > Well, if your are doing the SSL server stuff, then the password is not > > > flowing in the clear. On the other hand, my interpretation of the > > > vsftp parm I sent a few days ago is to NOT do certificate based client > > > authentication. > > > > > > > -Original Message- > > > > From: IBM Mainframe Discussion List > > > > [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Mark Pace > > > > Sent: Friday, May 09, 2014 9:19 AM > > > > To: IBM-MAIN@LISTSERV.UA.EDU > > > > Subject: Re: z/OS FTPS Client & Linux FTP server > > > > > > > > Oh yes. We've been doing it that way for years. > > > > > > > > Trying to add the ability to secure the log in process. > > > > > > > > > > > > On Fri, May 9, 2014 at 11:42 AM, Gibney, Dave > wrote: > > > > > > > > > I haven't used SSL client verification by certificate, so you are > > > > > past my knowledge. As an experiment, can you get a working > > > > > connection using userid/password authentication. > > > > > > > > > > > -Original Message- > > > > > > From: IBM Mainframe Discussion List > > > > > > [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Mark Pace > > > > > > Sent: Friday, May 09, 2014 5:47 AM > > > > > > To: IBM-MAIN@LISTSERV.UA.EDU > > > > > > Subject: Re: z/OS FTPS Client & Linux FTP server > > > > > > > > > > > > I was able to get the Trace to work - after removing the -r TLS, > > > > > > that generated an error. > > > > > > *EZA2892I Secure port 21 does not allow the -a or -r start > > > > > > parameter > > > > > > * > > > > > > > > > > > > And from that trace it appears, to me, that the FTP server is > > > > > > not responding correctly to the z/OS client handshake. > > > > > > > > > > > > 05/08/2014-16:46:27 Thd-0 INFO send_v3_client_hello(): Sent V3 > > > > > > CLIENT- HELLO message > > > > > > 05/08/2014-16:46:27 Thd-0 ASCII send_v3_client_hello(): V3 > > > > > > CLIENT-HELLO message > > > > > > : 012b 0301536b ed23cf50 8d72c5f7 > > &
Re: z/OS FTPS Client & Linux FTP server
Well, for what it is worth, I use the following in my userid.FTP.DATA and
successfully talk to vsftp with SSL Encryption:
TLSRFCLEVEL CCCNONOTIFY ;
EPSV4 TRUE
TLSMECHANISM FTP
SECURE_MECHANISM TLS
SECURE_FTP REQUIRED
SECURE_CTRLCONN CLEAR
SECURE_DATACONN PRIVATE
CIPHERSUITE SSL_NULL_MD5 ; 01
CIPHERSUITE SSL_NULL_SHA ; 02
CIPHERSUITE SSL_RC4_MD5_EX; 03
CIPHERSUITE SSL_RC4_MD5 ; 04
CIPHERSUITE SSL_RC4_SHA ; 05
CIPHERSUITE SSL_RC2_MD5_EX; 06
CIPHERSUITE SSL_DES_SHA ; 09
CIPHERSUITE SSL_3DES_SHA ; 0A
KEYRING FTPClientRing
My RACF keyring has:
Ring:
>FTPClientRing<
Certificate Label Name Cert Owner USAGE DEFAULT
---
Thawte Premium Server CA CERTAUTH CERTAUTH NO
thawte Primary Root CA CERTAUTH CERTAUTH NO
Thawte Server CA CERTAUTH CERTAUTH NO
Thawte DV SSL CA CERTAUTH CERTAUTH NO
I did find it necessary to have the full chain in my keyring.
I just use //MVSFTP EXEC PGM=FTP,
I don't maintain the Linux server, so I can't quickly get the full vsftp parm
deck. I can ask for it.
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Mark Pace
> Sent: Friday, May 09, 2014 10:58 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: z/OS FTPS Client & Linux FTP server
>
> Sorry, confused, again.
>
> We currently do userid/password authentication - without SSL.
>
>
> On Fri, May 9, 2014 at 1:42 PM, Gibney, Dave wrote:
>
> > Well, if your are doing the SSL server stuff, then the password is not
> > flowing in the clear. On the other hand, my interpretation of the
> > vsftp parm I sent a few days ago is to NOT do certificate based client
> > authentication.
> >
> > > -Original Message-
> > > From: IBM Mainframe Discussion List
> > > [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Mark Pace
> > > Sent: Friday, May 09, 2014 9:19 AM
> > > To: IBM-MAIN@LISTSERV.UA.EDU
> > > Subject: Re: z/OS FTPS Client & Linux FTP server
> > >
> > > Oh yes. We've been doing it that way for years.
> > >
> > > Trying to add the ability to secure the log in process.
> > >
> > >
> > > On Fri, May 9, 2014 at 11:42 AM, Gibney, Dave wrote:
> > >
> > > > I haven't used SSL client verification by certificate, so you are
> > > > past my knowledge. As an experiment, can you get a working
> > > > connection using userid/password authentication.
> > > >
> > > > > -Original Message-
> > > > > From: IBM Mainframe Discussion List
> > > > > [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Mark Pace
> > > > > Sent: Friday, May 09, 2014 5:47 AM
> > > > > To: IBM-MAIN@LISTSERV.UA.EDU
> > > > > Subject: Re: z/OS FTPS Client & Linux FTP server
> > > > >
> > > > > I was able to get the Trace to work - after removing the -r TLS,
> > > > > that generated an error.
> > > > > *EZA2892I Secure port 21 does not allow the -a or -r start
> > > > > parameter
> > > > > *
> > > > >
> > > > > And from that trace it appears, to me, that the FTP server is
> > > > > not responding correctly to the z/OS client handshake.
> > > > >
> > > > > 05/08/2014-16:46:27 Thd-0 INFO send_v3_client_hello(): Sent V3
> > > > > CLIENT- HELLO message
> > > > > 05/08/2014-16:46:27 Thd-0 ASCII send_v3_client_hello(): V3
> > > > > CLIENT-HELLO message
> > > > > : 012b 0301536b ed23cf50 8d72c5f7
> > > > > *...+..Sk.#.P.r..*
> > > > > 0010: 201c1c84 2fef8ce6 3228c3b3 8de37177 *
> > > > > .../...2(qw*
> > > > > 0020: a3e6e150 a3c5 0400ff00 050100
> > > > > *...P...
> > &
Re: z/OS FTPS Client & Linux FTP server
Sorry, confused, again.
We currently do userid/password authentication - without SSL.
On Fri, May 9, 2014 at 1:42 PM, Gibney, Dave wrote:
> Well, if your are doing the SSL server stuff, then the password is not
> flowing in the clear. On the other hand, my interpretation of the vsftp
> parm I sent a few days ago is to NOT do certificate based client
> authentication.
>
> > -Original Message-
> > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> > On Behalf Of Mark Pace
> > Sent: Friday, May 09, 2014 9:19 AM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: z/OS FTPS Client & Linux FTP server
> >
> > Oh yes. We've been doing it that way for years.
> >
> > Trying to add the ability to secure the log in process.
> >
> >
> > On Fri, May 9, 2014 at 11:42 AM, Gibney, Dave wrote:
> >
> > > I haven't used SSL client verification by certificate, so you are past
> > > my knowledge. As an experiment, can you get a working connection using
> > > userid/password authentication.
> > >
> > > > -Original Message-
> > > > From: IBM Mainframe Discussion List
> > > > [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Mark Pace
> > > > Sent: Friday, May 09, 2014 5:47 AM
> > > > To: IBM-MAIN@LISTSERV.UA.EDU
> > > > Subject: Re: z/OS FTPS Client & Linux FTP server
> > > >
> > > > I was able to get the Trace to work - after removing the -r TLS,
> > > > that generated an error.
> > > > *EZA2892I Secure port 21 does not allow the -a or -r start parameter
> > > > *
> > > >
> > > > And from that trace it appears, to me, that the FTP server is not
> > > > responding correctly to the z/OS client handshake.
> > > >
> > > > 05/08/2014-16:46:27 Thd-0 INFO send_v3_client_hello(): Sent V3
> > > > CLIENT- HELLO message
> > > > 05/08/2014-16:46:27 Thd-0 ASCII send_v3_client_hello(): V3
> > > > CLIENT-HELLO message
> > > > : 012b 0301536b ed23cf50 8d72c5f7
> > > > *...+..Sk.#.P.r..*
> > > > 0010: 201c1c84 2fef8ce6 3228c3b3 8de37177 *
> > > > .../...2(qw*
> > > > 0020: a3e6e150 a3c5 0400ff00 050100
> > > > *...P...
> > > > *
> > > > 05/08/2014-16:46:27 Thd-0 INFO gsk_write_v3_record(): Calling write
> > > > routine for 52 bytes
> > > > 05/08/2014-16:46:27 Thd-0 INFO gsk_write_v3_record(): 52 bytes
> > > > written
> > > > 05/08/2014-16:46:27 Thd-0 INFO gsk_read_v3_record(): Calling read
> > > > routine for 5 bytes
> > > > 05/08/2014-16:46:27 Thd-0 INFO gsk_read_v3_record(): 5 bytes
> > > > received
> > > > 05/08/2014-16:46:27 Thd-0 ERROR gsk_read_v3_record(): Content Type
> > > > 50 is not supported
> > > > 05/08/2014-16:46:27 Thd-0 ASCII gsk_read_v3_record(): SSL record
> > header
> > > > : 3232302d 57 *220-W
> > > > *
> > > > 05/08/2014-16:46:27 Thd-0 ERROR gsk_secure_socket_init(): SSL V3
> > > > client handshake failed with 10.6.0.15[21]
> > > >
> > > >
> > > >
> > > > On Wed, May 7, 2014 at 4:03 PM, Gibney, Dave
> > wrote:
> > > >
> > > > > Add this to the FTP Client job parms:
> > > > > //
> > > >
> > PARM=('ENVAR("GSK_TRACE=0X","GSK_TRACE_FILE=/tmp/gskwix.trc")',
> > > > > //'/-r TLS (TRACE EXIT')
> > > > >
> > > > > There is a formatted documented with gsktrace. Should get you to
> > > > > the exact error when you format gskwix.trc
> > > > >
> > > > > > -Original Message-
> > > > > > From: IBM Mainframe Discussion List
> > > > > > [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Mark Post
> > > > > > Sent: Wednesday, May 07, 2014 12:55 PM
> > > > > > To: IBM-MAIN@LISTSERV.UA.EDU
> > > > > > Subject: Re: z/OS FTPS Client & Linux FTP server
> > > > > >
> > > > > > Mark,
> > > > > >
> > > > > > This may be yet another case where running strace or ltrace on
> > > > > > the server side will give you some insight into what is going
> > > > > > on. If you don't
> > > > > want to
Re: z/OS FTPS Client & Linux FTP server
Well, if your are doing the SSL server stuff, then the password is not flowing
in the clear. On the other hand, my interpretation of the vsftp parm I sent a
few days ago is to NOT do certificate based client authentication.
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Mark Pace
> Sent: Friday, May 09, 2014 9:19 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: z/OS FTPS Client & Linux FTP server
>
> Oh yes. We've been doing it that way for years.
>
> Trying to add the ability to secure the log in process.
>
>
> On Fri, May 9, 2014 at 11:42 AM, Gibney, Dave wrote:
>
> > I haven't used SSL client verification by certificate, so you are past
> > my knowledge. As an experiment, can you get a working connection using
> > userid/password authentication.
> >
> > > -Original Message-
> > > From: IBM Mainframe Discussion List
> > > [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Mark Pace
> > > Sent: Friday, May 09, 2014 5:47 AM
> > > To: IBM-MAIN@LISTSERV.UA.EDU
> > > Subject: Re: z/OS FTPS Client & Linux FTP server
> > >
> > > I was able to get the Trace to work - after removing the -r TLS,
> > > that generated an error.
> > > *EZA2892I Secure port 21 does not allow the -a or -r start parameter
> > > *
> > >
> > > And from that trace it appears, to me, that the FTP server is not
> > > responding correctly to the z/OS client handshake.
> > >
> > > 05/08/2014-16:46:27 Thd-0 INFO send_v3_client_hello(): Sent V3
> > > CLIENT- HELLO message
> > > 05/08/2014-16:46:27 Thd-0 ASCII send_v3_client_hello(): V3
> > > CLIENT-HELLO message
> > > : 012b 0301536b ed23cf50 8d72c5f7
> > > *...+..Sk.#.P.r..*
> > > 0010: 201c1c84 2fef8ce6 3228c3b3 8de37177 *
> > > .../...2(qw*
> > > 0020: a3e6e150 a3c5 0400ff00 050100
> > > *...P...
> > > *
> > > 05/08/2014-16:46:27 Thd-0 INFO gsk_write_v3_record(): Calling write
> > > routine for 52 bytes
> > > 05/08/2014-16:46:27 Thd-0 INFO gsk_write_v3_record(): 52 bytes
> > > written
> > > 05/08/2014-16:46:27 Thd-0 INFO gsk_read_v3_record(): Calling read
> > > routine for 5 bytes
> > > 05/08/2014-16:46:27 Thd-0 INFO gsk_read_v3_record(): 5 bytes
> > > received
> > > 05/08/2014-16:46:27 Thd-0 ERROR gsk_read_v3_record(): Content Type
> > > 50 is not supported
> > > 05/08/2014-16:46:27 Thd-0 ASCII gsk_read_v3_record(): SSL record
> header
> > > : 3232302d 57 *220-W
> > > *
> > > 05/08/2014-16:46:27 Thd-0 ERROR gsk_secure_socket_init(): SSL V3
> > > client handshake failed with 10.6.0.15[21]
> > >
> > >
> > >
> > > On Wed, May 7, 2014 at 4:03 PM, Gibney, Dave
> wrote:
> > >
> > > > Add this to the FTP Client job parms:
> > > > //
> > >
> PARM=('ENVAR("GSK_TRACE=0X","GSK_TRACE_FILE=/tmp/gskwix.trc")',
> > > > //'/-r TLS (TRACE EXIT')
> > > >
> > > > There is a formatted documented with gsktrace. Should get you to
> > > > the exact error when you format gskwix.trc
> > > >
> > > > > -Original Message-
> > > > > From: IBM Mainframe Discussion List
> > > > > [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Mark Post
> > > > > Sent: Wednesday, May 07, 2014 12:55 PM
> > > > > To: IBM-MAIN@LISTSERV.UA.EDU
> > > > > Subject: Re: z/OS FTPS Client & Linux FTP server
> > > > >
> > > > > Mark,
> > > > >
> > > > > This may be yet another case where running strace or ltrace on
> > > > > the server side will give you some insight into what is going
> > > > > on. If you don't
> > > > want to go
> > > > > down that road, i would say it's time to open up a PMR with IBM.
> > > > >
> > > > >
> > > > > Mark Post
> > > > >
> > > > >
> > > > > ---
> > > -
> > > > > -- For IBM-MAIN subscribe / signoff / archive access
> > > > > instructions, send
> > > > email to
> > > > > lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> > > >
Re: z/OS FTPS Client & Linux FTP server
Oh yes. We've been doing it that way for years.
Trying to add the ability to secure the log in process.
On Fri, May 9, 2014 at 11:42 AM, Gibney, Dave wrote:
> I haven't used SSL client verification by certificate, so you are past my
> knowledge. As an experiment, can you get a working connection using
> userid/password authentication.
>
> > -Original Message-
> > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> > On Behalf Of Mark Pace
> > Sent: Friday, May 09, 2014 5:47 AM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: z/OS FTPS Client & Linux FTP server
> >
> > I was able to get the Trace to work - after removing the -r TLS, that
> > generated an error.
> > *EZA2892I Secure port 21 does not allow the -a or -r start parameter *
> >
> > And from that trace it appears, to me, that the FTP server is not
> > responding correctly to the z/OS client handshake.
> >
> > 05/08/2014-16:46:27 Thd-0 INFO send_v3_client_hello(): Sent V3 CLIENT-
> > HELLO message
> > 05/08/2014-16:46:27 Thd-0 ASCII send_v3_client_hello(): V3 CLIENT-HELLO
> > message
> > : 012b 0301536b ed23cf50 8d72c5f7
> > *...+..Sk.#.P.r..*
> > 0010: 201c1c84 2fef8ce6 3228c3b3 8de37177 *
> > .../...2(qw*
> > 0020: a3e6e150 a3c5 0400ff00 050100
> > *...P...
> > *
> > 05/08/2014-16:46:27 Thd-0 INFO gsk_write_v3_record(): Calling write
> > routine for 52 bytes
> > 05/08/2014-16:46:27 Thd-0 INFO gsk_write_v3_record(): 52 bytes written
> > 05/08/2014-16:46:27 Thd-0 INFO gsk_read_v3_record(): Calling read
> > routine for 5 bytes
> > 05/08/2014-16:46:27 Thd-0 INFO gsk_read_v3_record(): 5 bytes received
> > 05/08/2014-16:46:27 Thd-0 ERROR gsk_read_v3_record(): Content Type 50
> > is not supported
> > 05/08/2014-16:46:27 Thd-0 ASCII gsk_read_v3_record(): SSL record header
> > : 3232302d 57 *220-W
> > *
> > 05/08/2014-16:46:27 Thd-0 ERROR gsk_secure_socket_init(): SSL V3 client
> > handshake failed with 10.6.0.15[21]
> >
> >
> >
> > On Wed, May 7, 2014 at 4:03 PM, Gibney, Dave wrote:
> >
> > > Add this to the FTP Client job parms:
> > > //
> > PARM=('ENVAR("GSK_TRACE=0X","GSK_TRACE_FILE=/tmp/gskwix.trc")',
> > > //'/-r TLS (TRACE EXIT')
> > >
> > > There is a formatted documented with gsktrace. Should get you to the
> > > exact error when you format gskwix.trc
> > >
> > > > -Original Message-
> > > > From: IBM Mainframe Discussion List
> > > > [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Mark Post
> > > > Sent: Wednesday, May 07, 2014 12:55 PM
> > > > To: IBM-MAIN@LISTSERV.UA.EDU
> > > > Subject: Re: z/OS FTPS Client & Linux FTP server
> > > >
> > > > Mark,
> > > >
> > > > This may be yet another case where running strace or ltrace on the
> > > > server side will give you some insight into what is going on. If
> > > > you don't
> > > want to go
> > > > down that road, i would say it's time to open up a PMR with IBM.
> > > >
> > > >
> > > > Mark Post
> > > >
> > > > ---
> > -
> > > > -- For IBM-MAIN subscribe / signoff / archive access instructions,
> > > > send
> > > email to
> > > > lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> > >
> > > -
> > -
> > > For IBM-MAIN subscribe / signoff / archive access instructions, send
> > > email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> > >
> >
> >
> >
> > --
> > The postings on this site are my own and don’t necessarily represent
> > Mainline’s positions or opinions
> >
> > Mark D Pace
> > Senior Systems Engineer
> > Mainline Information Systems
> >
> > --
> > For IBM-MAIN subscribe / signoff / archive access instructions, send
> > email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
--
The postings on this site are my own and don’t necessarily represent
Mainline’s positions or opinions
Mark D Pace
Senior Systems Engineer
Mainline Information Systems
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS FTPS Client & Linux FTP server
I haven't used SSL client verification by certificate, so you are past my
knowledge. As an experiment, can you get a working connection using
userid/password authentication.
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Mark Pace
> Sent: Friday, May 09, 2014 5:47 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: z/OS FTPS Client & Linux FTP server
>
> I was able to get the Trace to work - after removing the -r TLS, that
> generated an error.
> *EZA2892I Secure port 21 does not allow the -a or -r start parameter *
>
> And from that trace it appears, to me, that the FTP server is not
> responding correctly to the z/OS client handshake.
>
> 05/08/2014-16:46:27 Thd-0 INFO send_v3_client_hello(): Sent V3 CLIENT-
> HELLO message
> 05/08/2014-16:46:27 Thd-0 ASCII send_v3_client_hello(): V3 CLIENT-HELLO
> message
> : 012b 0301536b ed23cf50 8d72c5f7
> *...+..Sk.#.P.r..*
> 0010: 201c1c84 2fef8ce6 3228c3b3 8de37177 *
> .../...2(qw*
> 0020: a3e6e150 a3c5 0400ff00 050100
> *...P...
> *
> 05/08/2014-16:46:27 Thd-0 INFO gsk_write_v3_record(): Calling write
> routine for 52 bytes
> 05/08/2014-16:46:27 Thd-0 INFO gsk_write_v3_record(): 52 bytes written
> 05/08/2014-16:46:27 Thd-0 INFO gsk_read_v3_record(): Calling read
> routine for 5 bytes
> 05/08/2014-16:46:27 Thd-0 INFO gsk_read_v3_record(): 5 bytes received
> 05/08/2014-16:46:27 Thd-0 ERROR gsk_read_v3_record(): Content Type 50
> is not supported
> 05/08/2014-16:46:27 Thd-0 ASCII gsk_read_v3_record(): SSL record header
> : 3232302d 57 *220-W
> *
> 05/08/2014-16:46:27 Thd-0 ERROR gsk_secure_socket_init(): SSL V3 client
> handshake failed with 10.6.0.15[21]
>
>
>
> On Wed, May 7, 2014 at 4:03 PM, Gibney, Dave wrote:
>
> > Add this to the FTP Client job parms:
> > //
> PARM=('ENVAR("GSK_TRACE=0X","GSK_TRACE_FILE=/tmp/gskwix.trc")',
> > //'/-r TLS (TRACE EXIT')
> >
> > There is a formatted documented with gsktrace. Should get you to the
> > exact error when you format gskwix.trc
> >
> > > -----Original Message-----
> > > From: IBM Mainframe Discussion List
> > > [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Mark Post
> > > Sent: Wednesday, May 07, 2014 12:55 PM
> > > To: IBM-MAIN@LISTSERV.UA.EDU
> > > Subject: Re: z/OS FTPS Client & Linux FTP server
> > >
> > > Mark,
> > >
> > > This may be yet another case where running strace or ltrace on the
> > > server side will give you some insight into what is going on. If
> > > you don't
> > want to go
> > > down that road, i would say it's time to open up a PMR with IBM.
> > >
> > >
> > > Mark Post
> > >
> > > ---
> -
> > > -- For IBM-MAIN subscribe / signoff / archive access instructions,
> > > send
> > email to
> > > lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> >
> > -
> -
> > For IBM-MAIN subscribe / signoff / archive access instructions, send
> > email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> >
>
>
>
> --
> The postings on this site are my own and don’t necessarily represent
> Mainline’s positions or opinions
>
> Mark D Pace
> Senior Systems Engineer
> Mainline Information Systems
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send
> email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS FTPS Client & Linux FTP server
ead_v3_record(): Content Type 50 is
> >> not supported
> >> 05/08/2014-16:46:27 Thd-0 ASCII gsk_read_v3_record(): SSL record
> >> header
> >> : 3232302d 57 *220-W
> >> *
> >> 05/08/2014-16:46:27 Thd-0 ERROR gsk_secure_socket_init(): SSL V3 client
> >> handshake failed with 10.6.0.15[21]
> >>
> >>
> >>
> >> On Wed, May 7, 2014 at 4:03 PM, Gibney, Dave wrote:
> >>
> >> > Add this to the FTP Client job parms:
> >> > //
> PARM=('ENVAR("GSK_TRACE=0X","GSK_TRACE_FILE=/tmp/gskwix.trc")',
> >> > //'/-r TLS (TRACE EXIT')
> >> >
> >> > There is a formatted documented with gsktrace. Should get you to the
> >> exact
> >> > error when you format gskwix.trc
> >> >
> >> > > -Original Message-
> >> > > From: IBM Mainframe Discussion List [mailto:
> IBM-MAIN@LISTSERV.UA.EDU]
> >> > > On Behalf Of Mark Post
> >> > > Sent: Wednesday, May 07, 2014 12:55 PM
> >> > > To: IBM-MAIN@LISTSERV.UA.EDU
> >> > > Subject: Re: z/OS FTPS Client & Linux FTP server
> >> > >
> >> > > Mark,
> >> > >
> >> > > This may be yet another case where running strace or ltrace on the
> >> server
> >> > > side will give you some insight into what is going on. If you don't
> >> > want to go
> >> > > down that road, i would say it's time to open up a PMR with IBM.
> >> > >
> >> > >
> >> > > Mark Post
> >> > >
> >> > >
> --
> >> > > For IBM-MAIN subscribe / signoff / archive access instructions, send
> >> > email to
> >> > > lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> >> >
> >> > --
> >> > For IBM-MAIN subscribe / signoff / archive access instructions,
> >> > send email to lists...@listserv.ua.edu with the message: INFO
> IBM-MAIN
> >> >
> >>
> >>
> >>
> >> --
> >> The postings on this site are my own and don’t necessarily represent
> >> Mainline’s positions or opinions
> >>
> >> Mark D Pace
> >> Senior Systems Engineer
> >> Mainline Information Systems
> >>
> >> --
> >> For IBM-MAIN subscribe / signoff / archive access instructions,
> >> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> >>
> >
> >
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
--
The postings on this site are my own and don’t necessarily represent
Mainline’s positions or opinions
Mark D Pace
Senior Systems Engineer
Mainline Information Systems
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS FTPS Client & Linux FTP server
I did a quick search and the error seems like a TLS 1.0 only issue.
As I remember it, the FTP TLS on z/OS is restricted to TLS 1.0 with IBM
stating something like
"please use AT-TLS... we are done putting work into task specific TLS
implementations"
AT-TLS provides support for a wider ranges of TLS levels. It isn't too
much work to get operating for FTP. Don't take the redbooks advice when
creating rules... the writer succeeded in making it more complicated. Copy
an existing rule for FTP.
The key is setting up the client rule not the server rule
the SYSFTPD - FTPCDATA
TLSMECHANISM ATTLS
secure_mechanism tls
secure_ctrlconn private
secure_dataconn private
epsv4 true
TLSRFCLEVEL RFC4217
secure_ftprequired
extensionsauth_tls
secure_pbsz 32768
You'll need PAGENT and
Obey this for TCPIP
TCPCONFIG TCPSENDBFRSIZE 32K TCPRCVBUFRSIZE 32K SENDGARBAGE FALSE TTLS
If you are after z/OS 1.13.. then the stand alone Config Assistant is not
available.. and the z/OSMF must be used. I would not recommend hand coding
Policy Agent Rules.
Rob Schramm
Rob Schramm
Senior Systems Consultant
Imperium Group
On Fri, May 9, 2014 at 9:06 AM, Rob Schramm wrote:
> Sorry.. was doing my post via phone..
>
> Here is the short version of GSKSRVR trace
>
> Run a GSKSRVR for SSL trace.. the only gotcha is that it must come up
> before the task you want to trace.
>
> - S GSKSRVR
> - Restart STC
> - Update GSKWTR PROC to add a dataset to hold the trace.
> - TRACE CT,WTRSTART=GSKWTR
> - TRACE CT,ON,COMP=GSKSRVR
> - R n,JOBNAME=(yyy),OPTIONS=(LEVEL=255),WTR=GSKWTR,END where yyy is the
> name of STC.
> - Recreate the problem.
> - TRACE CT,OFF,COMP=GSKSRVR
> - TRACE CT,WTRSTOP=GSKWTR
> - get into IPCS
> - update 0 DEFAULTS - Specify default dump and options with GSKWTR
> produced trace data set
> - 2 ANALYSIS - Analyze dump contents
> - 7 TRACES - Trace formatting
> - 1 CTRACE - Component trace
> - D DISPLAY - Specify parameters to display CTRACE entries
> - update "Component" with "GSKSRVR", update "Report type" with "full", and
> issue "S" to start the analysis
>
> GSKSRVR Commands#
>
> - S GSKSRVR
> - F GSKSRVR,DISPLAY CRYPTO
> - F GSKSRVR,DISPLAY LEVEL
> - F GSKSRVR,DISPLAY SIDCACHE
> - F GSKSRVR,DISPLAY XCF
> - F GSKSRVR,STOP
>
> Rob Schramm
>
> Rob Schramm
> Senior Systems Consultant
> Imperium Group
>
>
>
> On Fri, May 9, 2014 at 8:46 AM, Mark Pace wrote:
>
>> I was able to get the Trace to work - after removing the -r TLS, that
>> generated an error.
>> *EZA2892I Secure port 21 does not allow the -a or -r start parameter *
>>
>> And from that trace it appears, to me, that the FTP server is not
>> responding correctly to the z/OS client handshake.
>>
>> 05/08/2014-16:46:27 Thd-0 INFO send_v3_client_hello(): Sent V3
>> CLIENT-HELLO
>> message
>> 05/08/2014-16:46:27 Thd-0 ASCII send_v3_client_hello(): V3 CLIENT-HELLO
>> message
>> : 012b 0301536b ed23cf50 8d72c5f7
>> *...+..Sk.#.P.r..*
>> 0010: 201c1c84 2fef8ce6 3228c3b3 8de37177 *
>> .../...2(qw*
>> 0020: a3e6e150 a3c5 0400ff00 050100*...P...
>> *
>> 05/08/2014-16:46:27 Thd-0 INFO gsk_write_v3_record(): Calling write
>> routine
>> for 52 bytes
>> 05/08/2014-16:46:27 Thd-0 INFO gsk_write_v3_record(): 52 bytes
>> written
>> 05/08/2014-16:46:27 Thd-0 INFO gsk_read_v3_record(): Calling read routine
>> for 5 bytes
>> 05/08/2014-16:46:27 Thd-0 INFO gsk_read_v3_record(): 5 bytes
>> received
>> 05/08/2014-16:46:27 Thd-0 ERROR gsk_read_v3_record(): Content Type 50 is
>> not supported
>> 05/08/2014-16:46:27 Thd-0 ASCII gsk_read_v3_record(): SSL record
>> header
>> : 3232302d 57 *220-W
>> *
>> 05/08/2014-16:46:27 Thd-0 ERROR gsk_secure_socket_init(): SSL V3 client
>> handshake failed with 10.6.0.15[21]
>>
>>
>>
>> On Wed, May 7, 2014 at 4:03 PM, Gibney, Dave wrote:
>>
>> > Add this to the FTP Client job parms:
>> > // PARM=('ENVAR("GSK_TRACE=0X","GSK_TRACE_FILE=/tmp/gskwix.trc")',
>> > //'/-r TLS (TRACE EXIT')
>> >
>> > There is a formatted documented with gsktrace. Should get you to the
>> exact
>> > error when you format gskwix.trc
>> >
>> > > -Original Message-
>> > > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
>> > > On Behalf Of Mark Post
>> > > Sent: Wednesday, May 07, 2014 12:55 PM
Re: z/OS FTPS Client & Linux FTP server
Sorry.. was doing my post via phone..
Here is the short version of GSKSRVR trace
Run a GSKSRVR for SSL trace.. the only gotcha is that it must come up
before the task you want to trace.
- S GSKSRVR
- Restart STC
- Update GSKWTR PROC to add a dataset to hold the trace.
- TRACE CT,WTRSTART=GSKWTR
- TRACE CT,ON,COMP=GSKSRVR
- R n,JOBNAME=(yyy),OPTIONS=(LEVEL=255),WTR=GSKWTR,END where yyy is the
name of STC.
- Recreate the problem.
- TRACE CT,OFF,COMP=GSKSRVR
- TRACE CT,WTRSTOP=GSKWTR
- get into IPCS
- update 0 DEFAULTS - Specify default dump and options with GSKWTR produced
trace data set
- 2 ANALYSIS - Analyze dump contents
- 7 TRACES - Trace formatting
- 1 CTRACE - Component trace
- D DISPLAY - Specify parameters to display CTRACE entries
- update "Component" with "GSKSRVR", update "Report type" with "full", and
issue "S" to start the analysis
GSKSRVR Commands#
- S GSKSRVR
- F GSKSRVR,DISPLAY CRYPTO
- F GSKSRVR,DISPLAY LEVEL
- F GSKSRVR,DISPLAY SIDCACHE
- F GSKSRVR,DISPLAY XCF
- F GSKSRVR,STOP
Rob Schramm
Rob Schramm
Senior Systems Consultant
Imperium Group
On Fri, May 9, 2014 at 8:46 AM, Mark Pace wrote:
> I was able to get the Trace to work - after removing the -r TLS, that
> generated an error.
> *EZA2892I Secure port 21 does not allow the -a or -r start parameter *
>
> And from that trace it appears, to me, that the FTP server is not
> responding correctly to the z/OS client handshake.
>
> 05/08/2014-16:46:27 Thd-0 INFO send_v3_client_hello(): Sent V3 CLIENT-HELLO
> message
> 05/08/2014-16:46:27 Thd-0 ASCII send_v3_client_hello(): V3 CLIENT-HELLO
> message
> : 012b 0301536b ed23cf50 8d72c5f7
> *...+..Sk.#.P.r..*
> 0010: 201c1c84 2fef8ce6 3228c3b3 8de37177 *
> .../...2(qw*
> 0020: a3e6e150 a3c5 0400ff00 050100*...P...
> *
> 05/08/2014-16:46:27 Thd-0 INFO gsk_write_v3_record(): Calling write routine
> for 52 bytes
> 05/08/2014-16:46:27 Thd-0 INFO gsk_write_v3_record(): 52 bytes
> written
> 05/08/2014-16:46:27 Thd-0 INFO gsk_read_v3_record(): Calling read routine
> for 5 bytes
> 05/08/2014-16:46:27 Thd-0 INFO gsk_read_v3_record(): 5 bytes
> received
> 05/08/2014-16:46:27 Thd-0 ERROR gsk_read_v3_record(): Content Type 50 is
> not supported
> 05/08/2014-16:46:27 Thd-0 ASCII gsk_read_v3_record(): SSL record
> header
> : 3232302d 57 *220-W
> *
> 05/08/2014-16:46:27 Thd-0 ERROR gsk_secure_socket_init(): SSL V3 client
> handshake failed with 10.6.0.15[21]
>
>
>
> On Wed, May 7, 2014 at 4:03 PM, Gibney, Dave wrote:
>
> > Add this to the FTP Client job parms:
> > // PARM=('ENVAR("GSK_TRACE=0X","GSK_TRACE_FILE=/tmp/gskwix.trc")',
> > //'/-r TLS (TRACE EXIT')
> >
> > There is a formatted documented with gsktrace. Should get you to the
> exact
> > error when you format gskwix.trc
> >
> > > -----Original Message-
> > > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> > > On Behalf Of Mark Post
> > > Sent: Wednesday, May 07, 2014 12:55 PM
> > > To: IBM-MAIN@LISTSERV.UA.EDU
> > > Subject: Re: z/OS FTPS Client & Linux FTP server
> > >
> > > Mark,
> > >
> > > This may be yet another case where running strace or ltrace on the
> server
> > > side will give you some insight into what is going on. If you don't
> > want to go
> > > down that road, i would say it's time to open up a PMR with IBM.
> > >
> > >
> > > Mark Post
> > >
> > > --
> > > For IBM-MAIN subscribe / signoff / archive access instructions, send
> > email to
> > > lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> >
> > --
> > For IBM-MAIN subscribe / signoff / archive access instructions,
> > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> >
>
>
>
> --
> The postings on this site are my own and don’t necessarily represent
> Mainline’s positions or opinions
>
> Mark D Pace
> Senior Systems Engineer
> Mainline Information Systems
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS FTPS Client & Linux FTP server
I was able to get the Trace to work - after removing the -r TLS, that
generated an error.
*EZA2892I Secure port 21 does not allow the -a or -r start parameter *
And from that trace it appears, to me, that the FTP server is not
responding correctly to the z/OS client handshake.
05/08/2014-16:46:27 Thd-0 INFO send_v3_client_hello(): Sent V3 CLIENT-HELLO
message
05/08/2014-16:46:27 Thd-0 ASCII send_v3_client_hello(): V3 CLIENT-HELLO
message
: 012b 0301536b ed23cf50 8d72c5f7
*...+..Sk.#.P.r..*
0010: 201c1c84 2fef8ce6 3228c3b3 8de37177 *
.../...2(qw*
0020: a3e6e150 a3c5 0400ff00 050100*...P...
*
05/08/2014-16:46:27 Thd-0 INFO gsk_write_v3_record(): Calling write routine
for 52 bytes
05/08/2014-16:46:27 Thd-0 INFO gsk_write_v3_record(): 52 bytes
written
05/08/2014-16:46:27 Thd-0 INFO gsk_read_v3_record(): Calling read routine
for 5 bytes
05/08/2014-16:46:27 Thd-0 INFO gsk_read_v3_record(): 5 bytes
received
05/08/2014-16:46:27 Thd-0 ERROR gsk_read_v3_record(): Content Type 50 is
not supported
05/08/2014-16:46:27 Thd-0 ASCII gsk_read_v3_record(): SSL record
header
: 3232302d 57 *220-W
*
05/08/2014-16:46:27 Thd-0 ERROR gsk_secure_socket_init(): SSL V3 client
handshake failed with 10.6.0.15[21]
On Wed, May 7, 2014 at 4:03 PM, Gibney, Dave wrote:
> Add this to the FTP Client job parms:
> // PARM=('ENVAR("GSK_TRACE=0X","GSK_TRACE_FILE=/tmp/gskwix.trc")',
> //'/-r TLS (TRACE EXIT')
>
> There is a formatted documented with gsktrace. Should get you to the exact
> error when you format gskwix.trc
>
> > -Original Message-
> > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> > On Behalf Of Mark Post
> > Sent: Wednesday, May 07, 2014 12:55 PM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: z/OS FTPS Client & Linux FTP server
> >
> > Mark,
> >
> > This may be yet another case where running strace or ltrace on the server
> > side will give you some insight into what is going on. If you don't
> want to go
> > down that road, i would say it's time to open up a PMR with IBM.
> >
> >
> > Mark Post
> >
> > --
> > For IBM-MAIN subscribe / signoff / archive access instructions, send
> email to
> > lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
--
The postings on this site are my own and don’t necessarily represent
Mainline’s positions or opinions
Mark D Pace
Senior Systems Engineer
Mainline Information Systems
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS FTPS Client & Linux FTP server
The root cert is all that should be needed on the z/OS side, if linux side is set up correctly. But as mentioned in my last email, it doesn't look like the linux side cert file is complete. Your server cert is issued by a GoDaddy intermediate cert, which is issued by a GoDaddy root cert. I would guess your linux file only has the server cert in it, and it needs the intermediate cert in it as well, and optionally the root cert. -- Donald J. dona...@4email.net On Thu, May 8, 2014, at 07:31 AM, Mark Pace wrote: > I assume it's complete - I don't see an obvious error. -- http://www.fastmail.fm - One of many happy users: http://www.fastmail.fm/help/overview_quotes.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS FTPS Client & Linux FTP server
I assume it's complete - I don't see an obvious error.
Digital certificate information for
CERTAUTH:
Label: Go Daddy Class
2
Certificate ID:
2QiJmZmDhZmjgceWQMSBhISoQMOTgaKiQPJA
Status:
TRUST
Start Date: 2004/06/29
13:06:20
End Date: 2034/06/29
13:06:20
Serial
Number:
>00<
Issuer's
Name:
>OU=Go Daddy Class 2 Certification Authority.O=The Go Daddy Group,
Inc<
>..C=US<
Subject's
Name:
>OU=Go Daddy Class 2 Certification Authority.O=The Go Daddy Group,
Inc<
>..C=US<
Signing Algorithm:
sha1RSA
Key Type:
RSA
Key Size:
2048
Private Key:
NO
Ring
Associations:
Ring Owner:
TN3270
Ring:
>TNRING<
Ring Owner:
IBMUSER
Ring:
>FtpSecur<
Wow - that SEARCH CLASS(DIGTCERT) spewed out a lot of stuff. I'm not
sure what I was looking for on a cursory glance. I'll have to study that
one closer.
Question - The certificate on my FTP server was issued by Go Daddy, On my
z/OS system (Client) is all I need the Go Daddy root authority certificate
- or do I need to generate a public key from my FTP server and send to z/OS
to include in a ring?
On Wed, May 7, 2014 at 6:38 PM, Neubert, Kevin
wrote:
> Is the chain complete? Check trust and Issuer's/Subject's Names.
> RACDCERT LIST(LABEL('Go Daddy Class 2')) CERTAUTH. Do you have all the
> names? SEARCH CLASS(DIGTCERT).
>
> Regards,
>
> Kevin
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Mark Pace
> Sent: Wednesday, May 07, 2014 1:01 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: z/OS FTPS Client & Linux FTP server
>
> Yes, I did the digtcert refresh
> Digital ring information for user IBMUSER:
>
>Ring:
> >FtpSecur<
>Certificate Label Name Cert Owner USAGE DEFAULT
> ---
>GeoTrust Global CA CERTAUTH CERTAUTH NO
>Go Daddy Class 2 CERTAUTH CERTAUTH YES
>
> ***
>
> No ICH408I errors.
>
>
>
> On Wed, May 7, 2014 at 3:27 PM, Donald J. wrote:
>
> > You did do a:
> > SETROPTS RACLIST(DIGTCERT) REFRESH
> > after last changing the keyring?
> >
> > What does the LISTRING show now?
> >
> > Does the userid submitting the batch job have any ICH408I errors in
> > the log?
> >
> > --
> > Donald J.
> >
> >
> > --
> > http://www.fastmail.fm - Send your email first class
> >
> > --
> > For IBM-MAIN subscribe / signoff / archive access instructions, send
> > email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> >
>
>
>
> --
> The postings on this site are my own and don’t necessarily represent
> Mainline’s positions or opinions
>
> Mark D Pace
> Senior Systems Engineer
> Mainline Information Systems
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send email
> to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
--
The postings on this site are my own and don’t necessarily represent
Mainline’s positions or opinions
Mark D Pace
Senior Systems Engineer
Mainline Information Systems
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS FTPS Client & Linux FTP server
Kevin is right about the complete chain.
I issued this openssl command:
openssl s_client -connect ftp.s390.mainline.com:21 -starttls ftp -tls1
-CAfile gd-class2-root.crt
and got error:
Verify return code: 21 (unable to verify the first certificate)
I created a cacerts file with both the intermediate and root cert:
copy gd_intermediate.crt+gd-class2-root.crt daddy.cacerts.crt
Then I got code 0 with:
openssl s_client -connect ftp.s390.mainline.com:21 -starttls ftp -tls1
-CAfile daddy.cacerts.crt
So your rsa_cert_file=/etc/vsftpd/mainline-wc-2011.crt file probably
does not have the chain
of 3 certs in it: They should be stacked in the file as follows:
-BEGIN CERTIFICATE-
mainline server cert
-END CERTIFICATE-
-BEGIN CERTIFICATE-
gd_intermediate.crt cert
-END CERTIFICATE-
-BEGIN CERTIFICATE-
gd-class2-root.crt cert
-END CERTIFICATE-
Filezilla is not a good program to test with, as it appears to not do
server cert
authenticatation. It is better to use curl for windows or curl for
z/OS.
--
Donald J.
dona...@4email.net
On Wed, May 7, 2014, at 03:38 PM, Neubert, Kevin wrote:
> Is the chain complete? Check trust and Issuer's/Subject's Names.
> RACDCERT LIST(LABEL('Go Daddy Class 2')) CERTAUTH. Do you have all the
> names? SEARCH CLASS(DIGTCERT).
>
> Regards,
>
> Kevin
>
>
>Ring:
> >FtpSecur<
>Certificate Label Name Cert Owner USAGE DEFAULT
> ---
>GeoTrust Global CA CERTAUTH CERTAUTH NO
>Go Daddy Class 2 CERTAUTH CERTAUTH YES
--
http://www.fastmail.fm - Choose from over 50 domains or use your own
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS FTPS Client & Linux FTP server
Is the chain complete? Check trust and Issuer's/Subject's Names. RACDCERT
LIST(LABEL('Go Daddy Class 2')) CERTAUTH. Do you have all the names? SEARCH
CLASS(DIGTCERT).
Regards,
Kevin
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Mark Pace
Sent: Wednesday, May 07, 2014 1:01 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: z/OS FTPS Client & Linux FTP server
Yes, I did the digtcert refresh
Digital ring information for user IBMUSER:
Ring:
>FtpSecur<
Certificate Label Name Cert Owner USAGE DEFAULT
---
GeoTrust Global CA CERTAUTH CERTAUTH NO
Go Daddy Class 2 CERTAUTH CERTAUTH YES
***
No ICH408I errors.
On Wed, May 7, 2014 at 3:27 PM, Donald J. wrote:
> You did do a:
> SETROPTS RACLIST(DIGTCERT) REFRESH
> after last changing the keyring?
>
> What does the LISTRING show now?
>
> Does the userid submitting the batch job have any ICH408I errors in
> the log?
>
> --
> Donald J.
>
>
> --
> http://www.fastmail.fm - Send your email first class
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send
> email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
--
The postings on this site are my own and don’t necessarily represent Mainline’s
positions or opinions
Mark D Pace
Senior Systems Engineer
Mainline Information Systems
--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to
lists...@listserv.ua.edu with the message: INFO IBM-MAIN
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS FTPS Client & Linux FTP server
You need to change that to DEFAULT NO. -- Donald J. dona...@4email.net On Wed, May 7, 2014, at 01:01 PM, Mark Pace wrote: > Yes, I did the digtcert refresh > Digital ring information for user IBMUSER: > >Ring: > >FtpSecur< >Certificate Label Name Cert Owner USAGE DEFAULT > --- >GeoTrust Global CA CERTAUTH CERTAUTH NO >Go Daddy Class 2 CERTAUTH CERTAUTH YES > > *** > > No ICH408I errors. > > > > On Wed, May 7, 2014 at 3:27 PM, Donald J. wrote: > > > You did do a: > > SETROPTS RACLIST(DIGTCERT) REFRESH > > after last changing the keyring? > > > > What does the LISTRING show now? > > > > Does the userid submitting the batch job have any ICH408I > > errors in the log? > > > > -- > > Donald J. > > > > > > -- > > http://www.fastmail.fm - Send your email first class > > > > -- > > For IBM-MAIN subscribe / signoff / archive access instructions, > > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > > > > > -- > The postings on this site are my own and don’t necessarily represent > Mainline’s positions or opinions > > Mark D Pace > Senior Systems Engineer > Mainline Information Systems > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- http://www.fastmail.fm - Or how I learned to stop worrying and love email again -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS FTPS Client & Linux FTP server
Thank you. I will give that a try tomorrow. Today - my brain hurts. :)
On Wed, May 7, 2014 at 4:03 PM, Gibney, Dave wrote:
> Add this to the FTP Client job parms:
> // PARM=('ENVAR("GSK_TRACE=0X","GSK_TRACE_FILE=/tmp/gskwix.trc")',
> //'/-r TLS (TRACE EXIT')
>
> There is a formatted documented with gsktrace. Should get you to the exact
> error when you format gskwix.trc
>
> > -Original Message-
> > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> > On Behalf Of Mark Post
> > Sent: Wednesday, May 07, 2014 12:55 PM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: z/OS FTPS Client & Linux FTP server
> >
> > Mark,
> >
> > This may be yet another case where running strace or ltrace on the server
> > side will give you some insight into what is going on. If you don't
> want to go
> > down that road, i would say it's time to open up a PMR with IBM.
> >
> >
> > Mark Post
> >
> > --
> > For IBM-MAIN subscribe / signoff / archive access instructions, send
> email to
> > lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
--
The postings on this site are my own and don’t necessarily represent
Mainline’s positions or opinions
Mark D Pace
Senior Systems Engineer
Mainline Information Systems
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS FTPS Client & Linux FTP server
Add this to the FTP Client job parms:
// PARM=('ENVAR("GSK_TRACE=0X","GSK_TRACE_FILE=/tmp/gskwix.trc")',
//'/-r TLS (TRACE EXIT')
There is a formatted documented with gsktrace. Should get you to the exact
error when you format gskwix.trc
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Mark Post
> Sent: Wednesday, May 07, 2014 12:55 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: z/OS FTPS Client & Linux FTP server
>
> Mark,
>
> This may be yet another case where running strace or ltrace on the server
> side will give you some insight into what is going on. If you don't want to
> go
> down that road, i would say it's time to open up a PMR with IBM.
>
>
> Mark Post
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send email to
> lists...@listserv.ua.edu with the message: INFO IBM-MAIN
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS FTPS Client & Linux FTP server
Yes, I did the digtcert refresh
Digital ring information for user IBMUSER:
Ring:
>FtpSecur<
Certificate Label Name Cert Owner USAGE DEFAULT
---
GeoTrust Global CA CERTAUTH CERTAUTH NO
Go Daddy Class 2 CERTAUTH CERTAUTH YES
***
No ICH408I errors.
On Wed, May 7, 2014 at 3:27 PM, Donald J. wrote:
> You did do a:
> SETROPTS RACLIST(DIGTCERT) REFRESH
> after last changing the keyring?
>
> What does the LISTRING show now?
>
> Does the userid submitting the batch job have any ICH408I
> errors in the log?
>
> --
> Donald J.
>
>
> --
> http://www.fastmail.fm - Send your email first class
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
--
The postings on this site are my own and don’t necessarily represent
Mainline’s positions or opinions
Mark D Pace
Senior Systems Engineer
Mainline Information Systems
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS FTPS Client & Linux FTP server
Mark, This may be yet another case where running strace or ltrace on the server side will give you some insight into what is going on. If you don't want to go down that road, i would say it's time to open up a PMR with IBM. Mark Post -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS FTPS Client & Linux FTP server
I see you have pasv_enable=yes I think there's a setting in z/OS parms maybe related. EPSV4 True On 5/7/2014 3:36 PM, Mark Pace wrote: I had looked at that also. The vsftpd config - comments removed for brevity. listen=YES max_clients=20 use_localtime=YES log_ftp_protocol=YES # enable FTPS ssl_enable=YES allow_anon_ssl=NO force_local_data_ssl=NO force_local_logins_ssl=NO ssl_tlsv1=YES ssl_sslv2=NO ssl_sslv3=NO ssl_request_cert=NO rsa_cert_file=/etc/vsftpd/mainline-wc-2011.crt rsa_private_key_file=/etc/vsftpd/mainline-wc-2011.key ssl_ciphers=RC4-SHA debug_ssl=YES anonymous_enable=NO local_enable=YES write_enable=YES local_umask=022 anon_umask=666 anon_upload_enable=NO dirmessage_enable=YES message_file=.message xferlog_enable=YES connect_from_port_20=YES xferlog_file=/var/log/vsftpd.log banner_file=/etc/vsftpd.banner deny_email_enable=YES banned_email_file=/etc/vsftpd.banned_emails chroot_local_user=YES pasv_enable=YES listen_ipv6=NO On Wed, May 7, 2014 at 3:20 PM, Gibney, Dave wrote: I am now reminded of a difficulty I had with this once. My plea to the list(s) resulted in this: Skip to site navigation (Press enter) Re: FTP TLS Handshake Fails with SSL RC 410 Cal McCracken Thu, 10 Mar 2011 07:44:54 -0800 Thanks to a private responder, I was able to get this resolved. I don't know if the SSL RC 410 covers other error situations, but in my case, the resolution was to set configuration parm, ssl_request_cert to NO (defaults to YES). This is a config parm for the vsftpd FTP server on our Linux system. My humble thanks to the responder. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Mark Pace Sent: Wednesday, May 07, 2014 12:02 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: z/OS FTPS Client & Linux FTP server And for giggles I setup another Linux FTP server - this one pure-ftpd - again no issues connecting with a windows FTPS client - still no connection with z/OS. On Wed, May 7, 2014 at 2:39 PM, Mark Pace wrote: Yes - it was at that time. Since I started working on the RACF certs/keyring stuff the ftp.data has been updated as I go along. Currently. SECURE_CTRLCONN CLEAR SECURE_DATACONN PRIVATE SECURE_FTP REQUIRED SECURE_HOSTNAME OPTIONAL SECURE_MECHANISM TLS KEYRING IBMUSER/FtpSecur TLSPORT 21 TLSRFCLEVEL CCCNONOTIFY TLSTIMEOUT 10 ; ;CTRLCONN 7BIT SECUREIMPLICITZOS FALSE TLSMECHANISM FTP CIPHERSUITE SSL_RC4_SHA ; DEBUG SEC On Wed, May 7, 2014 at 2:06 PM, Gibney, Dave wrote: You said latest, so maybe you have tried others. In the parms listed here, your keyring is commented out. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Mark Pace Sent: Wednesday, May 07, 2014 5:26 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: z/OS FTPS Client & Linux FTP server Has anyone successfully sent data to a Linux FTP server using TLS security from the z/OS FTP client? I have a Linux server running vsftpd - I've been using it for years to send SMF data. I've added TLS support to this server. I've verified that the Secure connect works via a Filezilla client, So now I would like to be able to send SMF data to the server. But I always get an authentication failure. I've tried every combination of Security parameters I can come up with. These are the latest parms in my ftp.data file. ;SECURE_CTRLCONN SAFE SECURE_DATACONN CLEAR SECURE_FTP REQUIRED SECURE_HOSTNAME OPTIONAL SECURE_MECHANISM TLS SECUREIMPLICITZOS FALSE CIPHERSUITE SSL_RC4_SHA ;KEYRING IBMUSER/SecureFTPKeyRing TLSPORT 21 TLSRFCLEVEL CCCNONOTIFY TLSTIMEOUT 10 ;SECURE_PBSZ 16384 ; ;CTRLCONN 7BIT I'm beginning to think I am doing something fundamentally wrong instead of it being a matter of wrong parameters. //FTP EXEC PGM=FTP,REGION=5M,PARM='(EXIT' //SYSPRINT DD SYSOUT=* //SYSFTPD DD DISP=SHR,DSN=MARPACE.JCL.CNTL(FTPSDATA) //OUTPUTDD SYSOUT=* //INPUT DD * USE LOWER CASE BELOW ftp.s390.mainline.com userid password dir quit EZA1736I FTP (EXIT EZY2640I Using dd:SYSFTPD=MARPACE.JCL.CNTL(FTPSDATA) for local site configuration parameters. EZA1450I IBM FTP CS V2R1 EZA1772I FTP: EXIT has been set. EZA1456I Connect to ? EZA1736I ftp.s390.mainline.com EZA1554I Connecting to: ftp.s390.mainline.com 10.6.0.10 port: 21. EZA2897I Authentication negotiation failed EZA2898I Unable to successfully negotiate required authentication EZA1735I Std Return Code = 1, Error Code = 00017 -- The postings on this site are my own and don’t necessarily represent Mainline’s positions or opinions Mark D Pace Senior Systems Engineer Mainline Information Systems --- --- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lis
Re: z/OS FTPS Client & Linux FTP server
Hi, Mark - That is contained in the ftp.data file DD name SYSFTPD. In this case the DSN is MARPACE.JCL.CNTL(FTPSDATA) which contains SECURE_CTRLCONN CLEAR SECURE_DATACONN PRIVATE SECURE_FTP REQUIRED SECURE_HOSTNAME OPTIONAL SECURE_MECHANISM TLS KEYRING IBMUSER/FtpSecur TLSPORT 21 TLSRFCLEVEL CCCNONOTIFY TLSTIMEOUT 10 ; ;CTRLCONN 7BIT SECUREIMPLICITZOS FALSE TLSMECHANISM FTP CIPHERSUITE SSL_RC4_SHA ; DEBUG SEC On Wed, May 7, 2014 at 3:36 PM, Mark Post wrote: > >>> On 5/7/2014 at 08:25 AM, Mark Pace wrote: > > I'm beginning to think I am doing something fundamentally wrong instead > of > > it being a matter of wrong parameters. > > > > //FTP EXEC PGM=FTP,REGION=5M,PARM='(EXIT' > > //SYSPRINT DD SYSOUT=* > > //SYSFTPD DD DISP=SHR,DSN=MARPACE.JCL.CNTL(FTPSDATA) > > //OUTPUTDD SYSOUT=* > > //INPUT DD * USE LOWER CASE BELOW > > ftp.s390.mainline.com > > userid password > > dir > > quit > > I'm not at all familiar with the z/OS FTP client, so this may be entirely > irrelevant. But, where in this JCL stream are you telling the client to > try to use SSL and not just plain-text FTP? > > > Mark Post > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- The postings on this site are my own and don’t necessarily represent Mainline’s positions or opinions Mark D Pace Senior Systems Engineer Mainline Information Systems -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS FTPS Client & Linux FTP server
>>> On 5/7/2014 at 08:25 AM, Mark Pace wrote: > I'm beginning to think I am doing something fundamentally wrong instead of > it being a matter of wrong parameters. > > //FTP EXEC PGM=FTP,REGION=5M,PARM='(EXIT' > //SYSPRINT DD SYSOUT=* > //SYSFTPD DD DISP=SHR,DSN=MARPACE.JCL.CNTL(FTPSDATA) > //OUTPUTDD SYSOUT=* > //INPUT DD * USE LOWER CASE BELOW > ftp.s390.mainline.com > userid password > dir > quit I'm not at all familiar with the z/OS FTP client, so this may be entirely irrelevant. But, where in this JCL stream are you telling the client to try to use SSL and not just plain-text FTP? Mark Post -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS FTPS Client & Linux FTP server
I had looked at that also. The vsftpd config - comments removed for brevity. listen=YES max_clients=20 use_localtime=YES log_ftp_protocol=YES # enable FTPS ssl_enable=YES allow_anon_ssl=NO force_local_data_ssl=NO force_local_logins_ssl=NO ssl_tlsv1=YES ssl_sslv2=NO ssl_sslv3=NO ssl_request_cert=NO rsa_cert_file=/etc/vsftpd/mainline-wc-2011.crt rsa_private_key_file=/etc/vsftpd/mainline-wc-2011.key ssl_ciphers=RC4-SHA debug_ssl=YES anonymous_enable=NO local_enable=YES write_enable=YES local_umask=022 anon_umask=666 anon_upload_enable=NO dirmessage_enable=YES message_file=.message xferlog_enable=YES connect_from_port_20=YES xferlog_file=/var/log/vsftpd.log banner_file=/etc/vsftpd.banner deny_email_enable=YES banned_email_file=/etc/vsftpd.banned_emails chroot_local_user=YES pasv_enable=YES listen_ipv6=NO On Wed, May 7, 2014 at 3:20 PM, Gibney, Dave wrote: > I am now reminded of a difficulty I had with this once. My plea to the > list(s) resulted in this: > > Skip to site navigation (Press enter) > Re: FTP TLS Handshake Fails with SSL RC 410 Cal McCracken Thu, 10 Mar 2011 > 07:44:54 -0800 > > Thanks to a private responder, I was able to get this resolved. I don't > know if the SSL RC 410 covers other error situations, but in my case, the > resolution was to set configuration parm, ssl_request_cert to NO (defaults > to YES). This is a config parm for the vsftpd FTP server on our Linux > system. > > My humble thanks to the responder. > > > > > -Original Message- > > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > > On Behalf Of Mark Pace > > Sent: Wednesday, May 07, 2014 12:02 PM > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: Re: z/OS FTPS Client & Linux FTP server > > > > And for giggles I setup another Linux FTP server - this one pure-ftpd - > again no > > issues connecting with a windows FTPS client - still no connection with > z/OS. > > > > > > On Wed, May 7, 2014 at 2:39 PM, Mark Pace > > wrote: > > > > > Yes - it was at that time. Since I started working on the RACF > > > certs/keyring stuff the ftp.data has been updated as I go along. > Currently. > > > > > > SECURE_CTRLCONN CLEAR > > > SECURE_DATACONN PRIVATE > > > SECURE_FTP REQUIRED > > > SECURE_HOSTNAME OPTIONAL > > > SECURE_MECHANISM TLS > > > KEYRING IBMUSER/FtpSecur > > > TLSPORT 21 > > > TLSRFCLEVEL CCCNONOTIFY > > > TLSTIMEOUT 10 > > > ; > > > ;CTRLCONN 7BIT > > > SECUREIMPLICITZOS FALSE > > > TLSMECHANISM FTP > > > CIPHERSUITE SSL_RC4_SHA > > > ; > > > DEBUG SEC > > > > > > > > > On Wed, May 7, 2014 at 2:06 PM, Gibney, Dave wrote: > > > > > >> You said latest, so maybe you have tried others. In the parms listed > > >> here, your keyring is commented out. > > >> > > >> > -Original Message- > > >> > From: IBM Mainframe Discussion List > > >> > [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Mark Pace > > >> > Sent: Wednesday, May 07, 2014 5:26 AM > > >> > To: IBM-MAIN@LISTSERV.UA.EDU > > >> > Subject: z/OS FTPS Client & Linux FTP server > > >> > > > >> > Has anyone successfully sent data to a Linux FTP server using TLS > > >> security > > >> > from the z/OS FTP client? > > >> > > > >> > I have a Linux server running vsftpd - I've been using it for years > > >> > to > > >> send SMF > > >> > data. I've added TLS support to this server. I've verified that > > >> > the > > >> Secure > > >> > connect works via a Filezilla client, > > >> > > > >> > So now I would like to be able to send SMF data to the server. But > > >> > I > > >> always > > >> > get an authentication failure. I've tried every combination of > > >> > Security parameters I can come up with. > > >> > > > >> > These are the latest parms in my ftp.data file. > > >> > > > >> > ;SECURE_CTRLCONN SAFE > > >> > SECURE_DATACONN CLEAR > > >> > SECURE_FTP REQUIRED > > >> > SECURE_HOSTNAME OPTIONAL > > >> > SECURE_MECHANISM TLS > > >> > SECUREIMPLICITZOS FALSE > > >> > CIPHERSUITE SSL_RC4_SHA > > >> > ;KEYRING IBMUSER/SecureFTPKeyRing > > >> > TLSPORT 21 > > >&
Re: z/OS FTPS Client & Linux FTP server
You did do a: SETROPTS RACLIST(DIGTCERT) REFRESH after last changing the keyring? What does the LISTRING show now? Does the userid submitting the batch job have any ICH408I errors in the log? -- Donald J. -- http://www.fastmail.fm - Send your email first class -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS FTPS Client & Linux FTP server
I am now reminded of a difficulty I had with this once. My plea to the list(s) resulted in this: Skip to site navigation (Press enter) Re: FTP TLS Handshake Fails with SSL RC 410 Cal McCracken Thu, 10 Mar 2011 07:44:54 -0800 Thanks to a private responder, I was able to get this resolved. I don't know if the SSL RC 410 covers other error situations, but in my case, the resolution was to set configuration parm, ssl_request_cert to NO (defaults to YES). This is a config parm for the vsftpd FTP server on our Linux system. My humble thanks to the responder. > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > On Behalf Of Mark Pace > Sent: Wednesday, May 07, 2014 12:02 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: z/OS FTPS Client & Linux FTP server > > And for giggles I setup another Linux FTP server - this one pure-ftpd - again > no > issues connecting with a windows FTPS client - still no connection with z/OS. > > > On Wed, May 7, 2014 at 2:39 PM, Mark Pace > wrote: > > > Yes - it was at that time. Since I started working on the RACF > > certs/keyring stuff the ftp.data has been updated as I go along. Currently. > > > > SECURE_CTRLCONN CLEAR > > SECURE_DATACONN PRIVATE > > SECURE_FTP REQUIRED > > SECURE_HOSTNAME OPTIONAL > > SECURE_MECHANISM TLS > > KEYRING IBMUSER/FtpSecur > > TLSPORT 21 > > TLSRFCLEVEL CCCNONOTIFY > > TLSTIMEOUT 10 > > ; > > ;CTRLCONN 7BIT > > SECUREIMPLICITZOS FALSE > > TLSMECHANISM FTP > > CIPHERSUITE SSL_RC4_SHA > > ; > > DEBUG SEC > > > > > > On Wed, May 7, 2014 at 2:06 PM, Gibney, Dave wrote: > > > >> You said latest, so maybe you have tried others. In the parms listed > >> here, your keyring is commented out. > >> > >> > -----Original Message----- > >> > From: IBM Mainframe Discussion List > >> > [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Mark Pace > >> > Sent: Wednesday, May 07, 2014 5:26 AM > >> > To: IBM-MAIN@LISTSERV.UA.EDU > >> > Subject: z/OS FTPS Client & Linux FTP server > >> > > >> > Has anyone successfully sent data to a Linux FTP server using TLS > >> security > >> > from the z/OS FTP client? > >> > > >> > I have a Linux server running vsftpd - I've been using it for years > >> > to > >> send SMF > >> > data. I've added TLS support to this server. I've verified that > >> > the > >> Secure > >> > connect works via a Filezilla client, > >> > > >> > So now I would like to be able to send SMF data to the server. But > >> > I > >> always > >> > get an authentication failure. I've tried every combination of > >> > Security parameters I can come up with. > >> > > >> > These are the latest parms in my ftp.data file. > >> > > >> > ;SECURE_CTRLCONN SAFE > >> > SECURE_DATACONN CLEAR > >> > SECURE_FTP REQUIRED > >> > SECURE_HOSTNAME OPTIONAL > >> > SECURE_MECHANISM TLS > >> > SECUREIMPLICITZOS FALSE > >> > CIPHERSUITE SSL_RC4_SHA > >> > ;KEYRING IBMUSER/SecureFTPKeyRing > >> > TLSPORT 21 > >> > TLSRFCLEVEL CCCNONOTIFY > >> > TLSTIMEOUT 10 > >> > ;SECURE_PBSZ 16384 > >> > ; > >> > ;CTRLCONN 7BIT > >> > > >> > I'm beginning to think I am doing something fundamentally wrong > >> > instead > >> of > >> > it being a matter of wrong parameters. > >> > > >> > //FTP EXEC PGM=FTP,REGION=5M,PARM='(EXIT' > >> > //SYSPRINT DD SYSOUT=* > >> > //SYSFTPD DD DISP=SHR,DSN=MARPACE.JCL.CNTL(FTPSDATA) > >> > //OUTPUTDD SYSOUT=* > >> > //INPUT DD * USE LOWER CASE BELOW > >> > ftp.s390.mainline.com > >> > userid password > >> > dir > >> > quit > >> > > >> > > >> > EZA1736I FTP > >> > (EXIT > >> > > >> > EZY2640I Using dd:SYSFTPD=MARPACE.JCL.CNTL(FTPSDATA) for local site > >> > configuration parameters. > >> > EZA1450I IBM FTP CS > >> > V2R1 > >> > EZA1772I FTP: EXIT has been > >> > set. > >> > EZA1456I Connect to > >> > ? > >> > EZA1736I ftp.s390.mainline.com > >> > > >
Re: z/OS FTPS Client & Linux FTP server
And for giggles I setup another Linux FTP server - this one pure-ftpd - again no issues connecting with a windows FTPS client - still no connection with z/OS. On Wed, May 7, 2014 at 2:39 PM, Mark Pace wrote: > Yes - it was at that time. Since I started working on the RACF > certs/keyring stuff the ftp.data has been updated as I go along. Currently. > > SECURE_CTRLCONN CLEAR > SECURE_DATACONN PRIVATE > SECURE_FTP REQUIRED > SECURE_HOSTNAME OPTIONAL > SECURE_MECHANISM TLS > KEYRING IBMUSER/FtpSecur > TLSPORT 21 > TLSRFCLEVEL CCCNONOTIFY > TLSTIMEOUT 10 > ; > ;CTRLCONN 7BIT > SECUREIMPLICITZOS FALSE > TLSMECHANISM FTP > CIPHERSUITE SSL_RC4_SHA > ; > DEBUG SEC > > > On Wed, May 7, 2014 at 2:06 PM, Gibney, Dave wrote: > >> You said latest, so maybe you have tried others. In the parms listed >> here, your keyring is commented out. >> >> > -Original Message- >> > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] >> > On Behalf Of Mark Pace >> > Sent: Wednesday, May 07, 2014 5:26 AM >> > To: IBM-MAIN@LISTSERV.UA.EDU >> > Subject: z/OS FTPS Client & Linux FTP server >> > >> > Has anyone successfully sent data to a Linux FTP server using TLS >> security >> > from the z/OS FTP client? >> > >> > I have a Linux server running vsftpd - I've been using it for years to >> send SMF >> > data. I've added TLS support to this server. I've verified that the >> Secure >> > connect works via a Filezilla client, >> > >> > So now I would like to be able to send SMF data to the server. But I >> always >> > get an authentication failure. I've tried every combination of Security >> > parameters I can come up with. >> > >> > These are the latest parms in my ftp.data file. >> > >> > ;SECURE_CTRLCONN SAFE >> > SECURE_DATACONN CLEAR >> > SECURE_FTP REQUIRED >> > SECURE_HOSTNAME OPTIONAL >> > SECURE_MECHANISM TLS >> > SECUREIMPLICITZOS FALSE >> > CIPHERSUITE SSL_RC4_SHA >> > ;KEYRING IBMUSER/SecureFTPKeyRing >> > TLSPORT 21 >> > TLSRFCLEVEL CCCNONOTIFY >> > TLSTIMEOUT 10 >> > ;SECURE_PBSZ 16384 >> > ; >> > ;CTRLCONN 7BIT >> > >> > I'm beginning to think I am doing something fundamentally wrong instead >> of >> > it being a matter of wrong parameters. >> > >> > //FTP EXEC PGM=FTP,REGION=5M,PARM='(EXIT' >> > //SYSPRINT DD SYSOUT=* >> > //SYSFTPD DD DISP=SHR,DSN=MARPACE.JCL.CNTL(FTPSDATA) >> > //OUTPUTDD SYSOUT=* >> > //INPUT DD * USE LOWER CASE BELOW >> > ftp.s390.mainline.com >> > userid password >> > dir >> > quit >> > >> > >> > EZA1736I FTP >> > (EXIT >> > >> > EZY2640I Using dd:SYSFTPD=MARPACE.JCL.CNTL(FTPSDATA) for local site >> > configuration parameters. >> > EZA1450I IBM FTP CS >> > V2R1 >> > EZA1772I FTP: EXIT has been >> > set. >> > EZA1456I Connect to >> > ? >> > EZA1736I ftp.s390.mainline.com >> > >> > EZA1554I Connecting to: ftp.s390.mainline.com 10.6.0.10 port: >> > 21. >> > EZA2897I Authentication negotiation >> > failed >> > EZA2898I Unable to successfully negotiate required authentication >> EZA1735I >> > Std Return Code = 1, Error Code = >> > 00017 >> > >> > >> > >> > >> > >> > >> > >> > >> > -- >> > The postings on this site are my own and don’t necessarily represent >> > Mainline’s positions or opinions >> > >> > Mark D Pace >> > Senior Systems Engineer >> > Mainline Information Systems >> > >> > -- >> > For IBM-MAIN subscribe / signoff / archive access instructions, send >> email to >> > lists...@listserv.ua.edu with the message: INFO IBM-MAIN >> >> -- >> For IBM-MAIN subscribe / signoff / archive access instructions, >> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN >> > > > > -- > The postings on this site are my own and don’t necessarily represent > Mainline’s positions or opinions > > Mark D Pace > Senior Systems Engineer > Mainline Information Systems > > > > -- The postings on this site are my own and don’t necessarily represent Mainline’s positions or opinions Mark D Pace Senior Systems Engineer Mainline Information Systems -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS FTPS Client & Linux FTP server
Yes - it was at that time. Since I started working on the RACF certs/keyring stuff the ftp.data has been updated as I go along. Currently. SECURE_CTRLCONN CLEAR SECURE_DATACONN PRIVATE SECURE_FTP REQUIRED SECURE_HOSTNAME OPTIONAL SECURE_MECHANISM TLS KEYRING IBMUSER/FtpSecur TLSPORT 21 TLSRFCLEVEL CCCNONOTIFY TLSTIMEOUT 10 ; ;CTRLCONN 7BIT SECUREIMPLICITZOS FALSE TLSMECHANISM FTP CIPHERSUITE SSL_RC4_SHA ; DEBUG SEC On Wed, May 7, 2014 at 2:06 PM, Gibney, Dave wrote: > You said latest, so maybe you have tried others. In the parms listed here, > your keyring is commented out. > > > -Original Message- > > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > > On Behalf Of Mark Pace > > Sent: Wednesday, May 07, 2014 5:26 AM > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: z/OS FTPS Client & Linux FTP server > > > > Has anyone successfully sent data to a Linux FTP server using TLS > security > > from the z/OS FTP client? > > > > I have a Linux server running vsftpd - I've been using it for years to > send SMF > > data. I've added TLS support to this server. I've verified that the > Secure > > connect works via a Filezilla client, > > > > So now I would like to be able to send SMF data to the server. But I > always > > get an authentication failure. I've tried every combination of Security > > parameters I can come up with. > > > > These are the latest parms in my ftp.data file. > > > > ;SECURE_CTRLCONN SAFE > > SECURE_DATACONN CLEAR > > SECURE_FTP REQUIRED > > SECURE_HOSTNAME OPTIONAL > > SECURE_MECHANISM TLS > > SECUREIMPLICITZOS FALSE > > CIPHERSUITE SSL_RC4_SHA > > ;KEYRING IBMUSER/SecureFTPKeyRing > > TLSPORT 21 > > TLSRFCLEVEL CCCNONOTIFY > > TLSTIMEOUT 10 > > ;SECURE_PBSZ 16384 > > ; > > ;CTRLCONN 7BIT > > > > I'm beginning to think I am doing something fundamentally wrong instead > of > > it being a matter of wrong parameters. > > > > //FTP EXEC PGM=FTP,REGION=5M,PARM='(EXIT' > > //SYSPRINT DD SYSOUT=* > > //SYSFTPD DD DISP=SHR,DSN=MARPACE.JCL.CNTL(FTPSDATA) > > //OUTPUTDD SYSOUT=* > > //INPUT DD * USE LOWER CASE BELOW > > ftp.s390.mainline.com > > userid password > > dir > > quit > > > > > > EZA1736I FTP > > (EXIT > > > > EZY2640I Using dd:SYSFTPD=MARPACE.JCL.CNTL(FTPSDATA) for local site > > configuration parameters. > > EZA1450I IBM FTP CS > > V2R1 > > EZA1772I FTP: EXIT has been > > set. > > EZA1456I Connect to > > ? > > EZA1736I ftp.s390.mainline.com > > > > EZA1554I Connecting to: ftp.s390.mainline.com 10.6.0.10 port: > > 21. > > EZA2897I Authentication negotiation > > failed > > EZA2898I Unable to successfully negotiate required authentication > EZA1735I > > Std Return Code = 1, Error Code = > > 00017 > > > > > > > > > > > > > > > > > > -- > > The postings on this site are my own and don’t necessarily represent > > Mainline’s positions or opinions > > > > Mark D Pace > > Senior Systems Engineer > > Mainline Information Systems > > > > -- > > For IBM-MAIN subscribe / signoff / archive access instructions, send > email to > > lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- The postings on this site are my own and don’t necessarily represent Mainline’s positions or opinions Mark D Pace Senior Systems Engineer Mainline Information Systems -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS FTPS Client & Linux FTP server
You said latest, so maybe you have tried others. In the parms listed here, your keyring is commented out. > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > On Behalf Of Mark Pace > Sent: Wednesday, May 07, 2014 5:26 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: z/OS FTPS Client & Linux FTP server > > Has anyone successfully sent data to a Linux FTP server using TLS security > from the z/OS FTP client? > > I have a Linux server running vsftpd - I've been using it for years to send > SMF > data. I've added TLS support to this server. I've verified that the Secure > connect works via a Filezilla client, > > So now I would like to be able to send SMF data to the server. But I always > get an authentication failure. I've tried every combination of Security > parameters I can come up with. > > These are the latest parms in my ftp.data file. > > ;SECURE_CTRLCONN SAFE > SECURE_DATACONN CLEAR > SECURE_FTP REQUIRED > SECURE_HOSTNAME OPTIONAL > SECURE_MECHANISM TLS > SECUREIMPLICITZOS FALSE > CIPHERSUITE SSL_RC4_SHA > ;KEYRING IBMUSER/SecureFTPKeyRing > TLSPORT 21 > TLSRFCLEVEL CCCNONOTIFY > TLSTIMEOUT 10 > ;SECURE_PBSZ 16384 > ; > ;CTRLCONN 7BIT > > I'm beginning to think I am doing something fundamentally wrong instead of > it being a matter of wrong parameters. > > //FTP EXEC PGM=FTP,REGION=5M,PARM='(EXIT' > //SYSPRINT DD SYSOUT=* > //SYSFTPD DD DISP=SHR,DSN=MARPACE.JCL.CNTL(FTPSDATA) > //OUTPUTDD SYSOUT=* > //INPUT DD * USE LOWER CASE BELOW > ftp.s390.mainline.com > userid password > dir > quit > > > EZA1736I FTP > (EXIT > > EZY2640I Using dd:SYSFTPD=MARPACE.JCL.CNTL(FTPSDATA) for local site > configuration parameters. > EZA1450I IBM FTP CS > V2R1 > EZA1772I FTP: EXIT has been > set. > EZA1456I Connect to > ? > EZA1736I ftp.s390.mainline.com > > EZA1554I Connecting to: ftp.s390.mainline.com 10.6.0.10 port: > 21. > EZA2897I Authentication negotiation > failed > EZA2898I Unable to successfully negotiate required authentication EZA1735I > Std Return Code = 1, Error Code = > 00017 > > > > > > > > > -- > The postings on this site are my own and don’t necessarily represent > Mainline’s positions or opinions > > Mark D Pace > Senior Systems Engineer > Mainline Information Systems > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, send email to > lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS FTPS Client & Linux FTP server
Anything is possible. The vsftpd server is of no use for debugging. There is an ssl_debug parameter, but it doesn't produce any output. On Wed, May 7, 2014 at 1:19 PM, Brian France wrote: > I saw this same message before. We had a guy here that ran a tcp trace > during the connection process, moved it to a linux workstation and used > TCPDUMP? on it. What he determined was the windows server we were trying to > connect to had a checkpoint firewall and it actually was re-writting the > first two byes of the cert. There was a setting that had to change. I know > you said no firewalls BUT is it possible that something else is doing this > on the linux server? A setting in VSFTP maybe? He left doc somewhere and if > you're interested I'll dig it up. > > > On 5/7/2014 10:38 AM, Mark Pace wrote: > >> Trying to turn on some DEBUG information >> DEBUG FLO >> >> FC1003 authServer: secure_socket_init failed with rc = 410 (SSL message >> format is incorrect) >> >> So not to try to figure out where to find this error message. >> >> >> On Wed, May 7, 2014 at 10:19 AM, Mark Pace >> wrote: >> >> I remember setting up something very similar to connect to IBM. So I >>> added the GoDady cert to the same keyring. >>> >>> sr cla(digtring) >>> IBMUSER.smpemaint >>> *IBMUSER.FtpSecur * >>> >>> IBMUSER.IBMRing >>> IBMUSER.SecureFTPKeyRing >>> IBMUSER.SMPEMAINT >>> TN3270.TNRING >>> *** >>> >>> >>> >>> racdcert id(ibmuser) listring(*FtpSecur*) >>> >>> Digital ring information for user IBMUSER: >>> >>>Ring: >>> >FtpSecur< >>>Certificate Label Name Cert Owner USAGE DEFAULT >>> --- >>>GeoTrust Global CA CERTAUTH CERTAUTH NO >>> * Go Daddy Class 2 CERTAUTH CERTAUTH YES* >>> >>> >>> >>> So I added to my ftp.data >>> KEYRING IBMUSER/FtpSecur >>> >>> But that still isn't the final answer >>> >>> EZA2897I Authentication negotiation failed >>> EZA2898I Unable to successfully negotiate required authentication >>> EZA1735I Std Return Code = 1, Error Code = 00017 >>> >>> >>> >>> On Wed, May 7, 2014 at 9:44 AM, Chase, John wrote: >>> >>> If you're authorized to issue RACF commands, try SR CLA(DIGTRING) to >>>> list >>>> defined key rings (format is userid.ringname), then RACDCERT ID(userid) >>>> LISTRING(ringname or *) to see the ring(s) contents. >>>> >>>> Also ensure that the root cert you're interested in has TRUST status >>>> (default is NOTRUST). >>>> >>>>-jc- >>>> >>>> -Original Message- >>>>> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] >>>>> >>>> On Behalf Of Mark Pace >>>> >>>>> Sent: Wednesday, May 07, 2014 8:34 AM >>>>> To: IBM-MAIN@LISTSERV.UA.EDU >>>>> Subject: Re: z/OS FTPS Client & Linux FTP server >>>>> >>>>> The cipher was one of my early problems. But I figured that one out. >>>>> vsftpd - ssl_ciphers=RC4-SHA >>>>> z/OS - CIPHERSUITE SSL_RC4_SHA >>>>> >>>>> I'm certain that this Keyring is (part of) my problem. Stumbling >>>>> >>>> through >>>> >>>>> RACF I have found that the GoDaddy Root CA is already defined in z/OS, >>>>> >>>> but still trying to determine >>>> >>>>> if it is part of a keyring. >>>>> >>>>> >>>>> >>>>> On Wed, May 7, 2014 at 8:57 AM, Donald J. wrote: >>>>> >>>>> Make sure client and server have a common cipher. >>>>>> SSL_AES_128_SHA and SSL_AES_256_SHA are probably more commonly used >>>>>> than SSL_RC4_SHA. >>>>>> >>>>>> Make sure the linus root certificate is in your z/OS client keyring. >>>>>> >>>>>> -- >>>>>>Donald J. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> http://www.fastmail.fm - A no graphics, no pop-ups email
Re: z/OS FTPS Client & Linux FTP server
I saw this same message before. We had a guy here that ran a tcp trace
during the connection process, moved it to a linux workstation and used
TCPDUMP? on it. What he determined was the windows server we were trying
to connect to had a checkpoint firewall and it actually was re-writting
the first two byes of the cert. There was a setting that had to change.
I know you said no firewalls BUT is it possible that something else is
doing this on the linux server? A setting in VSFTP maybe? He left doc
somewhere and if you're interested I'll dig it up.
On 5/7/2014 10:38 AM, Mark Pace wrote:
Trying to turn on some DEBUG information
DEBUG FLO
FC1003 authServer: secure_socket_init failed with rc = 410 (SSL message
format is incorrect)
So not to try to figure out where to find this error message.
On Wed, May 7, 2014 at 10:19 AM, Mark Pace wrote:
I remember setting up something very similar to connect to IBM. So I
added the GoDady cert to the same keyring.
sr cla(digtring)
IBMUSER.smpemaint
*IBMUSER.FtpSecur *
IBMUSER.IBMRing
IBMUSER.SecureFTPKeyRing
IBMUSER.SMPEMAINT
TN3270.TNRING
***
racdcert id(ibmuser) listring(*FtpSecur*)
Digital ring information for user IBMUSER:
Ring:
>FtpSecur<
Certificate Label Name Cert Owner USAGE DEFAULT
---
GeoTrust Global CA CERTAUTH CERTAUTH NO
* Go Daddy Class 2 CERTAUTH CERTAUTH YES*
So I added to my ftp.data
KEYRING IBMUSER/FtpSecur
But that still isn't the final answer
EZA2897I Authentication negotiation failed
EZA2898I Unable to successfully negotiate required authentication
EZA1735I Std Return Code = 1, Error Code = 00017
On Wed, May 7, 2014 at 9:44 AM, Chase, John wrote:
If you're authorized to issue RACF commands, try SR CLA(DIGTRING) to list
defined key rings (format is userid.ringname), then RACDCERT ID(userid)
LISTRING(ringname or *) to see the ring(s) contents.
Also ensure that the root cert you're interested in has TRUST status
(default is NOTRUST).
-jc-
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
On Behalf Of Mark Pace
Sent: Wednesday, May 07, 2014 8:34 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: z/OS FTPS Client & Linux FTP server
The cipher was one of my early problems. But I figured that one out.
vsftpd - ssl_ciphers=RC4-SHA
z/OS - CIPHERSUITE SSL_RC4_SHA
I'm certain that this Keyring is (part of) my problem. Stumbling
through
RACF I have found that the GoDaddy Root CA is already defined in z/OS,
but still trying to determine
if it is part of a keyring.
On Wed, May 7, 2014 at 8:57 AM, Donald J. wrote:
Make sure client and server have a common cipher.
SSL_AES_128_SHA and SSL_AES_256_SHA are probably more commonly used
than SSL_RC4_SHA.
Make sure the linus root certificate is in your z/OS client keyring.
--
Donald J.
--
http://www.fastmail.fm - A no graphics, no pop-ups email service
--
For IBM-MAIN subscribe / signoff / archive access instructions, send
email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
--
The postings on this site are my own and don’t necessarily represent
Mainline’s positions or opinions
Mark D Pace
Senior Systems Engineer
Mainline Information Systems
--
For IBM-MAIN subscribe / signoff / archive access instructions, send
email to lists...@listserv.ua.edu
with the message: INFO IBM-MAIN
**
Information contained in this e-mail message and in any attachments
thereto is confidential. If you are not the intended recipient, please
destroy this message, delete any copies held on your systems, notify the
sender immediately, and refrain from using or disclosing all or any part of
its content to any other person.
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
--
The postings on this site are my own and don’t necessarily represent
Mainline’s positions or opinions
Mark D Pace
Senior Systems Engineer
Mainline Information Systems
--
Brian W. France
Systems Administrator (Mainframe)
Pennsylvania State University
Administrative Information Services - Infrastructure/SYSARC
Rm 25 Shields Bldg., University Park, Pa. 16802
814-863-4739
b...@psu.edu
"To make an apple pie from scratch, you must first invent the universe."
Carl Sagan
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS FTPS Client & Linux FTP server
These are not self signed certs. It was issued by Go Daddy. Why I was trying to add the Root authority certificate, and failed. Still researching what FC level vsftpd uses for TLS No firewalls involved, at least for this test. This a hipersocket connection between z/OS and a Linux for System running on the same CEC. Now off to try to figure out GSKSRVR. On Wed, May 7, 2014 at 12:56 PM, Rob Schramm wrote: > It is definitely TLS and not ATTLS. > > GSKSRVR trace is your friend. > > Biggest issues that i have had > -Self signed certs are not allowed courtesy of TLS 1.0 > -RFC level is very important!!! > -Firewalls and extended pasv are not supported by many clients > > Rob > On May 7, 2014 11:51 AM, "Mark Pace" wrote: > > > Crap - I've gotten myself so confused. > > That was a client certificate I put in many years ago when we did SSL on > > our TN3270 connections. I think I still need to add the Go Daddy root > > certificate, which what I thought that one was. How I hate this stuff. > > > > > > On Wed, May 7, 2014 at 11:43 AM, Donald J. wrote: > > > > > The DEFAULT YES would be used for a client certificate, > > > not for a CERTAUTH entry. > > > > > > -- > > > Donald J. > > > > > > > Digital ring information for user IBMUSER: > > > > > > > > Ring: > > > >>FtpSecur< > > > > Certificate Label Name Cert Owner USAGE > DEFAULT > > > > > --- > > > > GeoTrust Global CA CERTAUTH CERTAUTH NO > > > > * Go Daddy Class 2 CERTAUTH CERTAUTH > YES* > > > > > > > > > > -- > > > http://www.fastmail.fm - mmm... Fastmail... > > > > > > -- > > > For IBM-MAIN subscribe / signoff / archive access instructions, > > > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > > > > > > > > > > -- > > The postings on this site are my own and don’t necessarily represent > > Mainline’s positions or opinions > > > > Mark D Pace > > Senior Systems Engineer > > Mainline Information Systems > > > > -- > > For IBM-MAIN subscribe / signoff / archive access instructions, > > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- The postings on this site are my own and don’t necessarily represent Mainline’s positions or opinions Mark D Pace Senior Systems Engineer Mainline Information Systems -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS FTPS Client & Linux FTP server
It is definitely TLS and not ATTLS. GSKSRVR trace is your friend. Biggest issues that i have had -Self signed certs are not allowed courtesy of TLS 1.0 -RFC level is very important!!! -Firewalls and extended pasv are not supported by many clients Rob On May 7, 2014 11:51 AM, "Mark Pace" wrote: > Crap - I've gotten myself so confused. > That was a client certificate I put in many years ago when we did SSL on > our TN3270 connections. I think I still need to add the Go Daddy root > certificate, which what I thought that one was. How I hate this stuff. > > > On Wed, May 7, 2014 at 11:43 AM, Donald J. wrote: > > > The DEFAULT YES would be used for a client certificate, > > not for a CERTAUTH entry. > > > > -- > > Donald J. > > > > > Digital ring information for user IBMUSER: > > > > > > Ring: > > >>FtpSecur< > > > Certificate Label Name Cert Owner USAGE DEFAULT > > > --- > > > GeoTrust Global CA CERTAUTH CERTAUTH NO > > > * Go Daddy Class 2 CERTAUTH CERTAUTH YES* > > > > > > > -- > > http://www.fastmail.fm - mmm... Fastmail... > > > > -- > > For IBM-MAIN subscribe / signoff / archive access instructions, > > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > > > > > -- > The postings on this site are my own and don’t necessarily represent > Mainline’s positions or opinions > > Mark D Pace > Senior Systems Engineer > Mainline Information Systems > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS FTPS Client & Linux FTP server
Nope - no proxy involved. On Wed, May 7, 2014 at 11:53 AM, Skip Robinson wrote: > I didn't see in this thread any mention of proxy. In our case, company > policy requires use of a proxy for outside connections to vendors, > including IBM. We cannot use FTPS from mainframe because our proxy (an > appliance) does not understand FTPS and treats any FTPS command as a > syntax error. For initial FTPS debugging, I would suggest looking at the > proxy (if any) to make sure it's handling command pass-through correctly. > > . > . > J.O.Skip Robinson > Southern California Edison Company > Electric Dragon Team Paddler > SHARE MVS Program Co-Manager > 626-302-7535 Office > 323-715-0595 Mobile > jo.skip.robin...@sce.com > > > > From: "Donald J." > To: IBM-MAIN@LISTSERV.UA.EDU, > Date: 05/07/2014 08:43 AM > Subject:Re: z/OS FTPS Client & Linux FTP server > Sent by:IBM Mainframe Discussion List > > > > The DEFAULT YES would be used for a client certificate, > not for a CERTAUTH entry. > > -- > Donald J. > > > Digital ring information for user IBMUSER: > > > > Ring: > >>FtpSecur< > > Certificate Label Name Cert Owner USAGE DEFAULT > > --- > > GeoTrust Global CA CERTAUTH CERTAUTH NO > > * Go Daddy Class 2 CERTAUTH CERTAUTH YES* > > > > -- > http://www.fastmail.fm - mmm... Fastmail... > > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- The postings on this site are my own and don’t necessarily represent Mainline’s positions or opinions Mark D Pace Senior Systems Engineer Mainline Information Systems -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS FTPS Client & Linux FTP server
I didn't see in this thread any mention of proxy. In our case, company policy requires use of a proxy for outside connections to vendors, including IBM. We cannot use FTPS from mainframe because our proxy (an appliance) does not understand FTPS and treats any FTPS command as a syntax error. For initial FTPS debugging, I would suggest looking at the proxy (if any) to make sure it's handling command pass-through correctly. . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 626-302-7535 Office 323-715-0595 Mobile jo.skip.robin...@sce.com From: "Donald J." To: IBM-MAIN@LISTSERV.UA.EDU, Date: 05/07/2014 08:43 AM Subject: Re: z/OS FTPS Client & Linux FTP server Sent by:IBM Mainframe Discussion List The DEFAULT YES would be used for a client certificate, not for a CERTAUTH entry. -- Donald J. > Digital ring information for user IBMUSER: > > Ring: >>FtpSecur< > Certificate Label Name Cert Owner USAGE DEFAULT > --- > GeoTrust Global CA CERTAUTH CERTAUTH NO > * Go Daddy Class 2 CERTAUTH CERTAUTH YES* > -- http://www.fastmail.fm - mmm... Fastmail... -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS FTPS Client & Linux FTP server
Crap - I've gotten myself so confused. That was a client certificate I put in many years ago when we did SSL on our TN3270 connections. I think I still need to add the Go Daddy root certificate, which what I thought that one was. How I hate this stuff. On Wed, May 7, 2014 at 11:43 AM, Donald J. wrote: > The DEFAULT YES would be used for a client certificate, > not for a CERTAUTH entry. > > -- > Donald J. > > > Digital ring information for user IBMUSER: > > > > Ring: > >>FtpSecur< > > Certificate Label Name Cert Owner USAGE DEFAULT > > --- > > GeoTrust Global CA CERTAUTH CERTAUTH NO > > * Go Daddy Class 2 CERTAUTH CERTAUTH YES* > > > > -- > http://www.fastmail.fm - mmm... Fastmail... > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- The postings on this site are my own and don’t necessarily represent Mainline’s positions or opinions Mark D Pace Senior Systems Engineer Mainline Information Systems -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS FTPS Client & Linux FTP server
The DEFAULT YES would be used for a client certificate, not for a CERTAUTH entry. -- Donald J. > Digital ring information for user IBMUSER: > > Ring: >>FtpSecur< > Certificate Label Name Cert Owner USAGE DEFAULT > --- > GeoTrust Global CA CERTAUTH CERTAUTH NO > * Go Daddy Class 2 CERTAUTH CERTAUTH YES* > -- http://www.fastmail.fm - mmm... Fastmail... -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS FTPS Client & Linux FTP server
On Wed, 7 May 2014 11:06:32 -0400, Mark Pace wrote: >First - thank you for the manual number so that I can look these up. > >I've no idea what AT-TLS environment means. > By rote memorization: "Application Transparent Transport Layer Security". "Transparent" would seem to imply that the "Application" (in this case, the FTP client) may be entirely unaware that a security protocol is operating at a lower layer. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS FTPS Client & Linux FTP server
First - thank you for the manual number so that I can look these up. Now - Dunce hat firmly in place. I've no idea what AT-TLS environment means. On Wed, May 7, 2014 at 11:00 AM, Donald J. wrote: > SC24-5901 > > 410 SSL message format is incorrect. > Explanation: An incorrectly formatted SSL message is > received from the communication partner. > User response: Collect a System SSL trace > containing a dump of the SSL message and then > contact your service representative > > You usually have to run a GSK trace to track down these problems. > Are you using AT-TLS environment for the FTPS client ? > > -- > Donald J. > dona...@4email.net > > On Wed, May 7, 2014, at 07:38 AM, Mark Pace wrote: > > Trying to turn on some DEBUG information > > DEBUG FLO > > > > FC1003 authServer: secure_socket_init failed with rc = 410 (SSL message > > format is incorrect) > > > > So not to try to figure out where to find this error message. > > > > > > On Wed, May 7, 2014 at 10:19 AM, Mark Pace > > wrote: > > > > > I remember setting up something very similar to connect to IBM. So I > > > added the GoDady cert to the same keyring. > > > > > > sr cla(digtring) > > > IBMUSER.smpemaint > > > *IBMUSER.FtpSecur * > > > IBMUSER.IBMRing > > > IBMUSER.SecureFTPKeyRing > > > IBMUSER.SMPEMAINT > > > TN3270.TNRING > > > *** > > > > > > > > > > > > racdcert id(ibmuser) listring(*FtpSecur*) > > > Digital ring information for user IBMUSER: > > > > > > Ring: > > >>FtpSecur< > > > Certificate Label Name Cert Owner USAGE DEFAULT > > > --- > > > GeoTrust Global CA CERTAUTH CERTAUTH NO > > > * Go Daddy Class 2 CERTAUTH CERTAUTH YES* > > > > > > > > > So I added to my ftp.data > > > KEYRING IBMUSER/FtpSecur > > > > > > But that still isn't the final answer > > > > > > EZA2897I Authentication negotiation failed > > > EZA2898I Unable to successfully negotiate required authentication > > > EZA1735I Std Return Code = 1, Error Code = 00017 > > > > > > > > > > > > On Wed, May 7, 2014 at 9:44 AM, Chase, John wrote: > > > > > >> If you're authorized to issue RACF commands, try SR CLA(DIGTRING) to > list > > >> defined key rings (format is userid.ringname), then RACDCERT > ID(userid) > > >> LISTRING(ringname or *) to see the ring(s) contents. > > >> > > >> Also ensure that the root cert you're interested in has TRUST status > > >> (default is NOTRUST). > > >> > > >> -jc- > > >> > > >> > -Original Message- > > >> > From: IBM Mainframe Discussion List [mailto: > IBM-MAIN@LISTSERV.UA.EDU] > > >> On Behalf Of Mark Pace > > >> > Sent: Wednesday, May 07, 2014 8:34 AM > > >> > To: IBM-MAIN@LISTSERV.UA.EDU > > >> > Subject: Re: z/OS FTPS Client & Linux FTP server > > >> > > > >> > The cipher was one of my early problems. But I figured that one > out. > > >> > vsftpd - ssl_ciphers=RC4-SHA > > >> > z/OS - CIPHERSUITE SSL_RC4_SHA > > >> > > > >> > I'm certain that this Keyring is (part of) my problem. Stumbling > > >> through > > >> > RACF I have found that the GoDaddy Root CA is already defined in > z/OS, > > >> but still trying to determine > > >> > if it is part of a keyring. > > >> > > > >> > > > >> > > > >> > On Wed, May 7, 2014 at 8:57 AM, Donald J. > wrote: > > >> > > > >> > > Make sure client and server have a common cipher. > > >> > > SSL_AES_128_SHA and SSL_AES_256_SHA are probably more commonly > used > > >> > > than SSL_RC4_SHA. > > >> > > > > >> > > Make sure the linus root certificate is in your z/OS client > keyring. > > >> > > > > >> > > -- > > >> > > Donald J. > > >> > > > > >> > > > > >> > > > > >> > > > > >> > > -- > > >> > > http://www.fastmail.fm - A no graphics, no pop-ups em
Re: z/OS FTPS Client & Linux FTP server
If you aren't using any client certs, it is easier to just use a RAC virtual keyring for CERTAUTH server authentication: KEYRING *AUTH*/* -- Donald J. dona...@4email.net On Wed, May 7, 2014, at 07:38 AM, Mark Pace wrote: > Trying to turn on some DEBUG information > DEBUG FLO > > FC1003 authServer: secure_socket_init failed with rc = 410 (SSL message > format is incorrect) > > So not to try to figure out where to find this error message. > > > On Wed, May 7, 2014 at 10:19 AM, Mark Pace > wrote: > > > I remember setting up something very similar to connect to IBM. So I > > added the GoDady cert to the same keyring. > > > > sr cla(digtring) > > IBMUSER.smpemaint > > *IBMUSER.FtpSecur * > > IBMUSER.IBMRing > > IBMUSER.SecureFTPKeyRing > > IBMUSER.SMPEMAINT > > TN3270.TNRING > > *** > > > > > > > > racdcert id(ibmuser) listring(*FtpSecur*) > > Digital ring information for user IBMUSER: > > > > Ring: > >>FtpSecur< > > Certificate Label Name Cert Owner USAGE DEFAULT > > --- > > GeoTrust Global CA CERTAUTH CERTAUTH NO > > * Go Daddy Class 2 CERTAUTH CERTAUTH YES* > > > > > > So I added to my ftp.data > > KEYRING IBMUSER/FtpSecur > > > > But that still isn't the final answer > > > > EZA2897I Authentication negotiation failed > > EZA2898I Unable to successfully negotiate required authentication > > EZA1735I Std Return Code = 1, Error Code = 00017 > > > > > > > > On Wed, May 7, 2014 at 9:44 AM, Chase, John wrote: > > > >> If you're authorized to issue RACF commands, try SR CLA(DIGTRING) to list > >> defined key rings (format is userid.ringname), then RACDCERT ID(userid) > >> LISTRING(ringname or *) to see the ring(s) contents. > >> > >> Also ensure that the root cert you're interested in has TRUST status > >> (default is NOTRUST). > >> > >> -jc- > >> > >> > -Original Message- > >> > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > >> On Behalf Of Mark Pace > >> > Sent: Wednesday, May 07, 2014 8:34 AM > >> > To: IBM-MAIN@LISTSERV.UA.EDU > >> > Subject: Re: z/OS FTPS Client & Linux FTP server > >> > > >> > The cipher was one of my early problems. But I figured that one out. > >> > vsftpd - ssl_ciphers=RC4-SHA > >> > z/OS - CIPHERSUITE SSL_RC4_SHA > >> > > >> > I'm certain that this Keyring is (part of) my problem. Stumbling > >> through > >> > RACF I have found that the GoDaddy Root CA is already defined in z/OS, > >> but still trying to determine > >> > if it is part of a keyring. > >> > > >> > > >> > > >> > On Wed, May 7, 2014 at 8:57 AM, Donald J. wrote: > >> > > >> > > Make sure client and server have a common cipher. > >> > > SSL_AES_128_SHA and SSL_AES_256_SHA are probably more commonly used > >> > > than SSL_RC4_SHA. > >> > > > >> > > Make sure the linus root certificate is in your z/OS client keyring. > >> > > > >> > > -- > >> > > Donald J. > >> > > > >> > > > >> > > > >> > > > >> > > -- > >> > > http://www.fastmail.fm - A no graphics, no pop-ups email service > >> > > > >> > > -- > >> > > For IBM-MAIN subscribe / signoff / archive access instructions, send > >> > > email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > >> > > > >> > > >> > > >> > > >> > -- > >> > The postings on this site are my own and don’t necessarily represent > >> Mainline’s positions or opinions > >> > > >> > Mark D Pace > >> > Senior Systems Engineer > >> > Mainline Information Systems > >> > > >> > -- > >> > For IBM-MAIN subscribe / signoff / archive access instructions, send > >> email to lists...@listserv.ua.edu > >> > with the message: INFO IBM-MAI
Re: z/OS FTPS Client & Linux FTP server
SC24-5901 410 SSL message format is incorrect. Explanation: An incorrectly formatted SSL message is received from the communication partner. User response: Collect a System SSL trace containing a dump of the SSL message and then contact your service representative You usually have to run a GSK trace to track down these problems. Are you using AT-TLS environment for the FTPS client ? -- Donald J. dona...@4email.net On Wed, May 7, 2014, at 07:38 AM, Mark Pace wrote: > Trying to turn on some DEBUG information > DEBUG FLO > > FC1003 authServer: secure_socket_init failed with rc = 410 (SSL message > format is incorrect) > > So not to try to figure out where to find this error message. > > > On Wed, May 7, 2014 at 10:19 AM, Mark Pace > wrote: > > > I remember setting up something very similar to connect to IBM. So I > > added the GoDady cert to the same keyring. > > > > sr cla(digtring) > > IBMUSER.smpemaint > > *IBMUSER.FtpSecur * > > IBMUSER.IBMRing > > IBMUSER.SecureFTPKeyRing > > IBMUSER.SMPEMAINT > > TN3270.TNRING > > *** > > > > > > > > racdcert id(ibmuser) listring(*FtpSecur*) > > Digital ring information for user IBMUSER: > > > > Ring: > >>FtpSecur< > > Certificate Label Name Cert Owner USAGE DEFAULT > > --- > > GeoTrust Global CA CERTAUTH CERTAUTH NO > > * Go Daddy Class 2 CERTAUTH CERTAUTH YES* > > > > > > So I added to my ftp.data > > KEYRING IBMUSER/FtpSecur > > > > But that still isn't the final answer > > > > EZA2897I Authentication negotiation failed > > EZA2898I Unable to successfully negotiate required authentication > > EZA1735I Std Return Code = 1, Error Code = 00017 > > > > > > > > On Wed, May 7, 2014 at 9:44 AM, Chase, John wrote: > > > >> If you're authorized to issue RACF commands, try SR CLA(DIGTRING) to list > >> defined key rings (format is userid.ringname), then RACDCERT ID(userid) > >> LISTRING(ringname or *) to see the ring(s) contents. > >> > >> Also ensure that the root cert you're interested in has TRUST status > >> (default is NOTRUST). > >> > >> -jc- > >> > >> > -Original Message- > >> > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > >> On Behalf Of Mark Pace > >> > Sent: Wednesday, May 07, 2014 8:34 AM > >> > To: IBM-MAIN@LISTSERV.UA.EDU > >> > Subject: Re: z/OS FTPS Client & Linux FTP server > >> > > >> > The cipher was one of my early problems. But I figured that one out. > >> > vsftpd - ssl_ciphers=RC4-SHA > >> > z/OS - CIPHERSUITE SSL_RC4_SHA > >> > > >> > I'm certain that this Keyring is (part of) my problem. Stumbling > >> through > >> > RACF I have found that the GoDaddy Root CA is already defined in z/OS, > >> but still trying to determine > >> > if it is part of a keyring. > >> > > >> > > >> > > >> > On Wed, May 7, 2014 at 8:57 AM, Donald J. wrote: > >> > > >> > > Make sure client and server have a common cipher. > >> > > SSL_AES_128_SHA and SSL_AES_256_SHA are probably more commonly used > >> > > than SSL_RC4_SHA. > >> > > > >> > > Make sure the linus root certificate is in your z/OS client keyring. > >> > > > >> > > -- > >> > > Donald J. > >> > > > >> > > > >> > > > >> > > > >> > > -- > >> > > http://www.fastmail.fm - A no graphics, no pop-ups email service > >> > > > >> > > -- > >> > > For IBM-MAIN subscribe / signoff / archive access instructions, send > >> > > email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > >> > > > >> > > >> > > >> > > >> > -- > >> > The postings on this site are my own and don’t necessarily represent > >> Mainline’s positions or opinions > >> > > >> > Mark D Pace > >> > Senior Systems Engineer > >> > Mainline Information Systems > >> > > >> > -
Re: z/OS FTPS Client & Linux FTP server
Trying to turn on some DEBUG information DEBUG FLO FC1003 authServer: secure_socket_init failed with rc = 410 (SSL message format is incorrect) So not to try to figure out where to find this error message. On Wed, May 7, 2014 at 10:19 AM, Mark Pace wrote: > I remember setting up something very similar to connect to IBM. So I > added the GoDady cert to the same keyring. > > sr cla(digtring) > IBMUSER.smpemaint > *IBMUSER.FtpSecur * > IBMUSER.IBMRing > IBMUSER.SecureFTPKeyRing > IBMUSER.SMPEMAINT > TN3270.TNRING > *** > > > > racdcert id(ibmuser) listring(*FtpSecur*) > Digital ring information for user IBMUSER: > > Ring: >>FtpSecur< > Certificate Label Name Cert Owner USAGE DEFAULT > --- > GeoTrust Global CA CERTAUTH CERTAUTH NO > * Go Daddy Class 2 CERTAUTH CERTAUTH YES* > > > So I added to my ftp.data > KEYRING IBMUSER/FtpSecur > > But that still isn't the final answer > > EZA2897I Authentication negotiation failed > EZA2898I Unable to successfully negotiate required authentication > EZA1735I Std Return Code = 1, Error Code = 00017 > > > > On Wed, May 7, 2014 at 9:44 AM, Chase, John wrote: > >> If you're authorized to issue RACF commands, try SR CLA(DIGTRING) to list >> defined key rings (format is userid.ringname), then RACDCERT ID(userid) >> LISTRING(ringname or *) to see the ring(s) contents. >> >> Also ensure that the root cert you're interested in has TRUST status >> (default is NOTRUST). >> >> -jc- >> >> > -Original Message- >> > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] >> On Behalf Of Mark Pace >> > Sent: Wednesday, May 07, 2014 8:34 AM >> > To: IBM-MAIN@LISTSERV.UA.EDU >> > Subject: Re: z/OS FTPS Client & Linux FTP server >> > >> > The cipher was one of my early problems. But I figured that one out. >> > vsftpd - ssl_ciphers=RC4-SHA >> > z/OS - CIPHERSUITE SSL_RC4_SHA >> > >> > I'm certain that this Keyring is (part of) my problem. Stumbling >> through >> > RACF I have found that the GoDaddy Root CA is already defined in z/OS, >> but still trying to determine >> > if it is part of a keyring. >> > >> > >> > >> > On Wed, May 7, 2014 at 8:57 AM, Donald J. wrote: >> > >> > > Make sure client and server have a common cipher. >> > > SSL_AES_128_SHA and SSL_AES_256_SHA are probably more commonly used >> > > than SSL_RC4_SHA. >> > > >> > > Make sure the linus root certificate is in your z/OS client keyring. >> > > >> > > -- >> > > Donald J. >> > > >> > > >> > > >> > > >> > > -- >> > > http://www.fastmail.fm - A no graphics, no pop-ups email service >> > > >> > > -- >> > > For IBM-MAIN subscribe / signoff / archive access instructions, send >> > > email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN >> > > >> > >> > >> > >> > -- >> > The postings on this site are my own and don’t necessarily represent >> Mainline’s positions or opinions >> > >> > Mark D Pace >> > Senior Systems Engineer >> > Mainline Information Systems >> > >> > -- >> > For IBM-MAIN subscribe / signoff / archive access instructions, send >> email to lists...@listserv.ua.edu >> > with the message: INFO IBM-MAIN >> >> ** >> Information contained in this e-mail message and in any attachments >> thereto is confidential. If you are not the intended recipient, please >> destroy this message, delete any copies held on your systems, notify the >> sender immediately, and refrain from using or disclosing all or any part of >> its content to any other person. >> >> >> -- >> For IBM-MAIN subscribe / signoff / archive access instructions, >> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN >> > > > > -- > The postings on this site are my own and don’t necessarily represent > Mainline’s positions or opinions > > Mark D Pace > Senior Systems Engineer > Mainline Information Systems > > > > -- The postings on this site are my own and don’t necessarily represent Mainline’s positions or opinions Mark D Pace Senior Systems Engineer Mainline Information Systems -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS FTPS Client & Linux FTP server
I remember setting up something very similar to connect to IBM. So I
added the GoDady cert to the same keyring.
sr cla(digtring)
IBMUSER.smpemaint
*IBMUSER.FtpSecur *
IBMUSER.IBMRing
IBMUSER.SecureFTPKeyRing
IBMUSER.SMPEMAINT
TN3270.TNRING
***
racdcert id(ibmuser) listring(*FtpSecur*)
Digital ring information for user IBMUSER:
Ring:
>FtpSecur<
Certificate Label Name Cert Owner USAGE DEFAULT
---
GeoTrust Global CA CERTAUTH CERTAUTH NO
* Go Daddy Class 2 CERTAUTH CERTAUTH YES*
So I added to my ftp.data
KEYRING IBMUSER/FtpSecur
But that still isn't the final answer
EZA2897I Authentication negotiation failed
EZA2898I Unable to successfully negotiate required authentication
EZA1735I Std Return Code = 1, Error Code = 00017
On Wed, May 7, 2014 at 9:44 AM, Chase, John wrote:
> If you're authorized to issue RACF commands, try SR CLA(DIGTRING) to list
> defined key rings (format is userid.ringname), then RACDCERT ID(userid)
> LISTRING(ringname or *) to see the ring(s) contents.
>
> Also ensure that the root cert you're interested in has TRUST status
> (default is NOTRUST).
>
> -jc-
>
> > -Original Message-
> > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Mark Pace
> > Sent: Wednesday, May 07, 2014 8:34 AM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: z/OS FTPS Client & Linux FTP server
> >
> > The cipher was one of my early problems. But I figured that one out.
> > vsftpd - ssl_ciphers=RC4-SHA
> > z/OS - CIPHERSUITE SSL_RC4_SHA
> >
> > I'm certain that this Keyring is (part of) my problem. Stumbling
> through
> > RACF I have found that the GoDaddy Root CA is already defined in z/OS,
> but still trying to determine
> > if it is part of a keyring.
> >
> >
> >
> > On Wed, May 7, 2014 at 8:57 AM, Donald J. wrote:
> >
> > > Make sure client and server have a common cipher.
> > > SSL_AES_128_SHA and SSL_AES_256_SHA are probably more commonly used
> > > than SSL_RC4_SHA.
> > >
> > > Make sure the linus root certificate is in your z/OS client keyring.
> > >
> > > --
> > > Donald J.
> > >
> > >
> > >
> > >
> > > --
> > > http://www.fastmail.fm - A no graphics, no pop-ups email service
> > >
> > > --
> > > For IBM-MAIN subscribe / signoff / archive access instructions, send
> > > email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> > >
> >
> >
> >
> > --
> > The postings on this site are my own and don’t necessarily represent
> Mainline’s positions or opinions
> >
> > Mark D Pace
> > Senior Systems Engineer
> > Mainline Information Systems
> >
> > --
> > For IBM-MAIN subscribe / signoff / archive access instructions, send
> email to lists...@listserv.ua.edu
> > with the message: INFO IBM-MAIN
>
> **
> Information contained in this e-mail message and in any attachments
> thereto is confidential. If you are not the intended recipient, please
> destroy this message, delete any copies held on your systems, notify the
> sender immediately, and refrain from using or disclosing all or any part of
> its content to any other person.
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
--
The postings on this site are my own and don’t necessarily represent
Mainline’s positions or opinions
Mark D Pace
Senior Systems Engineer
Mainline Information Systems
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS FTPS Client & Linux FTP server
If you're authorized to issue RACF commands, try SR CLA(DIGTRING) to list defined key rings (format is userid.ringname), then RACDCERT ID(userid) LISTRING(ringname or *) to see the ring(s) contents. Also ensure that the root cert you're interested in has TRUST status (default is NOTRUST). -jc- > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Mark Pace > Sent: Wednesday, May 07, 2014 8:34 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: z/OS FTPS Client & Linux FTP server > > The cipher was one of my early problems. But I figured that one out. > vsftpd - ssl_ciphers=RC4-SHA > z/OS - CIPHERSUITE SSL_RC4_SHA > > I'm certain that this Keyring is (part of) my problem. Stumbling through > RACF I have found that the GoDaddy Root CA is already defined in z/OS, but > still trying to determine > if it is part of a keyring. > > > > On Wed, May 7, 2014 at 8:57 AM, Donald J. wrote: > > > Make sure client and server have a common cipher. > > SSL_AES_128_SHA and SSL_AES_256_SHA are probably more commonly used > > than SSL_RC4_SHA. > > > > Make sure the linus root certificate is in your z/OS client keyring. > > > > -- > > Donald J. > > > > > > > > > > -- > > http://www.fastmail.fm - A no graphics, no pop-ups email service > > > > -- > > For IBM-MAIN subscribe / signoff / archive access instructions, send > > email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > > > > > -- > The postings on this site are my own and don’t necessarily represent > Mainline’s positions or opinions > > Mark D Pace > Senior Systems Engineer > Mainline Information Systems > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, send email to > lists...@listserv.ua.edu > with the message: INFO IBM-MAIN ** Information contained in this e-mail message and in any attachments thereto is confidential. If you are not the intended recipient, please destroy this message, delete any copies held on your systems, notify the sender immediately, and refrain from using or disclosing all or any part of its content to any other person. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS FTPS Client & Linux FTP server
racdcert id(userid) listring(ring.name)
racdcert id(userid) connect(ring(ring.name) LABEL('GoDaddy Root Label')
CERTAUTH usage(CERTAUTH) )
--
Donald J.
On Wed, May 7, 2014, at 06:34 AM, Mark Pace wrote:
> The cipher was one of my early problems. But I figured that one out.
> vsftpd - ssl_ciphers=RC4-SHA
> z/OS - CIPHERSUITE SSL_RC4_SHA
>
> I'm certain that this Keyring is (part of) my problem. Stumbling
> through
> RACF I have found that the GoDaddy Root CA is already defined in z/OS,
> but
> still trying to determine if it is part of a keyring.
>
>
>
> On Wed, May 7, 2014 at 8:57 AM, Donald J. wrote:
>
> > Make sure client and server have a common cipher.
> > SSL_AES_128_SHA and SSL_AES_256_SHA are probably more
> > commonly used than SSL_RC4_SHA.
> >
> > Make sure the linus root certificate is in your z/OS client keyring.
> >
> > --
> > Donald J.
> >
> >
> >
> >
> > --
> > http://www.fastmail.fm - A no graphics, no pop-ups email service
> >
> > --
> > For IBM-MAIN subscribe / signoff / archive access instructions,
> > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> >
>
>
>
> --
> The postings on this site are my own and don’t necessarily represent
> Mainline’s positions or opinions
>
> Mark D Pace
> Senior Systems Engineer
> Mainline Information Systems
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
--
http://www.fastmail.fm - A fast, anti-spam email service.
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS FTPS Client & Linux FTP server
The cipher was one of my early problems. But I figured that one out. vsftpd - ssl_ciphers=RC4-SHA z/OS - CIPHERSUITE SSL_RC4_SHA I'm certain that this Keyring is (part of) my problem. Stumbling through RACF I have found that the GoDaddy Root CA is already defined in z/OS, but still trying to determine if it is part of a keyring. On Wed, May 7, 2014 at 8:57 AM, Donald J. wrote: > Make sure client and server have a common cipher. > SSL_AES_128_SHA and SSL_AES_256_SHA are probably more > commonly used than SSL_RC4_SHA. > > Make sure the linus root certificate is in your z/OS client keyring. > > -- > Donald J. > > > > > -- > http://www.fastmail.fm - A no graphics, no pop-ups email service > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- The postings on this site are my own and don’t necessarily represent Mainline’s positions or opinions Mark D Pace Senior Systems Engineer Mainline Information Systems -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS FTPS Client & Linux FTP server
Make sure client and server have a common cipher. SSL_AES_128_SHA and SSL_AES_256_SHA are probably more commonly used than SSL_RC4_SHA. Make sure the linus root certificate is in your z/OS client keyring. -- Donald J. -- http://www.fastmail.fm - A no graphics, no pop-ups email service -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS FTPS Client & Linux FTP server
On Wed, 7 May 2014 08:25:47 -0400, Mark Pace wrote: >Has anyone successfully sent data to a Linux FTP server using TLS security >from the z/OS FTP client? > Is SFTP an option? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
z/OS FTPS Client & Linux FTP server
Has anyone successfully sent data to a Linux FTP server using TLS security from the z/OS FTP client? I have a Linux server running vsftpd - I've been using it for years to send SMF data. I've added TLS support to this server. I've verified that the Secure connect works via a Filezilla client, So now I would like to be able to send SMF data to the server. But I always get an authentication failure. I've tried every combination of Security parameters I can come up with. These are the latest parms in my ftp.data file. ;SECURE_CTRLCONN SAFE SECURE_DATACONN CLEAR SECURE_FTP REQUIRED SECURE_HOSTNAME OPTIONAL SECURE_MECHANISM TLS SECUREIMPLICITZOS FALSE CIPHERSUITE SSL_RC4_SHA ;KEYRING IBMUSER/SecureFTPKeyRing TLSPORT 21 TLSRFCLEVEL CCCNONOTIFY TLSTIMEOUT 10 ;SECURE_PBSZ 16384 ; ;CTRLCONN 7BIT I'm beginning to think I am doing something fundamentally wrong instead of it being a matter of wrong parameters. //FTP EXEC PGM=FTP,REGION=5M,PARM='(EXIT' //SYSPRINT DD SYSOUT=* //SYSFTPD DD DISP=SHR,DSN=MARPACE.JCL.CNTL(FTPSDATA) //OUTPUTDD SYSOUT=* //INPUT DD * USE LOWER CASE BELOW ftp.s390.mainline.com userid password dir quit EZA1736I FTP (EXIT EZY2640I Using dd:SYSFTPD=MARPACE.JCL.CNTL(FTPSDATA) for local site configuration parameters. EZA1450I IBM FTP CS V2R1 EZA1772I FTP: EXIT has been set. EZA1456I Connect to ? EZA1736I ftp.s390.mainline.com EZA1554I Connecting to: ftp.s390.mainline.com 10.6.0.10 port: 21. EZA2897I Authentication negotiation failed EZA2898I Unable to successfully negotiate required authentication EZA1735I Std Return Code = 1, Error Code = 00017 -- The postings on this site are my own and don’t necessarily represent Mainline’s positions or opinions Mark D Pace Senior Systems Engineer Mainline Information Systems -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
