|
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
As an Amazon Associate we earn from qualifying purchases.
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.