|
Well I had this problem a couple months back: The documentation has a typo. I don't know if it will fix your problem but you MUST fix this: ssl.ServerSocketFactory.provider=com.sun.net.ssl.internal.ssl.SSLServerSocke tFactoryImp It must have an l on the end!! SSLServerSocketFactoryImpl Kristen -----Original Message----- From: java400-l-bounces@xxxxxxxxxxxx [mailto:java400-l-bounces@xxxxxxxxxxxx] On Behalf Of John Knox Sent: Tuesday, June 14, 2005 5:19 PM To: java400-l@xxxxxxxxxxxx Subject: RE: Verisign Payflow Pro Hi Paul. New environment, definitely! Thanks for the explanation of classpath. I guess I had already figured that out, but was sure going on some information in the Developers Kit manual that referred to something otherwise. Maybe I'm just stuck in the days of the DOS PATH command and assumed CLASSPATH would work similar. The security provider part of my java.security file looks like this after the modifications specified in the Payflow Pro documentation. I basically just added the first two lines for sun lines at the top and resequenced the existing security.provider records. security.provider.1=sun.security.provider.Sun security.provider.2=com.sun.net.ssl.internal.ssl.Provider security.provider.3=com.ibm.crypto.provider.IBMJCE security.provider.4=com.sun.rsajca.Provider security.provider.5=com.ibm.security.cert.IBMCertPath security.provider.6=com.ibm.as400.ibmonly.net.ssl.Provider security.provider.7=com.ibm.jsse.IBMJSSEProvider security.provider.8=com.ibm.security.jgss.IBMJGSSProvider Now granted, this is under the assumption Java is using the java.security in the path /QIBM/ProdData/Java400/jdk14/lib/security. I do have 3 versions of jdk on my system: 1.18, 1.2, 1.4. However, since running a JAVA *VERSION tells me I'm running 1.4, I feel somewhat (?) safe it's looking at the right security file. Also, based on the IBM knowledgebase article at http://www-1.ibm.com/support/docview.wss?uid=nas1f2696335784feedb86256e4 50020e015&rs=110 I modified the other part of the security file like this: os400.jdk14.jst.factories=true ssl.SocketFactory.provider=com.sun.net.ssl.internal.ssl.SSLSocketFactory Impl ssl.ServerSocketFactory.provider=com.sun.net.ssl.internal.ssl.SSLServerS ocketFactoryImp But I'm still stuck with this error in the Verisign app: RESULT=-31&RESPMSG=The certificate chain did not validate, no local certificate found. It's almost like it doesn't see a certificate, but according to Verisign's documentation, the cert file is right where it's supposed to be. I'm wondering if something in Java is still not configured right. I found some information somewhere about importing a certificate using the keytool utility so it would be in the cacerts file which I found in the same directory as java.security, but I'm not sure if that really applies to me. Thanks for any input. I'll get good at this new environment yet! -----Original Message----- date: Mon, 13 Jun 2005 15:31:39 -0400 from: "Paul Morgan" <pmorgan@xxxxxxxxxxxxxx> subject: Re: Verisign Payflow Pro John, You have a misunderstanding of how a Java classpath works equivalent to someone not understanding how an OS/400 library list works. You've fixed the problem with the classpath by including jar files in the class path. Just listing the directory the jar files were in wasn't enough. Java needs to find classes and a Jar file is just another directory. By just listing the directory the jar files was like only have QSYS in your library list and expecting access to all your libraries (they are all in QSYS so shouldn't that be enough?). You said you modified the java.security file yet you say the right security provider is in your java.security file. I'd suspect you haven't specified that parameter in the java.security file correctly. I'd take a real hard look at any changes you might have done to the java.security file. How about posting the security provider entry in your java.security file so we could take a look at it and see if it's got a problem. Tail chasing or learning a new environment? Paul
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.