Packaging issue with PDF only - EPUB works

[Guest]

Has anyone seen this while using the packager service on a PDF?

     java.lang.NoClassDefFoundError: Could not initialize class com.adobe.adept.packaging.pdf.

Everything else seems to be working very well, all services running and test ok, EPUB packaging works ok, etc. The class file is there, and otherwise the packager seems to be working.

Tomcat6 / Linux / java version "1.6.0_20"

[Guest]

Here's more info - it seems to appear in the log earler, the PDFPackager doesn't init due to JsafeJCE init failing:

Caused by: java.lang.SecurityException: JsafeJCE provider self-integrity check failed

     at com.rsa.jsafe.provider.JsafeJCE.<init>(Unknown Source)

     at com.adobe.adept.packaging.pdf.PDFPackager.<clinit>(PDFPackager.java:73)

I've determined that the jsafeJCE.jar is a signed JAR, and the certificate is out of date.

I tried to install a more recent jsafeJCE.jar from the EMC/RSA project, but that just apparently masked the error. I think the root cause is in fact the signed JAR certificate has expired.

Any advice on either:
a) Getting an updated jsafeJCE.jar that has a valid signature, or

b) Configuring Tomcat/Java to consider an out of date signing certificate as OK (eg, relax this requirement)

Thx -

[Jim_Lester-oIBbX7]

I have a test environment that is fairly close to that, and I'm packaging PDFs without a problem.  I have verified that we do have the out of date certificate in the signature of the jsafeJCE.jar.  The cert expiry date is 3/6/09, so I would suspect that this would be a general problem for everybody.  So I would expect something with your tomcat or java configuration.  I didn't see anything obvious in the catalina settings files to point at for this though.  Do you remember anything that you changed?

[Guest]

Hi Jim,

I solved my own issue last night, but if you have guidance on the context or security setup you used on tomcat I'd love to hear it.

Essentially I put the jsafe.jar and jsafeJCE.jar in the tomcat system lib directory and removed them from the pacakging app's deployment lib directory. This allowed the cert issue to be ignoerd. I'd guess there's a tomcat or java.security setting I could do to permit the signature issue to pass without a security exception in the deployment directory, but I haven't been able to find such a setting. This workaround is ok for now, but I'm sure to forget it next time a new war needs to be deployed. <grin>

cheers,

James

[Jim_Lester-oIBbX7]

It's interesting, because I haven't heard of a Tomcat installation that has caused that particular problem.  (There have been other problems with trying to set security to the minimal level needed to run, but the ACS4.1 distro has good information on what was gleaned about this).

I played around a bit with my dev installation and wasn't able to reproduce this.

[angwe]

This is an old discussion, I know, but the same issue reared its head for me yesterday. It happened (and this is important) when my install of OpenJDK 1.8.0 was updated. (I'm running Tomcat on RedHat plain, no JBoss stuff.)

Turns out the security settings for JAR signing got bumped up above what ACS 5.0 was originally configured for. The JAR files in Packaging server on my system were signed with an MD5+RSA1024 key, but the system's java.security file was disallowing any MD5-based certificates for JAR signing.

On RH7 with OpenJDK 1.8.0, the relevant file is:

/usr/lib/jvm/CURRENTOPENJDKJVMDIRECTORY/jre/lib/security/java.security

The line you want is:

jdk.jar.disabledAlgorithms=MD2, MD5, RSA keySize < 1024

And you want to change it to:

jdk.jar.disabledAlgorithms=MD2, RSA keySize < 1024

It means your whole system will now accept MD5-signed JAR files, which you might consider a security risk, but it solves the issue.

[Oliver Schnell]

Thanks for post this! It saved my day!

[Mile5DC4]

Works like a charm, thank you so much for sharing!

[Guest]

Hi,

Upgraded to CS version 4.1 on JBoss6 from 4.0 on Glassfish 2.1, version 4.0 runs smoothly on Glassfish, version 4.1 introduces the error of this discussion. Any ideas for a solution?

Cheers,

Alex