× 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.



It was a trustStore problem. Turns out we had overlooked that were
trying to use the native iSeries provider
(com.ibm.as400.ibmonly.net.ssl.Provider) instead of the pure java
provider (com.ibm.jsse.IBMJSSEProvider).

We switched the two around in java.security and added the certificates
to the jks file configured in the websphere instance and everything
turned out fine.

On Mon, 11 Oct 2004 17:01:44 -0500, Frances Stewart <francess@xxxxxxxxxx> wrote:
> I forwarded your question to a person more knowledgeable than I am in this
> area.
> His reply:
> With "Certificate Unknown" errors, this means that a signer certificate for
> the CA (certificate authority) who signed the server's certificate is not
> in the client's trust base (certificate store).  Causes are:
> 
>    the wrong signer certificate was added to the client's certificate store
>    the signer certificate was added to the wrong certificate store
> 
> If Seth has verified that the correct certificate is contained in cacerts,
> then the conclusion is that cacerts is not the client's certificate store.
> 
> Typically, confusion over what certificate store the client is using occurs
> when default socket factories are used.  If Seth has an application running
> in WAS,  the application does JNDI to connect to an LDAP server, and the
> default socket factory is used to get the connection, then the default
> socket factory may be using some other certificate store.  Check to see if
> an application is setting the Java system property
> javax.net.ssl.trustStore, or that javax.net.ssl.trustStore is configured
> for the application server's Java Virtual Machine Process Definition.
> 
> Also, this WebSphere Application Server security FAQ may apply:
> 
>  "Application Throws SSLHandShakeException after Installing Version 5.0.2
> or 5.1.0" at http://www-912.ibm.com/s_dir/slkbase.NSF/wsadv?OpenView&view
> 
> Frances Stewart
> WebSphere Application Server for iSeries
>     External web site: http://www.iseries.ibm.com/websphere
> IBM Rochester
> 
>              Seth
>              <sethmreagan@gmai
>              l.com>                                                     To
>              Sent by:                  "java400-l@xxxxxxxxxxxx"
>              java400-l-bounces         <java400-l@xxxxxxxxxxxx>
>              +francess=us.ibm.                                          cc
>              com@xxxxxxxxxxxx
>                                                                    Subject
>                                        JNDI, SSL, and Websphere problem on
>              10/11/2004 01:21          AS/400
>              PM
> 
>              Please respond to
>              Java Programming
>              on and around the
>               iSeries / AS400
> 
> 
> 
> 
> I am using JNDI to connect to a Sun One Directory Server from
> Websphere. It works fine when running Websphere on our developer
> (windows-based) workstations but when we put it on the 400 it gets
> into an (seemingly) infinite loop. We looked at the network traffic
> through a sniffer and it just keeps repeating itself even after an ssl
> ALERT (Level: Fatal, Description: Certificate Unkown) pops up.
> 
> The message that keeps repeating complains about an incorrect checksum...
> 
> We have verified that:
> 1.) we are using the 1.3 jvm.
> 2.) the certificate is imported into the cacerts file of said jvm.
> 3.) both environments (workstation and server) are using the
> com.ibm.jsse.IBMJSSEProvider
> 
> Can anyone help?
> 
> Here is the beginning of one of the logs which proves a couple of the
> assertions that I have made:
> 
> WebSphere Platform 5.0 [ND 5.0.2 ptf2M0325.01] [BASE 5.0.2
> ptf2M0325.01] [CLIENT 5.0.2 ptf2M0325.01]  running with process name
> S02T
> Host Operating System is OS/400, version V5R1M0
> Java version = 1.3.1, Java Compiler = jitc_de, Java VM name = Classic
> VM
> was.install.root = /QIBM/ProdData/WebAS5/Base
> user.install.root = /QIBM/UserData/WebAS5/Base/default
> Java Home = /QIBM/ProdData/Java400/jdk13
> ws.ext.dirs =
> /QIBM/ProdData/WebAS5/Base/java/tools:/QIBM/UserData/WebAS5/Base/default/classes:/QIBM/ProdData/WebAS5/Base/classes:/Q
> 
> Classpath =
> /QIBM/UserData/WebAS5/Base/default/properties:/QIBM/ProdData/WebAS5/Base/properties:/QIBM/ProdData/WebAS5/Base/lib/boots
> 
> Java Library path =
> /QSYS.LIB/QEJBAS5.LIB:/QSYS.LIB/QGPL.LIB:/QSYS.LIB/QTEMP.LIB:/QSYS.LIB/WEBTOOLS.LIB:/QSYS.LIB/WSTOOLS.LIB:/QSYS.
> 
> Current trace specification = *=all=enabled
> --
> This is the Java Programming on and around the iSeries / AS400 (JAVA400-L)
> mailing list
> To post a message email: JAVA400-L@xxxxxxxxxxxx
> To subscribe, unsubscribe, or change list options,
> visit: http://lists.midrange.com/mailman/listinfo/java400-l
> or email: JAVA400-L-request@xxxxxxxxxxxx
> Before posting, please take a moment to review the archives
> at http://archive.midrange.com/java400-l.
> 
> --
> This is the Java Programming on and around the iSeries / AS400 (JAVA400-L) 
> mailing list
> To post a message email: JAVA400-L@xxxxxxxxxxxx
> To subscribe, unsubscribe, or change list options,
> visit: http://lists.midrange.com/mailman/listinfo/java400-l
> or email: JAVA400-L-request@xxxxxxxxxxxx
> Before posting, please take a moment to review the archives
> at http://archive.midrange.com/java400-l.
> 
>

As an Amazon Associate we earn from qualifying purchases.

This thread ...

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.