Re: Certificate is not signed by a trusted certificate authority

[Scott Klement <klemscot@xxxxxxxxxxxx>]

Sender: Scott Klement <klemscot@xxxxxxxxxxxx>

> > Your message sounds like the client certificate is signed by your iSeries
> > certificate authority.  What about the server certificate?
>
> Yes the server also.

If the server is also generated from your iSeries CA, wouldn't that mean
that the server is actually running on the same iSeries?  If so, why
bother with HTTP?  Just access the data directly.


> I didn't have the normal CA's like Verisign trusted, but they are now,
> but I am still getting the error message. HTTP server was restarted too.
> Maybe it is on there end.

I thought it was using your iSeries CA?   The problem with the "normal"
CAs is that IBM doesn't include as many of them as you'd get with a Web
browser.

So, a lot of people will set up their Web sites with a different CA
than Thawte or VeriSign because it's quicker or cheaper, but then iSeries
programs get the error that you're experiencing.

The solution is relatively simple -- get the CA certificate from the
issuer and install it on your iSeries, and mark it as trusted.


> Is there a log file I can look for more info?

Yes... In version 1.10 and earlier of HTTPAPI, you can configure a log
file by changing the values in CONFIG_H.  Near the botton there's a
setting where you have to define the DEBUG compiler condition, and set the
filename to where you want it to write the log to (in the IFS)

I don't know if the log file will tell you anything you don't already
know, however.

In version 1.11 (which is still currently under development) I added more
debugging info for SSL certificates that may or may not be helpful for
this. You can grab a pre-release of version 1.11 from my site:

SAVF: http://www.scottklement.com/httpapi/beta/1.11pre2/httpapi.savf
XML:  http://www.scottklement.com/httpapi/beta/1.11pre2/httpapi.xml
ZIP:  http://www.scottklement.com/httpapi/beta/1.11pre2/httpapi.zip

(Follow the same download/install instructions that you used for version
1.10)

Another really helpful thing when debugging SSL errors is to use the
openssl command-line tool.  This would be a program you run on your PC
that you can use to get a dump of various things that go on in an SSL
connection. Among other things, you can see the certificates that are
being sent, you can see the DN info from the certificates, etc.

This openssl command-line tool is packaged with most versions of Linux,
*BSD, etc.  Their Web site is http://www.openssl.org

I've put a pre-compiled .EXE file of the openssl command-line tool for
Windows (you run it from a command-prompt/MS-DOS prompt) on my Web site at
the following link, if you want to try it out:

   http://www.scottklement.com/tools/openssl.exe

When you run it, issue the following commands from your command prompt:

  cd \dir\where\you\saved\the\file
  openssl s_client -showcerts -connect www.klements.com:443

It's not specifically an HTTP tool, it works with any/all SSL protocols,
so you do have to specify a host name a port number rather than a URL.
When you're done looking at the info, hit Ctrl-C to exit.

For www.klements.com (my company's web server) the certificate chain looks
like this:
Certificate chain
  0 s:/CN=www.klements.com/OU=Domain Validated/OU=Go to https://www.thawte.com/repository/index.html/OU=Thawte SSL123 certificate/O=www.klements.com
    i:/C=ZA/O=Thawte Consulting (Pty) Ltd./CN=Thawte SSL Domain CA

The CN is www.klements.com, which means that it's a certificate that was
verified by a CA for the particular site that I'm connecting to.  The
issue (i:) is Thawte Consulting. In order for the SSL engine to know
whether it trusts www.klements.com, it has to know if it trusts "Thawte
SSL Domain CA" (the CN of the issuer)

Later on in the OpenSSL output for my site, I find this:

 1 s:/C=ZA/O=Thawte Consulting (Pty) Ltd./CN=Thawte SSL Domain CA
   i:/C=ZA/ST=Western Cape/L=Cape Town/O=Thawte Consulting cc/OU=Certification Services Division/CN=Thawte Server CA/emailAddress=server-certs@xxxxxxxxxx

So that's where it's checking to see if it trusts "Thawte SSL Domain CA".
THAT certificate was issued by the "i:" line in that block. This "chain of
certificates" can keep going...  ultimately, the LAST certificate in the
chain has to be one that's installed in your digital certificate manager.
In this case, there are only these two, so "Thawte Server CA" has to be
installed in the DCM.

The certificates aren't matched up by name, unfortunately, but by an
encrypted number within the certificate itself. So, it's possible that the
name on the iSeries won't be an exact match. But, this does give you a
good idea of how certificates work, and it can be very helpful in
diagnosing problems.

-----------------------------------------------------------------------
This is the FTPAPI mailing list.  To unsubsribe from the list send mail
to majordomo@xxxxxxxxxxxxx with the body: unsubscribe ftpapi mymailaddr
-----------------------------------------------------------------------