IBM's documentation on this web page: http://publib.boulder.ibm.com/infocenter/wsdoc400/v6r0/topic/com.ibm.websphere.iseries.doc/info/ae/ae/secmigjsse.htm
provides instructions on how to export the certificates from DCM into Java keystores. As they mention below, they've moved away from using the proprietary .kdb keystore format and now support using the standard Java .jks format. "The use of OS/400 *SYSTEM certificate stores (.kdb files) for WebSphere Application Server applications was deprecated in WebSphere Application Server Version 5.x. In Version 6 and later, only Java keystores (.jks files) are fully supported. You must migrate your applications to use Java keystores." "DCM uses PKCS12 format to export client and server certificates, and it uses base64 encoded format to export certificate authority certificates.... However, you must to convert the base64 encoded data from EBCDIC to ASCII format" See the web page for complete instructions, including converting from EBCDIC to ASCII. Cheers! Simba Engineering -----Original Message----- From: James Lampert [mailto:jam...@touchtonecorp.com] Sent: Friday, 05 October, 2012 09:29 To: Tomcat Users List Subject: Re: Not sure what to make of this, Re: bringing up HTTPS on Tomcat Mark H. Wood wrote: > I have no idea what DCM is or does. Maybe it works with PKCS #12 > files, which can carry both parts in a single container. That part isn't really relevant here (I hope), but to clarify: DCM = Digital Certificate Manager. It's part of the IBM Midrange operating system (i.e, "OS/400," "i5OS," or whatever they're calling it this week). It uses an entirely different keystore format from that used by Java and Keytool (and, by extension, Tomcat), and so far as I (and the real IBM Midrange gurus on the various Midrange.com lists) can determine, there's nothing currently available to convert a keystore between the IBM-proprietary format and the Java format. We've had more than one customer who screwed themselves out of a certificate signing fee by failing to appreciate the distinction, even though we do our best to warn them about it. -- JHHL --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
