Re: SSL Certificate Failures

Oh.  I almost forgot to mention.  Many thanks to Patrick Botz for taking
the time to assist with this issue.

Gary

Gary L Peskin wrote:
> 
> 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
> _______________________________________________
> This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
> 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