Initialization error when tried to lauch JNPL with OWS

[arunkumarj811]

net.sourceforge.jnlp.LaunchException: Fatal: Initialization Error: Could not initialize application. The application has not been initialized, for more information execute javaws from the command line.
at net.sourceforge.jnlp.Launcher.createApplication(Launcher.java:592)
at net.sourceforge.jnlp.Launcher.launchApplication(Launcher.java:373)
at net.sourceforge.jnlp.Launcher.access$300(Launcher.java:71)
at net.sourceforge.jnlp.Launcher$TgThread.run(Launcher.java:660)
Caused by: net.sourceforge.jnlp.LaunchException: Fatal: Initialization Error: A fatal error occurred while trying to verify jars. An exception has been thrown in class JarCertVerifier. Being unable to read the cacerts or trusted.certs files could be a possible cause for this exception.: Error in verify jar C:\Users\myUserName.cache\icedtea-web\cache\0\94\icepdf-viewer.jar
at net.sourceforge.jnlp.runtime.classloader.JNLPClassLoader.initializeResources(JNLPClassLoader.java:716)
at net.sourceforge.jnlp.runtime.classloader.JNLPClassLoader.(JNLPClassLoader.java:350)
at net.sourceforge.jnlp.runtime.classloader.JNLPClassLoader.createInstance(JNLPClassLoader.java:423)
at net.sourceforge.jnlp.runtime.classloader.JNLPClassLoader.getInstance(JNLPClassLoader.java:495)
at net.sourceforge.jnlp.runtime.classloader.JNLPClassLoader.getInstance(JNLPClassLoader.java:468)
at net.sourceforge.jnlp.Launcher.createApplication(Launcher.java:584)
... 3 more
Caused by: java.lang.RuntimeException: Error in verify jar C:\Users\myUserName.cache\icedtea-web\cache\0\94\icepdf-viewer.jar
at net.sourceforge.jnlp.tools.JarCertVerifier.verifyJar(JarCertVerifier.java:309)
at net.sourceforge.jnlp.tools.JarCertVerifier.verifyJars(JarCertVerifier.java:251)
at net.sourceforge.jnlp.tools.JarCertVerifier.add(JarCertVerifier.java:225)
at net.sourceforge.jnlp.runtime.classloader.JNLPClassLoader.initializeResources(JNLPClassLoader.java:709)
... 8 more
Caused by: net.sourceforge.jnlp.util.InvalidJarHeaderException: Jar icepdf-viewer.jar do not heave valid header. You can skip this check by -Xignoreheaders
at net.sourceforge.jnlp.util.JarFile.verifyZipHeader(JarFile.java:184)
at net.sourceforge.jnlp.util.JarFile.(JarFile.java:86)
at net.sourceforge.jnlp.util.JarFile.(JarFile.java:82)
at net.sourceforge.jnlp.tools.JarCertVerifier.verifyJar(JarCertVerifier.java:273)
... 11 more

---

I hava a .pfx file and also a .jks file which i tried attaching by import in OWS>Certificates. However, I can't add .jks file but .pfx file got attached.

I also tried adding deployment.system.security.trusted.certs="myPath to .pfx file" in deployment.properties (C:\Users\myUserName.config\icedtea-web). I placed both files also in security folder because i dont know what to do. Just trying all out.

Using Amazon 1.8 JDK locally and mentioned in JVM manager of OWS too. I have no idea how to make my .jks or .pfx available and make this non verify jar to go away to start my application using JNLP. When i check manually for the jar sign in cache, it has signature. I think it need some .pfx like file to confirm it. Its just my understanding, correct me if i'm wrong.

I hope you got what i'm trying to do. I referred docs, but can't get a clear picture of what to do to bypass the error. Please help. I'm trying for almost a week now. Thanks in advance.

[2573117531]

I had a similar problem. Did you finally solve it？

[tejveer-kyo]

I had a similar problem too.

[jelabarre59]

Working on it for a week??? Been fighting this for a month & a half, probably more. I need this working to access the remote console on a server (there is NO chance the firmware will be fixed for this, the last released firmware is from 2010).

[arunkumarj811]

I solved the problem after numerous tries. Nothing from OWS side config/settings changes worked for me, so I went back to my EAR file I deployed to find a solution to make it work with OWS. It says in OWS error "Fatal: Initialization Error: A fatal error occurred while trying to verify jars. An exception has been thrown in class JarCertVerifier".

1. When I checked my JAR files signature inside the EAR, all signed using SHA-256, but a few of them are signed with timestamp using SHA-1 algorithm. Technically, timestamp algorithm shouldn't be a problem, but I changed my POM file to build all JAR's using SHA-256 for timestamps too. Now I have a EAR file with all JAR's and WAR's signed using SHA-256 with a SHA-256 timestamp too.
2. Build my EAR file for deployment using Amazon Coretto 1.8 which I used for launching JNLP file in OWS too. Previously I built using oracle java 8 and used Amazon coretto 1.8 in OWS for launching JNLP. Seems oracle java and openJDK(Amazon Coretto in my case works differently in certain aspects).
3. Clear the OWS cache (not the JVM cache, if cleared, need to do the settings in OWS again since all will be lost), usually by default installation cache folder will be "C:\Users<your username>.cache\icedtea-web\cache". This prevents duplication of downloaded JARS. Do this for each launch until OWS works, else next time same initialization due to jarsigner error will be thrown over and over.
4. Have correct OWS settings for JVM.I removed auto lookup for finding java in OWS and pointed my local JVM (Amazon Corretto 1.8). No other settings were changed (all default).

These are the things I did and after numerous tries of different combinations, we were able to launch the application using OWS successfully and implemented it. Hope it helps solves your too.

If not, and you find some other approaches, please do post it here, since it will be of great help for people using OWS. I will leave this issue unclosed for now.

Have a great day!!!

[jelabarre59]

That only works if you can re-compile the JAR files. I'm just presuming that since the IMM firmware is 13 years old at this point, Java/OWS won't accept the signatures anymore.

[arunkumarj811]

I really don't think there is a problem with IMM firmware in context of jar signatures. IMM and jar signatures are completely unrelated. The process of verifying digital signatures on JAR files is primarily determined by the Java Runtime Environment (JRE) or the Java Security Manager. But yes, in my case I control, how the JARs should be signed and thus I build a deployable EAR file with signatures used globally at this point (SHA-256), and so my JAR unsigned/unverified error is no more.

IBM's Integrated Management Module (IMM) firmware, as primarily a hardware management and monitoring tool, is not designed for verifying the digital signatures of JAR (Java Archive) files. Verifying the digital signatures of JAR files is typically a function performed by the Java Runtime Environment (JRE) or the Java Security Manager when executing Java applications.

When a JAR file is signed with a digital signature, the verification process typically involves the following steps:

1. Checking the JAR Manifest: The JAR file contains a manifest that specifies which files are signed and includes information about the signer's certificate.
2. Accessing the Public Key: The JRE uses the public key from the signer's certificate to verify the digital signature.
3. Signature Verification: The JRE calculates a hash of the JAR file's contents and decrypts the digital signature using the public key. If the decrypted signature matches the calculated hash, the JAR file is considered valid and hasn't been tampered with.

This verification process is entirely within the realm of Java and the JRE, and it's unrelated to the hardware-level functions of IMM firmware. IMM is primarily concerned with activities such as server hardware management, remote server control, monitoring, and diagnostics.