|
Darrell -- I have had numerous encryption-related problems with the IBM JDK 1.3 on Win2K. I'm using the 5/2/2001 release which is just one release back from the latest release. I kept getting errors like "unknown certificate" when trying to connect. On Win2K, I just moved ibmjsse.jar out of the extensions directory (lib/ext) and replaced it with the Sun JSSE implementation and everything worked fine immediately. This was very frustrating since I had spent hours trying to figure out what was wrong and I couldn't find documentation for the IBM JSSE implementation anywhere to get trace data or something. I would hope that the OS/400 JSSE implementation would use OS/400's underlying SSL support and I'm pretty sure that's the way that it works. I'd imagine that IBM has built in extensive servicability (ie tracing) hooks into the SSL support to keep up with the 400's excellent reliability track record. If I were you and you have a SupportLine contract, I'd contact IBM immediately and report the symptoms after making sure that you have the latest PTFs on. Get to level 2 and I'm pretty confident that you'll find someone who would be delighted to hear of your problems so that they can find and fix them. I don't think there are that many people using the SSL/PKI/Certificate support on the 400 so it's possible there are some bugs lurking. But with Web Services looming on the horizon (that's where I encountered my problem), I'm pretty sure that IBM would want to jump on this immediately. I'm also fairly confident that they have the tools built-in to OS/400 SSL support to trace this pretty closely. As a first step, try this. I'm on v4r5 so things may be different if you're on a different release. Installed extensions are usually installed with a link in /QIBM/UserData/Java400/ext. I'd look in there for any security-related .jars. The javax.net stuff is in jssl.jar. Other suspects are ibmjssl.jar, ibmjcefw.jar, and ibmjceprovider.jar. There may be others as well. Remove these links after noting their attributes. If some of these are actual files and not links, move them to another directory temporarily. Renaming will not help. Then, download Sun JSSE 1.0.2 from the bottom of this page: http://java.sun.com/products/jsse/index-102.html This is a pure java security implementation and should work on the AS/400. First, download it to your PC. Then unzip and install. Follow the installation instructions carefully and ask here if there's anything you don't understand. Move the jar files in the lib subdirectory (jsse.jar, jnet.jar, jcert.jar) to a directory on your 400 using FTP in BINARY mode. Then, create SYMLINKS in /QIBM/UserData/Java400/ext to these three .jars. The security.properties file on my system is in /QIBM/ProdData/OS400/Java400/jdk/lib/security. You'll need to comment out the line with the IBM crypto provider and substitute the one shown in the JSSE documentation. This should work, albeit slower than the native IBM implementation is supposed to work but much faster than it actually works (since anything works better than a broken implementation). If this works for you, and I think it will, you'll (a) have a (slow performing) working solution on your 400, (b) have good ammunition to go to IBM support to find out what's wrong with their implementation. Please keep us posted. I'm dying to know how this comes out. So much for "Write once, run anywhere!" HTH, Gary > Darrell.Kavanagh@newellandbudge.com wrote: > > Blair, > > The servlet is a "black box" to me, supplied by a third party as a jar > file. I have no source to play with. I have spent many hours trying to > get it to work on the AS/400, not helped by all sorts of bugs and > misconfigurations which would have prevented it working on any > platform. I will only say that the suppliers of the servlet (who > provide it as the only means to access a secure database which they > host) have not been overly open or helpful. > > The servlet is communicating with another servlet at the remote site. > The failures all seemed to be in the area of encryption and PKI > certification (x509?). I tried it under JDKs 1.1.8, 1.2.2 and 1.3 on a > V4R5 machine. I was eventually persuaded to try using an NT server > with the Sun JDK - I downloaded Sun JDK 1.3.1 for this exercise. This > worked. I then reverted to IBM JDK 1.2 on the NT machine, which is my > usual NT JDK, and the servlet stopped working. I will probably try the > IBM JDK 1.3 on NT, to get the closest equivalent environment to the > one which has worked. I would love to prove them wrong. > > Thanks for your reply, and any further thoughts would be welcome. > > Darrell > > -----Original Message----- > From: Blair Wyman [mailto:blairw@us.ibm.com] > Sent: 12 July 2001 16:52 > To: JAVA400-L@midrange.com > Subject: Re: Sun JDK on AS400? > > Are you saying that this servlet doesn't work in the AS/400 JVM? ..or > that > you *suspect* it won't work there, because it doesn't work under the > IBM > JREs for Windows or AIX? > > While IBM implemented its own JVM on the AS/400, from scratch, we > already > use the Sun version of the JDK classes (the classes that make up the > java.* > API that are located in rt.jar). > > So, if you haven't tried this servlet on the AS/400 yet, you should. > > (If you can be more specific about the nature of the incompatibility, > there > could be other solutions lurking. There aren't a lot of > incompatibilities > between the vendor JRE versions, but there are certainly some... > Serialization is one area where things get a little dicey.) > > -blair > > Blair Wyman -- iSeries JVM -- (507) 253-2891 > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > "I was born not knowing, and have had only a > little time to change that here and there." -- Richard P. Feynman > > > > > Darrell.Kavanagh@newellan > > dbudge.com To: > JAVA400-L@midrange.com > > Sent by: > cc: > > owner-java400-l@midrange. Subject: Sun > JDK on AS400? > > > com > > > > > > 07/11/2001 11:24 > AM > > Please respond > to > > > JAVA400-L > > > > > > Hi all, > > We are having to use a third party servlet to access a remote > database. Due > to some unique "features" of this servlet, it will not work under the > IBM > JDK/JRE - it must be using some out-of-spec features in the Sun > JDK/JRE. We > are hoping that the developers of this servlet will be able to provide > a > properly compliant version, but in the meantime, is it possible to use > the > Sun JRE on the AS400 an if so, how should I set this up? > > I am using Tomcat 3.2.1 as the servlet engine/web server. On a NT > machine, > the servlet works with Sun JDK 1.3.1, but not IBM JDK 1.2.2 or 1.3. > > Many thanks in anticipation, > > Darrell > > >******************************************************************************** > > This electronic mail system is used for information purposes and is > not intended to form any legal contract or binding agreement. > The content is confidential and may be legally privileged. Access > by anyone other than the addressee(s) is unauthorised and any > disclosure, copying, distribution or any other action taken in > reliance on it is prohibited and maybe unlawful > >******************************************************************************** > > +--- > | This is the JAVA/400 Mailing List! > | To submit a new message, send your mail to JAVA400-L@midrange.com. > | To subscribe to this list send email to JAVA400-L-SUB@midrange.com. > | To unsubscribe from this list send email to > JAVA400-L-UNSUB@midrange.com. > | Questions should be directed to the list owner: joe@zappie.net > +--- +--- | This is the JAVA/400 Mailing List! | To submit a new message, send your mail to JAVA400-L@midrange.com. | To subscribe to this list send email to JAVA400-L-SUB@midrange.com. | To unsubscribe from this list send email to JAVA400-L-UNSUB@midrange.com. | Questions should be directed to the list owner: joe@zappie.net +---
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.