× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



I can't connect thru the iSeries FTP after I enter this command:
FTP RMTSYS(*INTNETADR) INTNETADR('74.112.20.22') PORT(990) SECCNN(*SSL)

I get:

Connecting to remote host xxx.xxx.xxx.xxx using port 990. On the screen
and it set until it times out (actually I have to cancel it).

From the PC Client that I can get to work I get:

Started on Thursday February 25, 2010 at 07:23:AM
Connect socket #680 to xxx.xxx.xxx.xxx, port 990...
TLSv1, cipher TLSv1/SSLv3 (AES256-SHA) - 256 bit
USER uuuuuuuuuu
331 Password required for uuuuuuuuuu.
PASS **********
230 Login OK. Proceed.
SYST

If in the PC client I go to their Manage menu and select SSL/SSH
Certificates and remove their "certificate" or record there of. When I
try and connect it pops up a window for me to accept their "certificate"
right after the " Connect socket #680 to xxx.xxx.xxx.xxx, port 990..."
message in the log. That is why I was saying they were sending
something.

If I change the SECCNN to (*IMPLICIT) which I hadn't tried before and
use this command:

FTP RMTSYS(*INTNETADR) INTNETADR('74.112.20.22') PORT(990)
SECCNN(*IMPLICIT)

Then I get:

Connecting to remote host 74.112.20.22 using port 990.
Secure connection error, return code -23.

Where the -23 is:
-23 Certificate is not signed by a trusted certificate authority.

So from all this I was saying I thought they were sending me some sort
of Certificate, but since I'm really not sure what I'm doing with Certs
and FTP; I could be all wet and obviously don't have a clue one about
this. That is why I asked them for a certificate to import thinking,
from what I saw THAT they were sending me one, but they say they don't
send one.

I did do a Comm Trace this morning and it appears they are sending
something, as I get an 847 byte block of data. Which when I print using
*ASCII I can see what the PC Client is putting up asking me to accept as
a certificate.

Humm... I'm still confused


As for using the PC Client and FTP'ing out of the IFS, yes I could do
that, but if the iSeries can do this then I'd like to keep it all on the
"I". Just call me an "i" bigot ;-) but if is doable I might as well
learn how to do it. If not then a one liner that Client Eastwood said,
"A man has to know his limitations!", comes to mind. (not that using
the PC app isn't a valid approach, it is. It's just not my first pick.)

Thanks,
-- Jim



-----Original Message----- from: Scott Klement

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...


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.