Okay, so the answer to my question "what are you trying to do that PARM/SYSFTPD/INPUT does not solve?" is "force FTP to use TLS 1.2, because that is the only variant that seems to work no matter what their RACF/ACF2/TSS configuration is." Is that right?
> without installing certificates used by the FTP server into their > RACF/ACF2/Top Secret databases That is not a condition that you can necessarily solve. The CA that signed your server certificate -- their CA certificate MUST be installed and trusted at the customer site or TLS will not work, and there is no CA certificate that you can be absolutely certain is installed. That is just how TLS works, and the management of which CAs to trust it totally up to customer management. I think DigiCert is your best bet, but it is not a sure thing. An alternative to certificates in RACF/ACF2/TSS you might look into a gskkyman database, but I am not sure you would want to go that route. >From the link you provided I guess you want to use the "native" FTP/SystemSSL >interface rather than AT-TLS. I'm not sure exactly why. I think much of the >point of AT-TLS is getting users out of the TLS configuration business and >letting the magic of AT-TLS handle it. Are you saying you cannot get TLS 1.1 to work? Or are you saying that you or your customers have a security or compliance requirement for TLS 1.2? Or do you just want to be latest and greatest? TLS 1.1 is last year's movie but it is not considered not secure, at least if you are not sending nuclear secrets. Charles -----Original Message----- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Wendell Lovewell Sent: Thursday, September 10, 2020 9:58 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Passing STDENV DD to FTP via SYSIN Hey Charles, I took you seriously the first time. I appreciate your interest in helping. Bottom line, I'd like to come up with a job any z/OS customer could run, without requiring changes to any of their system files (like FTPCDATA or AT-TLS or RACF) that would allow them to transmit files to/from an FTP site using FTPS. I've pretty much given up on that--I can't find a way to do it without installing certificates used by the FTP server into their RACF/ACF2/Top Secret databases. And even with the certificates in RACF, the only way I've gotten it to work is force FTP to use TLS 1.2 by setting the "GSK_PROTOCOL_TLSV1_2" environment variable to "ON" per this URL: https://www.ibm.com/support/pages/zos-communications-server-tls-needed-implement-tls-v12 That page does say for FTP the STDENV dataset should be RECFM=VB. (I did try various combinations of DD *,DCB=(...), including DCB=(RECFM=VB), but JES didn't seem to allow that.) Gil might be on to something with the temporary datasets not being available to spawned processes, but I've cataloged the IEBGENER'd file and the job still fails like it doesn't find the "GSK_PROTOCOL_TLSV1_2=ON" variable. ------------------------------------------------------------------- I'm not sure how to close this out, but as I've been typing this, I did figure out how to get around the STDENV problem. I'm going to go ahead and leave what I've said so far in case someone else comes across this in the future, but here's a work-around: What I was trying to do was: //FTPXFER EXEC PGM=FTP,REGION=4292K, // PARM=('POSIX(ON) ALL31(ON)', // 'ENVAR("_CEE_ENVFILE=DD:STDENV")/(EXIT') //STDENV DD * GSK_PROTOCOL_TLSV1_2=ON //* Where the 'ENVAR("_CEE_ENVFILE=DD:STDENV") is telling LE to look for environment variables in the STDENV DD. The STDENV file wasn't being found, but all it has is one variable name and value. So it occurred to me that I could just put the variable and value in the PARM: //FTPXFER EXEC PGM=FTP,REGION=4292K, // PARM=('POSIX(ON) ALL31(ON)', // 'ENVAR("GSK_PROTOCOL_TLSV1_2=ON")/(EXIT') ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
