× 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 have solved this knotty problem.  It turns out not to have anything to
do with SSL 2.0.  Rather, it has to do with a difference between the way
that IBM handles certificate chains and the way that Sun does.

First, I've established that IBM uses the certificates in DCM for its
SSL support.  Any jssecerts, cacerts, or file specified in
javax.net.ssl.trustStore is ignored.  In addition, you can manipulate
these keystores to your heart's content with keytool but none of them
are used by the SSL support.  Only the DCM certificates are used.

Second, is the difference between the way the TrustManagers work.  I
visited a site (https://banking.wellsfargo.com) that has the following
certificate chain:

   CA-1 Root CA
    | - CA-2 Another CA signed by CA-1
         | - The server certificate signed by CA-2

In the Sun (and every other) implementation, the TrustManager looks for
the server certificate in the keystore.  If found, the certificate is
good.  If not, we look at the signer's certificate.  In this case,
that's CA-2.  If that's found in the keystore, the certificate is good
and we continue.  Otherwise, we look for -its- signer's certificate.  In
this case, it's a Verisign Root Certificate that is found so we're
allowed to continue.  In other words, we keep going up the chain until
we find a good (or bad) certificate.  If we pop off the top of the chain
without finding a trusted certificate in our keystore, the server
certificate is not accepted.

In the IBM implementation, however, it seems that the default
TrustManager only looks at the certificate of the server and its
immediate signer.  It won't go further up the chain to find a
certificate in DCM.  Therefore, you need to add all immediate signers to
DCM.  This is sort of a pain but I suppose it also gives you greater
control over who you'll trust.  It would be nice if the IBM algorithm
conformed to standards and worked like everybody else (see RFC 2459,
section 6).  Failing that, it would be nice if the algorithm was
documented.  It may be documented somewhere but certainly not anywhere
that I could find in the v5r1 Information Center.

It is possible that I am wrong and that the IBM implementation conforms
to the standard and found something wrong with one of the certificates,
making it a bad certificate.  However, nothing indicated that to me and
my Sun implementation and IE and Netscape all process it just fine.

The setting of javax.net.debug in the reference implementation is pretty
crude.  But it is LIGHT YEARS ahead of the absence of any tracing in
OS/400.  It's impossible to tell what keystore is used, what the
operating system thinks the certificate chain looks like or what it's
done with what certificate.  This tracing may be available somewhere
but, again, I couldn't find it.  It's so easy to do in the reference
implementation and even I can understand the output.  IBM should be
ashamed of itself.  On a platform like the AS/400/iSeries which
emphasizes RAS, this should be built right in to the SSL support. 
Understandable traces in this confusing area should be made available to
customers and developers.

Well, if anyone has questions on SSL in java on the 400, I'll try to
help.

Gary

Gary L Peskin wrote:
> 
> I have a Java client application trying to open a secure socket to an
> SSL 2.0 web server.  I'm unable to get a successful handshake with the
> server even though I can connect fine from my browser.
> 
> In java, the relevant part of the stack trace looks like this:
> 
> javax.net.ssl.SSLPeerUnverifiedException: peer not authenticated
>     java/lang/Throwable.<init>(Ljava/lang/String;)V+4 Throwable.java:90)
> 
>com/ibm/as400/ibmonly/net/ssl/SSLSessionImpl.getPeerCertificateChain()[Ljavax/security/cert/X509Certificate;+47
> (SSLSessionImpl.java:247)
>     <my application follows>
> 
> I have DCM installed as well as AC3 and I have created the *SYSTEM
> certificate store.  I haven't set up any kind of client application
> under the DCM "Manage Applications" section but I can't see why that
> should be necessary.  Is it?  I just want my client to trust all CAs
> that are enabled.
> 
> All of the supplied CA certificates are marked enabled and one of them
> is the parent of the certificate that signed the server's certificate.
> 
> I did a TRCCNN and got the following messages:
> 
> 1.  From AS/400 client to server:  CLIENT-HELLO.  This looks fine.
> 2.  From server to AS/400:  SERVER-HELLO.  This also looks fine.  It is
> an SSL 2.0 SERVER-HELLO.
> 3.  From AS/400 client to server:  The following message is sent (in
> hex):
> 
>       8003 000004
> 
> I looked this up and it indicates an SSL_PE_BAD_CERTIFICATE error as
> defined by the SSL 2.0 protocol.
> 
> Can I find out why the AS/400 thinks the certificate is bad?  There is
> some mention in the information center of a flight recorder for SSL but
> I don't know how to access it or interpret it.  Will it show me exactly
> why the server's certificate is not being accepted?
> 
> Anyone ideas on what I can do to find out exactly why I'm unable to
> complete the SSL handshake would be appreciated.
> 
> Thanks,
> Gary
> _______________________________________________
> This is Midrange Systems Technical Discussion (MIDRANGE-L)
> To post a message email: MIDRANGE-L@midrange.com
> To subscribe, unsubscribe, or change list options,
> visit: http://lists.midrange.com/cgi-bin/listinfo/midrange-l
> or email: MIDRANGE-L-request@midrange.com


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.