We need to sign JSSE 1.0.2 jars so WS clients can download and use them. Normally, we sign jar usings our commercial certificate and Netscape's signtool, however this problem occurs whether I use signtool or Sun's jarsigner. Problem: Signed JSSE jars download and verify correctly, but upon the first attempt to negotiate an HTTPS connection, we fail with the exception shown below. This is not JNLB/WS -specific, the signed jars will cause the failure with or without the use of WS. However, I'm posting here since somebody must have run into this when preparing JSSE jars for use with JNLP/WS. Note that I have verified that y.class is in the signed jar and it is the same size as the in the original jsse.jar. Has anyone run into this?
posted 14 years ago
OK, so I'll answer my own question... This is a case-sensitivity issue. Java identifiers are case-sensitive. The RSA JSafe code in the jsse.jar is in a package rooted at "COM" vs. the traditional lower-case "com". If you unpack the jar on a operating system with a *real* filesystem, the package structure is preserved. If you unpack it on an MS Windows system, you lose. At runtime, JSSE internal classes that are dependent on COM.rsa.jsafe.* will fail. Since Netscape's signtool cannot operate directly on jar archives, we unpack the jsse.jar before running signtool. So, this unpacking / signing operation has to be done on a UN*X system - or we have to switch to using Sun's jarsigner.
What are you doing? You are supposed to be reading this tiny ad!
the new thread boost feature brings a LOT of attention to your favorite threads