530 Non-anonymous sessions must use encryption

[Viking]

Hi, I have a process using RPGLE, CLLE, and FTP scripts that uses FTP to go to our webserver to pick up files. Now we are moving the webserver to a different server (at AWS) and the same programs are now unable to log in with FTP. I get the error "530 Non-anonymous sessions must use encryption".

It seems that the new server requires SSL/TLS...? Or...?

I'm in a bit of a hurry to get this working... what can be done, either on the webserver or in my programs (hopefully very easily), to make this work?

Thank you in advance!

[Scott Klement]

Yes, it sounds like it needs TLS unless you're logging in anonymously.

[Viking]

Thanks, Scott. How can I change my regular FTP process to use TLS? What's the easiest/quickest way to connect to this server?

Looking at this IBM link, it seems to say that I need to install a certificate and then do one of three things:
https://www.ibm.com/support/knowledg...zaiqtlsssl.htm

In your experience, is this what I have to do?

[Scott Klement]

Its not clear why you would have to install a certificate? You are FTPing to them, not vice-versa, right?

I'm not completely sure what site you're connecting to, or what its actual requirements are. You said something about AWS, but... who set up and maintains the FTP server that's installed on AWS that you're connecting to? Shouldn't you be talking to that person?

[Viking]

That IBM documentation that I linked to above seems to imply that to use the IBM FTP client over TLS, it needs a certificate added to the certificate store, if I read that correctly.

Correct, the IBM is the client and I'm FTP'ing to a webserver to pick up some files. A similar process drops off a file. It has always worked with our current production webserver.

The new webserver that we'll be switching over to is hosted on AWS (doesn't matter where it's hosted) is set to require TLS. I guess that's more secure, but it makes my current process not work. I am able to use FileZilla to get to the new server with the same credentials I'm using from the IBM batch process.

Yes, I am talking to the people who set up that new webserver, but they don't know how to make my IBM native FTP client work with TLS. So that's why I'm asking for help here.

[Scott Klement]

Oh sorry, i thought you were trying to understand whether TLS was needed, whether a particular certificate is needed, and which of the FTP over TLS modes you'd need to use. If you have this working in FileZilla, you must already know those things, right?

Can you tell us what these requirements are so we can suggest how to do the same thing with the IBM FTP client?

[Viking]

I am not very experienced with this type of configuration, so I don't know that I know those things... What are the different FTP over TLS modes...? Transfer mode is passive (but I don't think my IBM script is even getting that far since it can't login). I can look in my FileZilla configuration to answer specific questions. I know that FileZilla didn't work either until the web developers installed a self-signed certificate on the webserver... then it worked. Does FileZilla automatically download that certificate, but maybe on the IBM we need to specifically install it in the IBM Digital Certificate Manager...?

Looking at the IBM documentation I linked to above, it seems to indicate that I need a certificate in order to do FTP over TLS... do you agree?

[Scott Klement]

You don't need the certificate itself, but you need the Certificate Authority Certificate, and it must be trusted by the FTP Client application. This is probably the hardest part.

Then you'll need to connect. There are three options here:

1. *IMPLICIT = Implicit connection, typically on port 990. This was the "original" way, but is deprecated and you don't see it much anymore.
2. *SSL = Using AUTH. This is what people typically do these days. (SSL is the older name for TLS)
3. *KERBEROS = AUTH with Kerberos. Unlikely to be this from your description.

Technically, there's fourth option where you don't encrypt the control connection at all... but your error message already makes it clear that this isn't wanted, here.

So that option specified whether the control connection was encrypted, which includes exchanging the userid/password as well as all of the FTP commands issued. But, the actual transfer of files and/or directory listings is done in a separate channel, and you can also control whether this is encrypted or not:

1. *CLEAR = means that it is not encrypted
2. *PRIVATE = means that it is
3. *DFT = means to use the default, which is *PRIVATE for TLS connections unless Kerberos is used.
4. *SAFE = is a kerberos-only option, it adds additional integrity protection and makes sure the connection is private.

The most common scenario is option 2 for both things, which would be

FTP RMTSYS('whatever.com') SECCNN(*SSL) DTAPROT(*PRIVATE)

From here it should work just like any other FTP connection, but everything will be protected...

...except that it doesn't always work with NAT gateways or even some firewalls due to the nature of the FTP protocol and how it works with SSL/TLS. So if it doesn't work, you'll be able to log in and get a prompt, and use most commands, but sending/receive files will fail, as will directory listings. If you run into the problem, this can be the most difficult part to fix. This is why most people prefer sftp (the FTP-like interface to SSH) rather than FTP over TLS. SFTP also doesn't require the TLS CA certificate setup. But... since you've already got it working with FileZilla, maybe this is a non-issue.

Hopefully that gives you enough info to get started.