i have the following JNLP file:
<jnlp spec="1.0+" codebase="http://****:****" href="tcm2012.jnlp">
<information>
<title>TCM 2012</title>
<vendor>Drift og Performance, *** Servicecenter</vendor>
<homepage href="http://******"/>
<description/>
</information>
<security>
<all-permissions/>
</security>
<resources>
<j2se version="1.6+"/>
<jar href="tcm2012.jar"/>
</resources>
<application-desc main-class="com.****.kundeservice.TCMApplication"/>
</jnlp>
Now when i try to run in from the web i get the following error:
Found unsigned entry in resource
With the following exepction
com.sun.deploy.net.JARSigningException: Found unsigned entry in resource: http://*****:****/tcm2012.jar
at com.sun.javaws.security.SigningInfo.getCommonCodeSignersForJar(Unknown Source)
at com.sun.javaws.security.SigningInfo.check(Unknown Source)
at com.sun.javaws.security.JNLPSignedResourcesHelper.checkSignedResourcesHelper(Unknown Source)
at com.sun.javaws.security.JNLPSignedResourcesHelper.checkSignedResources(Unknown Source)
at com.sun.javaws.Launcher.prepareResources(Unknown Source)
at com.sun.javaws.Launcher.prepareAllResources(Unknown Source)
at com.sun.javaws.Launcher.prepareToLaunch(Unknown Source)
at com.sun.javaws.Launcher.prepareToLaunch(Unknown Source)
at com.sun.javaws.Launcher.launch(Unknown Source)
at com.sun.javaws.Main.launchApp(Unknown Source)
at com.sun.javaws.Main.continueInSecureThread(Unknown Source)
at com.sun.javaws.Main.access$000(Unknown Source)
at com.sun.javaws.Main$1.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
Does anyone know how to fix this problem?
This worked for me:
Go the Control Panel/Java.
Then click on “Settings” button and activate the option “Keep temporary files on my computer.”
It’s weird, but it worked!
The problem can also occur with older Java Versions if you sign with a newer Java versions.
Sign with 1.8u74 and older works with all versions
Sign with 1.8u101 and newer works with 1.7u80 and newer but not with older versions on the client.
There seems a incompatible change in the sign algorithm.
I had a similar problem with my applications.
I' ve a java swing application deployed with javaws:
when I run the application using JRE 1.6 I get the exception
when I run the application using JRE 1.7 and JRE 1.8 it works
I checked all the jar, MANIFEST.MF etc. and all was fine.
Finally I discovered that I've used a new TSA endpoint to sign my jars.
when I use this TSA http://tsa.starfieldtech.com the application run fine with JRE6,8
when I use this TSA http://services.globaltrustfinder.com/adss/tsa the application runs only with JRE8
From this resource http://docs.oracle.com/javase/7/docs/technotes/tools/windows/jarsigner.html I read
To generate the time stamp, jarsigner communicates with the TSA with the Time-Stamp Protocol (TSP) defined in RFC 3161. When successful, the time stamp token returned by the TSA is stored with the signature in the signature block file.
Someone can give more insight about this problem? In particular I don't want to be forced to use a particular TSA.
Why there are this differences between TSA?
Thanks
I my case the applet really had unsigned entry in META-INF folder. )
One way to fix that would be to re-sign it.
But in java 8 self-signed applets were demoted to almost the same level as unsigned ones. And the applet didn't required any additional privileges.
So it was sufficient to just un-sign it and add to trusted sites list.
I had the same problem when compiling on my linux maschine (with JDK 6 U45).
But I got this error only when I also tried to start the signed application with Java 6 U45.
When I try to start the application with a newer Java-Version (e.g Java 8) it was OK all the time, with no error message.
When I used a windows maschine to compile the project (also with 6 Update 45), it strangely works also when I use Java 6 U45 to start.
Just my 2 cents....
Cheers!
Related
We are using Java web start for deploying our application.
All JAR files are signed and there is no problem with deploying and using the application with all Java versions (including 8u73).
With JRE 8u74, application was deployed OK (all JAR files downloaded and application started correctly).
When trying to extract a file from a JAR file we are getting the following message:
Failed to validate certificate. The application will not be executed.
java.security.cert.CertificateException: Could not verify signing in resource: https://www.example.com:443/app/myFile.jar
at com.sun.deploy.security.TrustDecider.ensureAllJarEntriesSigned(Unknown Source)
at com.sun.deploy.security.TrustDecider.getValidationState(Unknown Source)
at com.sun.deploy.security.TrustDecider.validateChain(Unknown Source)
at com.sun.deploy.security.TrustDecider.isAllPermissionGrantedInt(Unknown Source)
at com.sun.deploy.security.TrustDecider.isAllPermissionGranted(Unknown Source)
at com.sun.deploy.security.DeployURLClassLoader.getResourcePermission(Unknown Source)
at com.sun.deploy.security.DeployURLClassLoader.getResourceAsStream(Unknown Source)
at com.til.manager.B.A.A(Unknown Source)
at com.til.manager.B.A.D(Unknown Source)
at com.til.manager.B.A.B(Unknown Source)
at com.til.manager.app.H$6.run(Unknown Source)
Caused by: com.sun.deploy.net.JARSigningException: Could not verify signing in resource: https://www.example.com:443/app/myFile.jar
This happens for several files.
This error message is shown when our application tries to extract files from the JAR files to the local computer.
Further investigating we found that on 8u74, for the following code:
ClassLoader classLoader = this.getClass().getClassLoader();
classLoader.getResource("").getPath();
the second line returns NULL.
On all previous Java version this was working correctly.
Could this be connected to the error message?
Any idea why this is happening or how to fix this problem?
The API documentation for ClassLoader.getResource(String) claims that it will return null "if the resource could not be found or the invoker doesn't have adequate privileges to get the resource". Moreover, I tested the code you listed using the OpenJDK 1.7.0_95 as well as the Oracle JDK 1.8.0_72, and with both of them it did not return null on my system but rather it returned the execution directory (e.g. /home/errantlinguist/Eclipse%20Workspaces/Default/ClassLoaderTest8/bin/).
These two pieces of evidence suggest that the null reference you're getting is a symptom of the problem rather than the cause: CertificateException "indicates one of a variety of certificate problems", and is moreover a subclass of GeneralSecurityException-- note the words privileges and security.
Are you absolutely sure that your manifest for myFile.jar is correct?-- If so, what exact JVM are you runnng?-- If your manifest is correct, it is possible this problem may be related to a reported bug in OpenJDK 8u72. Unfortunately, without further information about your deployment, it isn't possible to know for sure.
I had the same problem, but the Jar referred to by my JNLP had only DLLs in it, no Java code. Upon reading hundreds of similar threads relating to this problem it became apparent that I might need to add a Jar to the JNLP that actually included Java code. So, my original JNLP included 4 Jars with DLLs as follows:
<resources os="Windows" arch="x86">
<nativelib href="lib/jogl/jogl-all-natives-windows-i586.jar"/>
</resources>
<resources os="Windows" arch="amd64">
<nativelib href="lib/jogl/jogl-all-natives-windows-amd64.jar"/>
</resources>
<resources os="Windows" arch="x86">
<nativelib href="lib/jogl/gluegen-rt-natives-windows-i586.jar"/>
</resources>
<resources os="Windows" arch="amd64">
<nativelib href="lib/jogl/gluegen-rt-natives-windows-amd64.jar"/>
</resources>
This failed with the Java.security.cert.CertificateException: Could not verify signing in resource: ...
Then, when I added a signed Jar that has Java code in it as follows, the problem went away:
<resources>
<jar href="lib/hdf/jhdf.jar"/>
</resources>
I wrote a simple program in java using eclipse. The program requires disk access (read and write) and some internet access. I want to create a web start application out of it, so I downloaded netbeans. I imported the project and ran it with netbeans. Everything worked. After that I right clicked the project, went to web start => I selected local Execution, selected an icon and signed it with my own created key. (I didn't select "Allow offline").
After that I hit f11 and the project build. I went to the project folder and opened the dist folder and dragged everything to my desktop (C:\Users\teddy\Desktop\host). I double clicke dlaunch.jnla and then I got the error: Unable to laucn hthe application
I clicked details. The error looks like this:
com.sun.deploy.net.JARSigningException: Found unsigned entry in resource: file:/C:/Users/teddy/workspace/facebooker/dist/facebooker.jar
at com.sun.javaws.security.SigningInfo.getCommonCodeSignersForJar(Unknown Source)
at com.sun.javaws.security.SigningInfo.check(Unknown Source)
at com.sun.javaws.security.JNLPSignedResourcesHelper.checkSignedResourcesHelper(Unknown Source)
at com.sun.javaws.security.JNLPSignedResourcesHelper.checkSignedResources(Unknown Source)
at com.sun.javaws.Launcher.prepareResources(Unknown Source)
at com.sun.javaws.Launcher.prepareAllResources(Unknown Source)
at com.sun.javaws.Launcher.prepareToLaunch(Unknown Source)
at com.sun.javaws.Launcher.prepareToLaunch(Unknown Source)
at com.sun.javaws.Launcher.launch(Unknown Source)
at com.sun.javaws.Main.launchApp(Unknown Source)
at com.sun.javaws.Main.continueInSecureThread(Unknown Source)
at com.sun.javaws.Main.access$000(Unknown Source)
at com.sun.javaws.Main$1.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
I also used JaNeLA to chech the jnla file, this is the output:
JaNeLA Report - version 11.05.17
Report for file:/C:/Users/teddy/Desktop/host/launch.jnlp
Content type application/xml does not equal expected type of application/x-java-jnlp-file
cvc-complex-type.2.4.a: Invalid content was found starting with element 'security'. One of '{resources, application-desc, applet-desc, component-desc, installer-desc}' is expected.
cvc-complex-type.2.4.a: Invalid content was found starting with element 'security'. One of '{resources, application-desc, applet-desc, component-desc, installer-desc}' is expected.
XML encoding not known, but declared as UTF-8
Codebase + href 'file:/C:/Users/teddy/workspace/facebooker/dist/launch.jnlp' is not equal to actual location of 'file:/C:/Users/teddy/Desktop/host/launch.jnlp'.
Optimize this application for off-line use by adding the <offline-allowed /> flag.
Downloads can be optimized by specifying a resource size for 'facebooker.jar'.
The resource download at facebooker.jar can be optimized by removing the (default) value of download='eager'.
Lazy downloads might not work as expected for facebooker.jar unless the download 'part' is specified.
Downloads can be optimized by specifying a resource size for 'lib/restfb-1.6.14.jar'.
The resource download at lib/restfb-1.6.14.jar can be optimized by removing the (default) value of download='eager'.
The resource download at lib/restfb-1.6.14.jar can be optimized by removing the (default) value of main='false'.
It might be possible to optimize the start-up of the app. by specifying download='lazy' for the lib/restfb-1.6.14.jar resource.
Lazy downloads might not work as expected for lib/restfb-1.6.14.jar unless the download 'part' is specified.
Downloads can be optimized by specifying a resource size for '007.jpg'.
Icon loading & use can be optimized by specifying the width and height for 007.jpg
Report for file:/C:/Users/teddy/workspace/facebooker/dist/jnlpcomponent1.jnlp
Content type application/xml does not equal expected type of application/x-java-jnlp-file
XML encoding not known, but declared as UTF-8
Optimize this application for off-line use by adding the <offline-allowed /> flag.
Downloads can be optimized by specifying a resource size for 'lib/forms-1.3.0.jar'.
The resource download at lib/forms-1.3.0.jar can be optimized by removing the (default) value of download='eager'.
The resource download at lib/forms-1.3.0.jar can be optimized by removing the (default) value of main='false'.
It might be possible to optimize the start-up of the app. by specifying download='lazy' for the lib/forms-1.3.0.jar resource.
Lazy downloads might not work as expected for lib/forms-1.3.0.jar unless the download 'part' is specified.
#
Does anyone knows what's going on here?
The JNLP file looks like this:
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<jnlp codebase="file:/C:/Users/teddy/workspace/facebooker/dist/" href="launch.jnlp" spec="1.0+">
<information>
<title>facebooker</title>
<vendor>teddy</vendor>
<homepage href=""/>
<description>facebooker</description>
<description kind="short">facebooker</description>
<icon href="007.jpg" kind="default"/>
</information>
<update check="always"/>
<security>
<all-permissions/>
</security>
<resources>
<j2se version="1.7+"/>
<jar href="facebooker.jar" main="true"/>
<jar href="lib/restfb-1.6.14.jar"/>
<extension href="jnlpcomponent1.jnlp"/>
</resources>
<application-desc main-class="">
</application-desc>
</jnlp>
I have an applet which depends with many jars. After I update the java to 7.45 the applet generate message saying “This application will be blocked in a future Java security update because the JAR file manifest does not contain the Permissions attribute”
I added permission attribute “Permissions: all-permissions” to all manifest files after that I resigned all these jars by our "6NRJ" certificate.
All jars was well signed but unfortunately the applet generate an exception only in "bcprov-ext-jdk16-140.jar".
Here the exception details:
java.security.NoSuchProviderException: JCE cannot authenticate the provider BC
at javax.crypto.JceSecurity.getInstance(JceSecurity.java:101)
at javax.crypto.KeyGenerator.getInstance(KeyGenerator.java:249)
at org.bouncycastle.cms.CMSEnvelopedHelper.createKeyGenerator(Unknown Source)
at org.bouncycastle.cms.CMSEnvelopedHelper.createSymmetricKeyGenerator(Unknown Source)
at org.bouncycastle.cms.CMSEnvelopedDataGenerator.generate(Unknown Source)
at com.atexo.mpe.applet.AppletDiagnostic.init(AppletDiagnostic.java:142)
at com.sun.deploy.uitoolkit.impl.awt.AWTAppletAdapter.init(Unknown Source)
at sun.plugin2.applet.Plugin2Manager$AppletExecutionRunnable.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
Caused by: java.util.jar.JarException: http://wma-migration.whitecapetech.local/ressources/applet/bcprov-ext-jdk16-140.jar is not signed by a trusted signer.
at javax.crypto.JarVerifier.verifySingleJar(JarVerifier.java:503)
at javax.crypto.JarVerifier.verifyJars(JarVerifier.java:322)
at javax.crypto.JarVerifier.verify(JarVerifier.java:250)
at javax.crypto.JceSecurity.verifyProviderJar(JceSecurity.java:161)
at javax.crypto.JceSecurity.getVerificationResult(JceSecurity.java:187)
at javax.crypto.JceSecurity.getInstance(JceSecurity.java:98)
... 8 more
I think that bcprov-ext-jdk16-140.jar was signed before by bouncy castle.
Is there a way to re-sign "bcprov-ext-jdk16-140.jar" after adding the permission attribute ?
Thanks in advance for help
"I think that bcprov-ext-jdk16-140.jar was signed before by bouncy castle."
No, you can verify this opening the jar. You Will find no signature in it.
"Is there a way to re-sign "bcprov-ext-jdk16-140.jar" after adding the permission attribute ? "
yes. Open the bcprov jar. Add the permission attribuite using a text editor. Sign using jarsigner.
I have a Java servlet application developed and on my develpment PC everything works as expected including using SFTP programmatically to copy over a PDF using HTTPS on port 8443 etc and with SSL certificates in place too.
However, when I attempt to run the application on the Live server I receive the error;
java.lang.NoClassDefFoundError: Could not initialize class javax.crypto.SunJCE_b
On investigation, some are suggesting check the jce.jar. But I have ensured the jce.jar is present and also created a "lib" folder in my project and copied the jar there and placed the jar on my build path but still the problem exists.
How do I resolve this please? Thanks in advance. Here is the console output from right after Tomcat has started the application;
#
08-Jan-2014 10:45:44 org.apache.catalina.startup.Catalina start
INFO: Server startup in 12715 ms
08-Jan-2014 10:47:42 org.apache.tomcat.util.net.NioEndpoint$SocketProcessor run
SEVERE:
java.lang.NoClassDefFoundError: Could not initialize class javax.crypto.SunJCE_b
at javax.crypto.Cipher.getInstance(DashoA13*..)
at com.sun.net.ssl.internal.ssl.JsseJce.getCipher(Unknown Source)
at com.sun.net.ssl.internal.ssl.RSAClientKeyExchange.<init>(Unknown Source)
at com.sun.net.ssl.internal.ssl.ServerHandshaker.processMessage(Unknown Source)
at com.sun.net.ssl.internal.ssl.Handshaker.processLoop(Unknown Source)
at com.sun.net.ssl.internal.ssl.Handshaker$1.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at com.sun.net.ssl.internal.ssl.Handshaker$DelegatedTask.run(Unknown Source)
at org.apache.tomcat.util.net.SecureNioChannel.tasks(SecureNioChannel.java:285)
at org.apache.tomcat.util.net.SecureNioChannel.handshakeUnwrap
(SecureNioChannel.java:343)
at org.apache.tomcat.util.net.SecureNioChannel.handshake
(SecureNioChannel.java:193)
at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.run
(NioEndpoint.java:1642)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
The jce.jar must be inside the folder WEB-INF/lib of the deployed web application.
I've seen this problem pop up very often and there seems to be a lot of confusion around it. The actual reason this is happening is because the JRE you are using to run your application has been set up with the unrestricted JCE policy jars inside its jre/lib folder (inside your jdk install folder).
If your current project does not need these, then you can move then out of this folder temporarily. This will remove the requirement on the jce libraries and you will no longer see this error.
Hope this helps.
And many thanks to all who will take time for reading.
I'm struggling to make a webstart Swing 1.4.2_12 application to launch with java webstart 1.6.0_29.
Here is the scenario :
All traffic is done over HTTPS
User clics a link on a web page to launch the application : servlet
generated jnlp file
Java webstart client (1.6.0_29) starts and loads the application in
a breath
Because the j2se version is set to 1.4.2_12 in jnlp descriptor java
webstart 1.4.2_12 is used to launch the application (loaded by
1.6.0_29)
Java webstart 1.4.2_12 fails on startup claiming that it cannot find some ghost "javaws2" file
The following message is reported:
CouldNotLoadArgumentException[ Could not load specified file/URL : C:\DOCUME~1\BENOIT~1.VAT\LOCALS~1\Temp\javaws2]
at com.sun.javaws.Main.launchApp(Unknown Source)
at com.sun.javaws.Main.continueInSecureThread(Unknown Source)
at com.sun.javaws.Main$1.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
Full stacktrace is:
java.io.FileNotFoundException: C:\DOCUME~1\BENOIT~1.VAT\LOCALS~1\Temp\javaws2 (File not found)
at java.io.FileInputStream.open(Native Method)
at java.io.FileInputStream.<init>(Unknown Source)
at java.io.FileInputStream.<init>(Unknown Source)
at com.sun.javaws.jnl.LaunchDescFactory.buildDescriptor(Unknown Source)
at com.sun.javaws.Main.launchApp(Unknown Source)
at com.sun.javaws.Main.continueInSecureThread(Unknown Source)
at com.sun.javaws.Main$1.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
The same error occurs when HTTPS is disabled.
Both the following HTTP headers are sent to the client by JNLP servlet :
Cache-Control : empty
Pragma : empty
These headers are necessary to prevent IE to disable caching in HTTPS mode wich prevents java webstart to find the loaded jnlp file (because it is not cached).
Mime-type is set to : application/x-java-jnlp-file
What I do not understand is why java 1.4.2_12 cannot find the jnlp file loaded by JWS 1.6.0_29 ?
Thanks for reading.
#Andrew : Thank you for your interest.
Here comes my conclusions on that issue.
In a nutshell : Always set the href attribute in the the jnlp tag !
<jnlp spec="1.0+" codebase="htt://myhost/codebase" href="mustSetThisAbsolutelyForJWS-1.4.2_12.jnlp">
...
</jnlp>
Multiple HTTP debug sessions have shown that :
Scenario 1: href attribute is left empty and JNLP files are associated with JWS 1.6 on the client
User clicks a jnlp link, JNLP file is downloaded and cached by
browser.
JWS 1.6.0_29 starts up then read the downloaded JNLP file.
JWS 1.6.0_29 downloads all JAR files and then switches to JWS 1.4.2_12.
JWS 1.4.2_12 starts up and then obviously read the JNLP file in its turn.
JWS 1.4.2_12 tries to retrieve the JNLP file pointed by the href
attribute.
Since href is empty, JWS reports "Could not load specified file/URL
: C:\DOCUME~1\BENOIT~1.VAT\LOCALS~1\Temp\javaws2". (As a side note, ghost javaws2 is sometimes named javaws10 or similar)
Please note : When using JWS 1.4 or 1.5 with this scenario, the
application WILL start. The issue only appears when JWS 1.6 is used
to run a 1.4.2_12 application. JWS 1.5 and 1.6 do not fail when no
href attribute is set. Instead they simply use the JNLP as is, check the
JAR updates and then launch the application.
Scenario 2: href attribute is set with a proper value and JNLP files are associated with JWS 1.6 on the client
User clicks a jnlp link, JNLP file is downloaded and cached by
browser.
JWS 1.6.0_29 starts up then read the downloaded JNLP file.
JWS 1.6.0_29 downloads all JAR files and then switches to JWS 1.4.2_12.
JWS 1.4.2_12 starts up and then obviously read the JNLP file in its turn.
JWS 1.4.2_12 tries to retrieve the JNLP file pointed by the href
attribute.
JWS 1.4.2_12 downloads the JNLP pointed by the href attribute.
JWS 1.4.2_12 downloads all JNLP JAR files referenced in the freshly downloaded JNLP file.
JWS 1.4.2_12 launches the application correctly.
It's been a major pain in the neck for me and took me days to figures this out. Hope this will help someone one day.