Re: FTP Question(s) -- MIDRANGE-L

Hi Jim,

I'm not sure that I understand what the problem is. You say it "waits after connecting then times out". What does that mean, exactly? Are you able to connect or not?

If you're able to sign in, but unable to get a directory listing or transfer any files (but are able to do other things like change directories, rename files, etc) then the problem is that your data connections aren't making it through a firewall. FTP uses multiple connections, and that particular symptom implies that the control connection (the one in which the signin happens and commands are sent) is working fine, but the data connections (where directory and file information is transferred) are being blocked.

It could also be a symptom of using a NAT gateway with an encrypted control channel. If you're doing that, it most certainly will not work. After signing in, you need to drop encryption on the control channel if your'e behind NAT, otherwise you're screwed. a NAT gateway can't possible decrypt your packets to modify them. This is one of the big reasons why so few shops use FTP over SSL (FTPS), and most are using the FTP-like interface to SSH (sftp) if encryption is required. SSL FTP is notoriously difficult to get working if there are firewalls or NAT gateways involved.

Regarding certificates... I'm not sure that you understand how SSL certificates work. (At least from your description, it doesn't sound like it!) It would be very unusual for the client to be sending a certificate. It's certainly possible to configure that sort of setup, but it's not the norm, and it'd be awfully hard to set up without you realizing you're doing it.

Most likely, there are only two certs involved. Your server certificate (sent from your server) and it's CA certificate, which is not normally transferred, but rather is located on the client's side and is only used to validate your server cert.

The error message you posted says that there's no matching CA cert to validate your server against. Which implies that you generated your own certificate instead of getting it from a public authority like VeriSign. If that's the case, you need to send them your CA certificate, and they need to install it into their application's repository of CA certs so they will trust your server cert.

Though, most apps let you simply click a "trust this site" button in these cases, so installing the CA cert isn't required.

But these problems have nothing to do with what the client is sending...

On 2/24/2010 3:46 PM, Lowary, Jim wrote:

I'm trying to set up an FTP with a vendor and would like to keep it on
our iSeries and I can't get it to work for me. The iSeries FTP just
waits after connecting then times out.

The only PC ftp app that I have been able to get working is "Core FTP
Lite" and I have it set to FTPS (SSL DIRECT) using port 990. When I try
and connect I get a prompt that asks me if I want to accept their
certificate information (once or always). Now this seems to only store
the name and some minimal information somewhere but that is it and no
where it can be exported. I've contacted the vendor and they say they
don't have a Cert that they send out.

So after that long winded explanation here is my question. Is there
some way to get FTP on the iSeries to except their "certificate" (I'm
assuming that is what they are sending one out, but really don't know as
I've not trace the connection to see, and they say they are not).

I didn't know if there was some entry I needed to make for them in the
Digital Certificate Manager. Or since other PC FTP clients don't work
either, is this some FTP option that the iSeries doesn't support?

One other FTP Client gives me this message:

"Peer certificate cannot be authenticated with known CA certificates.
[60] Additional information: SSL certificate problem, verify that the CA
cert is OK. Details:
error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate
verify failed."

Which says to me, that they do have a certificate I have to validate
against, but since I'm not well versed in this I could be totally wrong.

Thanks,
-- Jim