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



It makes perfect sense, but the server folks told my client that any public
certificate could be used.

Her quote:
"I have asked them for the certificate but they told me I could use any
public certificate. I am sending the file using a pc FTP application and it
works. But, I want to send the file directly from the iSeries."

I must be missing something here.

Paul Nelson
Cell 708-670-6978
Office 512-392-2577
nelsonp@xxxxxxxxxxxxx


-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Scott Klement
Sent: Wednesday, December 12, 2007 12:37 PM
To: Midrange Systems Technical Discussion
Subject: Re: SSL FTP question

Paul,

With SSL, there's a certificate that states that a server really is the
server it claims to be. Then, there's a certificate authority (CA)
certificate that tells you WHO determined that a system really is who it
claimed to be. In other words, who verified the facts?

Think of a CA certificate as like a notary public, verifying that a
signature (or "certificate") is genuine. Now imagine a world with rogue
notarys... You have to determine who to trust, and who not to trust. If
you trust a certificate authority, you implicitly trust all certificates
that it has signed.

In your example, your FTP client is connecting to a server. One of the
very first things that happens is that the FTP client receives the
server's certificate. (It's downloaded from the FTP server to the FTP
client.) In order for the client to know whether it trusts the server,
it checks to see which signed it. If the CA that signed it is installed
in your digital certificate manager, and marked as "trusted" in the
application profile for the FTP client, then the SSL connection will
continue (and hopefully succeed). However, if the CA certificate isn't
installed, or isn't marked as "trusted", then you'll get the
"certificate is not signed by a trusted certificate authority" error --
which is what you have.

Your message states "I'm pretty sure I told the DCM to sign the
certificate as a trusted authority" -- which would only make sense if
you're connecting to the same machine. If you're connecting to a
different computer (which seems likely) then the certificate would've
been signed on THAT computer, or would've been signed by an external
certificate authority. In either case, you need to get the CA
certificate for that certificate authority and install it into the DCM
on the machine where you're running the FTP client. And you may also
need to mark it as "trusted" in the Application Definition (depending on
whether the FTP client is currently set up as "trust all" or not.)

Does that make sense?




Paul Nelson wrote:
Secure connection error, return code -23.

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


Is this message issued by my machine or by the target machine when I
try to connect with PORT(990) SECCNN(*IMPLICIT) ?

I'm pretty sure I told the DCM to sign the certificate as a trusted
authority.

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

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.