[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: error/security??
Hi Pat!
> I am working on a new project and find that I am not making contact
> with the web site. (I get a 1 returned)
From the words "contact with the web site, I get a 1 returned" it
sounds like you're working with HTTPAPI. Is that correct? I just want
to make sure we're talking about the same thing, because you also said this:
> c callp ftp_logging(0: *On)
> That should write information to the job log so you can debug the
> problem."
FTP_logging() is a command from FTPAPI. HTTPAPI has a similar feature,
but it's a little different, since HTTP and FTP have different
considerations. Here's what you should code:
callp HTTP_debug(*ON)
The output will be written to an IFS file named /tmp/httpapi_debug.txt
(though, this is configurable).
After HTTPAPI has completed, you can view that file by typing the
following i5/OS command:
DSPF STMF('/tmp/httpapi_debug.txt')
> I get a compile time error with this stating that ftp_logging is not
> defined so I must be missing something.
That would make sense if you're using HTTPAPI, since FTP_logging() is
part of FTPAPI.
> (GSKit) Certificate is not signed by a trusted certificate authority.
>
> It is a secure site and I have set up a simple certificate on the
> calling 400. Any ideas out there?
Creating your own certificate would have no impact on this error. The
key word in the error message is "TRUSTED". In other words, the SSL
engine in i5/OS does not TRUST something.
Bear in mind that i5/OS *always* trusts it's own certificates. (If it
didn't, it wouldn't have let you install the certificate in the first
place!) So you know the error isn't with YOUR certificate.
The error is that your system doesn't trust the certificate it's
downloading when it connects to the web server! Which leads us to a
discussion about how trust works in SSL.
SSL provides security in two ways:
a) It encrypts your data.
b) It verifies the identity of the program you're communicating with.
The second part is just as important as the first part. All of the
security in the world is meaningless if you send the data to the wrong
person. Think about it, you can use a browser to establish an SSL
connection to ANY site on the Internet. SSL will connect to anyone, and
it will make sure that the data is securely transmitted to whomever
you've connected to. But none of that does any good if you aren't
connected to someone you trust!
If I decide to order a book online, and I sent my credit card
information to a site that's only PRETENDING to be Amazon.com, the
cryptography didn't really protect me, did it? My credit card number
was sent very securely -- straight to an imposter who steals people's
credit card numbers.
That's why SSL includes a system of trust. In order to communicate, a
site's SSL certificate must be "signed" by a certificate authority.
Think of "signed" in the way a notary public would sign a legal
document. It's a verification that the site really is who it was
intended to be.
An organization that signs a certificate is said to be a "certificate
authority", i.e. they are the ones vouching that the certificate is
genuine and that the name listed on the certificate is really who will
be receiving your data. Now that they've done that, they have to
provide you with a way for the computer to (cryptographically) verify
that the certificate is really signed by them.
To do that, they issue a special kind of certificate called a
"Cerificate Authority Certificate" (or "CA Certificate" for short). In
order for the SSL manager in i5/OS to trust a certificate, that CA
Certificate must be installed into the digital certificate manager, and
if you're using an ApplicationId, that applicationId must be marked as
"trusting" that CA certificate. Once it's trusted, any certificate
that the CA has signed will be trusted by your program.
Very big CA's, such as VeriSign and Thawte, have their certificates
automatically distributed with i5/OS (and also with the browsers) but
when people issue their own certificates, or when they use a certificate
from a smaller, less common, CA, then it may be not be installed
automatically.
Hope that made sense -- it's very hard to explain.
The error "(GSKit) Certificate is not signed by a trusted certificate
authority" essentially means that the certificate on the web server (not
your side, their side) isn't trusted by your iSeries.
To solve the problem, you need to find out what the correct CA
certificate is and install it. Then your system will trust their
certificate.
-----------------------------------------------------------------------
This is the FTPAPI mailing list. To unsubscribe, please go to:
http://www.scottklement.com/mailman/listinfo/ftpapi
-----------------------------------------------------------------------