He is using TLSMECHANISM ATTLS. Yours uses TLSMECHANISM FTP (non-Pagent). He is getting the error because he has no PAGENT TTLSRule for Outbound Port 21. Suggest you turn on DEBUG ALL in your FTP.DATA file while debugging.
It is working ok for me with TLSMECHANISM FTP. I tried with ATTLS, but am getting a server error on the BINARY FTP SUBCOMMAND. Still looking in to that, but it is questionable if their FTPS server works with PAGENT ATTLS. Can't imagine why they would install a server incompatible with PAGENT though. >>> TYPE I SC3261 getReply: entered SC4327 getNextReply: entered with waitForData = TRUE Connection with dispby-117.boulder.ibm.com terminated SC4445 SETCEC code = 10 CZ1434 ftpClose: entered SC4067 inSession: entered SC4145 setLoggedIn: entered CT0282 binary: getReply failed. PC1047 logClientErrMsg: entered PC0945 setClientRC: entered SC4019 getLastReply: entered PC1015 setClientRC: std_rc=06000, rc_type=CEE, rc=1006 SRECTIV3 FTP failed - Cmd = 6(binary) Reply = n/a EX CEE RC = 1006 SC4019 getLastReply: entered CX0389 main: RC=-0001 cmd_in_progress=06 CX0392 main: last_reply= err=10 PC0945 setClientRC: entered SC4019 getLastReply: entered Std Return Code = 06000, Error Code = 00010 CZ1354 ftpQuit: entered CZ1434 ftpClose: entered Their server also seems to require use of the CCC subcommand to clear the command channel. So if you are using SECURE_CTRLCONN PRIVATE instead of SECURE_CTRLCONN CLEAR, it might cause a problem also. There is a client parameter setting ftpccc="no" to make the server quit using CCC, but that seems to cause a problem also. Use of KEYRING *AUTH*/* should be sufficient for the FTPS portion of the job. The server web site also uses root certificate "GeoTrust Global CA" which has its share of issues also. See: http://security.stackexchange.com/questions/53231/google-certificates-correct-ca/53271#53271 Openssl s_client reports the server cert chain to be: Certificate chain 0 s:/C=US/ST=New York/L=Armonk/O=INTERNATIONAL BUSINESS MACHINES CORPORATION/CN=deliverycb-bld.dhe.ibm.com i:/C=US/O=GeoTrust Inc./CN=GeoTrust SSL CA - G3 1 s:/C=US/O=GeoTrust Inc./CN=GeoTrust SSL CA - G3 i:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA 2 s:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA i:/C=US/O=Equifax/OU=Equifax Secure Certificate Authority 3 s:/C=US/O=Equifax/OU=Equifax Secure Certificate Authority i:/C=US/O=Equifax/OU=Equifax Secure Certificate Authority -- Donald J. [email protected] On Thu, Mar 10, 2016, at 06:45 AM, Jousma, David wrote: > I had to come up with some alternate FTP client parms to make it work. > Possibly the one you are getting stuck on is this. Change FtpSecur to your > keyring name. this member happens to live in our SYS1.TCPPARMS dataset, but > the member can be anywhere, just gotta point to wherever it lives in your > RECEIVE ORDER job. > //CLIENT DD * > <CLIENT > javahome="/opt/fitb/java/Jre" classpath="/usr/lpp/smp/classes"> > <FTPOPTIONS> > -v -f "//'SYS1.TCPPARMS(FTPSECUR)'" > </FTPOPTIONS> > </CLIENT> > /* > > EDIT SYS1.TCPPARMS(FTPSECUR) - 01.01 Columns > 00001 00080 . > Command ===> Scroll > ===> CSR . > 000642 ;CIPHERSUITE SSL_AES_256_SHA ; 35 > . > 000643 > . > 000644 KEYRING FtpSecur ; Name of the keyring for TLS > . > 000645 ; It can be the name of an HFS > . > 000646 ; file (name starts with /) or > . > 000647 ; a resource name in the security > . > 000648 ; product (e.g., RACF) > . > > _________________________________________________________________ > Dave Jousma > Assistant Vice President, Mainframe Engineering > [email protected] > 1830 East Paris, Grand Rapids, MI 49546 MD RSCB2H > p 616.653.8429 > f 616.653.2717 > > -----Original Message----- > From: IBM Mainframe Discussion List [mailto:[email protected]] On > Behalf Of Gibney, David Allen > Sent: Wednesday, March 09, 2016 7:47 PM > To: [email protected] > Subject: Re: (External):Re: IBM secure z/OS software delivery: Don't get > locked out! > > Repeating the earlier msg. > Ok, so I am trying to use ATTLS for FTPS.. My RECEIVEORDER log goes: > > /bin/ftp -e deliverycb-bld.dhe.ibm.com > > Using 'GIBNEY.FTP.DATA' for local site configuration parameters. > Using //'TCPIP.STANDARD.TCPXLBIN' for FTP translation tables for the control > con > nection. > > Using //'TCPIP.STANDARD.TCPXLBIN' for FTP translation tables for the data > connec > tion. > > IBM FTP CS V1R13 > > FTP: using TCPIP > > FTP: EXIT has been set. > > Using catalog '/usr/lib/nls/msg/C/ftpdmsg.cat' for FTP messages. > > Connecting to: dispby-117.boulder.ibm.com 170.225.15.117 port: 21. > > 220-IBM's internal systems must only be used for conducting IBM's > > 220-business or for purposes authorized by IBM management. > > 220- > > 220-Use is subject to audit at any time by IBM management. > > 220- > > 220 dhebpcb01 secure FTP server ready. > > 15:19:59(000005BD.4) FC0255 ftpAuth: security values: mech=TLS, > tlsmech=ATTLS, s > FTP=A, sCC=C, sDC=P > 15:19:59(000005BD.4) FC2704 ftpAuthAttls: No AT-TLS policy matched connection > Authentication negotiation failed > NAME (deliverycb-bld.dhe.ibm.com:GIBNEY): > > > S042242j > >>> USER S042242j > > The Geotrust cert is in my keyring: > RACDCERT ID(GIBNEY) listRING(FTPClientRing) > > Digital ring information for user GIBNEY: > > Ring: > >FTPClientRing< > Certificate Label Name Cert Owner USAGE DEFAULT > -------------------------------- ------------ -------- ------- > > GeoTrust Global CA CERTAUTH CERTAUTH NO > > > -----Original Message----- > > From: IBM Mainframe Discussion List [mailto:[email protected]] > > On Behalf Of Jesse 1 Robinson > > Sent: Wednesday, March 09, 2016 4:38 PM > > To: [email protected] > > Subject: Re: (External):Re: IBM secure z/OS software delivery: Don't > > get locked out! > > > > > > > > . > > . > > . > > J.O.Skip Robinson > > Southern California Edison Company > > Electric Dragon Team Paddler > > SHARE MVS Program Co-Manager > > 323-715-0595 Mobile > > 626-302-7535 Office > > [email protected] > > > > > > -----Original Message----- > > From: IBM Mainframe Discussion List [mailto:[email protected]] > > On Behalf Of Gibney, David Allen > > Sent: Wednesday, March 09, 2016 2:46 PM > > To: [email protected] > > Subject: (External):Re: IBM secure z/OS software delivery: Don't get locked > > out! > > > > AS noted in my reply a day or so ago, I am successfully submitting the > > RECIEVEORDER securely (at least I think I am, it fails when the > > certificate > > expires:)) But, then when it fires up FTPS to retrieve the package, > > the TLS (or AT- > > TLS) handshake fails. > > > > > -----Original Message----- > > > From: IBM Mainframe Discussion List > > > [mailto:[email protected]] On Behalf Of Kurt Quackenbush > > > Sent: Wednesday, March 09, 2016 2:38 PM > > > To: [email protected] > > > Subject: Re: IBM secure z/OS software delivery: Don't get locked out! > > > > > > > ... I'm only mildly concerned about the keyring name, as we use a > > > > totally different name associated with SMP/E, not with Java. That > > > > keyring works fine today. > > > > > > If you're already downloading securely, then you can continue to use > > > your same keyring. My example in the article was simply that, an > > > example, which uses the default Java truststore instead of a > > > security manager > > (RACF) keyring: > > > > > > <CLIENT > > > downloadmethod=”https” > > > downloadkeyring=”javatruststore” > > > javahome="/usr/lpp/java/J6.0" > > > > > > > </CLIENT> > > > > > > I call this the "Fast Path" because for someone that is not already > > > downloading securely, then using HTTPS with the Java truststore is > > > the quickest and simplest choice because you don't need to mess > > > around with keyrings or a security manager product at all. > > > > > > If anyone is interested, more details can be found here: > > > https://urldefense.proofpoint.com/v2/url?u=http- > > > 3A__www.ibm.com_support_knowledgecenter_SSLTBW- > > > > > 5F2.2.0_com.ibm.zos.v2r1.gim3000_dsetups.htm&d=CwIDaQ&c=C3yme8gMkx > > > g_ihJNXS06ZyWk4EJm8LdrrvxQb- > > > > > Je7sw&r=u9g8rUevBoyCPAdo5sWE9w&m=vkv4CpLe_hygd7rNmto_QCrcBflG_Y > > > A6s0g2dvojUTE&s=K3EXMlACn-O47e9WLTyXIE2I_lbl-1mZlh3MS3oFSGo&e= > > > > > > Kurt Quackenbush -- IBM, SMP/E Development > > > > > > -------------------------------------------------------------------- > > > -- For IBM-MAIN subscribe / signoff / archive access instructions, > > > send email to [email protected] with the message: INFO > > > IBM-MAIN > > > > ---------------------------------------------------------------------- > > For IBM-MAIN subscribe / signoff / archive access instructions, send > > email to [email protected] with the message: INFO IBM-MAIN > > > > ---------------------------------------------------------------------- > > For IBM-MAIN subscribe / signoff / archive access instructions, send > > email to [email protected] with the message: INFO IBM-MAIN > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, send email to > [email protected] with the message: INFO IBM-MAIN > > This e-mail transmission contains information that is confidential and may be > privileged. It is intended only for the addressee(s) named above. If you > receive this e-mail in error, please do not read, copy or disseminate it in > any manner. If you are not the intended recipient, any disclosure, copying, > distribution or use of the contents of this information is prohibited. Please > reply to the message immediately by informing the sender that the message was > misdirected. After replying, please erase it from your computer system. Your > assistance in correcting this error is appreciated. > > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [email protected] with the message: INFO IBM-MAIN -- http://www.fastmail.com - Access all of your messages and folders wherever you are ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
