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