Add intermediate certificate to signed jar

Is it possible to add an intermediate certificate to a signed jar file?
The users of my applet are asked to trust the certificate showing the hint that the source is not trusted. The root certificate of my code signing certificate is included in the trusted sources.
Thanks,
Reinhard

I have already a full trusted chain consisting of the root, an intermediate certificate and my code signing certificate. The root is included in Java�s trusted roots. But if I sign my jar with my code signing certificate, Java can not build the trust chain, as it does not have the intermediate certificate. If it would be possible to include the intermediate certificate certificate it would work, but appearantly this is not possible with jarsigner.

Similar Messages

How to connect from Signed jar to normal jar

Hi Team,
I have one signed jar. This signed jar manifest file contains all the algorithams. I want to connect from
a class (which is available in a signed jar) to another class (which is available in another jar which is not signed.)
could you please explain how to add class-path in signed jar maifest file.
Thanks
T. Shankar Reddy

Hi,
Please use the CD to run setup on the second, third, ..... computer. In short, you have to run setup for each computer.
Regards.
BH
**Click the KUDOS thumb up on the left to say 'Thanks'**
Make it easier for other people to find solutions by marking a Reply 'Accept as Solution' if it solves your problem.

Signed JAR file won�t work on A Mac

Hello I am trying to run this java script on a Mac
import java.awt.*;
import java.awt.event.*;
import java.applet.*;
import javax.swing.*;
import javax.swing.border.*;
import javax.swing.table.*;
import java.io.*;
public class Applet1 extends Applet {
private FlowLayout flowLayout1 = new FlowLayout();
private JFileChooser jFileChooser1 = new JFileChooser();
public Applet1() {
try {
jbInit();
catch(Exception e) {
e.printStackTrace();
private void jbInit() throws Exception {
this.setLayout(flowLayout1);
this.add(jFileChooser1, null);
The signed jar works properly on pc and it doesn�t work on a Mac.
I am using JDK 2.5 and swing 1.1.1

What error are you getting?Swing: checked access to system event queue.
An exception occurred:
com.apple.mrj.JManager.JMAppletSecurityExc: security.checkread: /, /
     at com.apple.mrj.JManager.JMAppletSecurityOld.checkRead(JMAppletSecurityOld.java)
     at com.apple.mrj.JManager.JMAppletSecurityOld.checkRead(JMAppletSecurityOld.java)
     at java.io.File.exists(File.java)
     at javax.swing.filechooser.UnixFileSystemView.getRoots(FileSystemView.java:270)
     at javax.swing.plaf.metal.MetalFileChooserUI$DirectoryComboBoxModel.<init>(MetalFileChooserUI.java:683)
     at javax.swing.plaf.metal.MetalFileChooserUI.createDirectoryComboBoxModel(MetalFileChooserUI.java:666)
     at javax.swing.plaf.metal.MetalFileChooserUI.installComponents(MetalFileChooserUI.java:145)
     at javax.swing.plaf.basic.BasicFileChooserUI.installUI(BasicFileChooserUI.java:106)
     at javax.swing.JComponent.setUI(JComponent.java:258)
     at javax.swing.JFileChooser.updateUI(JFileChooser.java:1296)
     at javax.swing.JFileChooser.setup(JFileChooser.java:294)
     at javax.swing.JFileChooser.<init>(JFileChooser.java:270)
     at javax.swing.JFileChooser.<init>(JFileChooser.java:233)
     at Applet1.<init>(Applet1.java:13)
     at com.apple.mrj.JManager.JMAppletViewer_OLD.doLoadCode(JMAppletViewerOld.java)
     at com.apple.mrj.JManager.JMAppletViewer_OLD.setState(JMAppletViewerOld.java)
     at com.apple.mrj.JManager.JMViewerEvent.post(JMAppletViewerOld.java)
     at com.apple.mrj.JManager.AVDispatcherThread.run(JMAppletViewerOld.java)

How can i add update signed jar file

I am developing an applet which requires signing to run in a browser.
I am developing supporting classes. But these class files have to be added
to the jar. Isnt it??
But to test the applet i need to load it in the browser each time i modify the class files. So the jar file need to be updated every time. But an
IOError
is being displayed when i try to update the signed jar file.
How can i update signed jar file?? Or is there any othe way to test the signed applet during development??

How can i update signed jar file?You can't, the signature is there to make sure the content of the jare hasn't been messed
with.
Either recreate the jar and re sign it or set up a policy during testing.

Problems with signed JAR files in JWS/JRE6 environment.

Hello All,
I'm encountering a problem running our desktop application as a Java Web Start deployment in a JRE 6 environment. There were never any problems when running the same application as a JWS deployment in JRE 1.4, or 5, environments. There are also currently no problems in a JRE 6 environment when running the application as a standard desktop application.
The problem which I am having has nothing to do with launching the application. But for good measure, I verified the JNLP file with JaNeLA. A couple things we out of order, which I addressed to make JaNeLA happy, but my problem still persists. Here is my JNLP file (anonymized to protect the innocent):
TS: 2010-10-18 17:04:46
<?xml version="1.0" encoding="UTF-8"?>
<jnlp codebase="$$codebase" href="$$name">
     <information>
          <title>Acme Desktop</title>
          <vendor>Acme Corporation</vendor>
          <homepage href="http://www.acme.com/"/>
          <description>Acme Client for Acme Server</description>
          <description kind="tooltip">Acme Client for Acme Server</description>
          <icon href="desktop.gif"/>
          <offline-allowed/>
     </information>
     <security>
          <all-permissions/>
     </security>
     <resources>
          <j2se version="1.5+"/>
          <jar href="acmedesktop.jar" download="eager" version="8.00.01.00+"/>
          <jar href="lib/antlr-2.7.2.jar" download="eager" version="8.00.01.00+"/>
          <jar href="lib/backport-util-concurrent.jar" download="eager" version="8.00.01.00+"/>
          <jar href="lib/commons-codec-1.3.jar" download="eager" version="8.00.01.00+"/>
          <jar href="lib/commons-httpclient.jar" download="eager" version="8.00.01.00+"/>
          <jar href="lib/commons-logging.jar" download="eager" version="8.00.01.00+"/>
          <jar href="lib/acmeapi.jar" download="eager" version="8.00.01.00+"/>
          <jar href="lib/HelpJavaDT.jar" download="eager" version="8.00.01.00+"/>
          <jar href="lib/HelpJavaDT_es.jar" download="eager" version="8.00.01.00+"/>
          <jar href="lib/jacorb.jar" download="eager" version="8.00.01.00+"/>
          <jar href="lib/Multivalent.jar" download="eager" version="8.00.01.00+"/>
          <jar href="lib/slf4j-api-1.5.6.jar" download="eager" version="8.00.01.00+"/>
          <jar href="lib/slf4j-jdk14-1.5.6.jar" download="eager" version="8.00.01.00+"/>
          <jar href="lib/snow.jar" download="lazy" version="8.00.01.00+"/>
          <jar href="lib/AcmeTMClient.jar" download="eager" version="8.00.01.00+"/>
          <jar href="lib/xercesImpl.jar" download="eager" version="8.00.01.00+"/>
          <jar href="lib/xml-apis.jar" download="eager" version="8.00.01.00+"/>
          <extension name="installer" href="desktopInstaller.jnlp" />
          <extension name="Java Help" href="help.jnlp"/>
          <property name="java.library.path" value="./lib"/>
          <property name="admin" value="false"/>
          <property name="webstart" value="true"/>
          
     </resources>
     <resources os="Windows">
          <nativelib href="lib/jniWin32.jar" version="8.00.01.00+"/>
     </resources>
     <application-desc main-class="desktop"/>
</jnlp>-----
When running as a JWS deployment, on JRE 6, the application will be functioning normally for a little while, and then suddenly the following exception is thrown, and the current operation fails because the class in question cannot be accessed:
java.lang.SecurityException: class "acmeapi.communication.CDocImpl"'s signer information does not match signer information of other classes in the same package
     at java.lang.ClassLoader.checkCerts(ClassLoader.java:807)
     at java.lang.ClassLoader.preDefineClass(ClassLoader.java:488)
     at java.lang.ClassLoader.defineClassCond(ClassLoader.java:626)
     at java.lang.ClassLoader.defineClass(ClassLoader.java:616)
     at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:141)
     at java.net.URLClassLoader.defineClass(URLClassLoader.java:283)
     at java.net.URLClassLoader.access$000(URLClassLoader.java:58)
     at java.net.URLClassLoader$1.run(URLClassLoader.java:197)
     at java.security.AccessController.doPrivileged(Native Method)
     at java.net.URLClassLoader.findClass(URLClassLoader.java:190)
     at com.sun.jnlp.JNLPClassLoader.findClass(JNLPClassLoader.java:288)
     at java.lang.ClassLoader.loadClass(ClassLoader.java:307)
     at java.lang.ClassLoader.loadClass(ClassLoader.java:248)
     at acmeapi.common.CDoc.getAnnotationsInfo(CDoc.java:493)
     at acmedesktop.communication.CCommunicationManager.privateGetAnnotations(CCommunicationManager.java:1976)
     at acmedesktop.communication.CCommunicationManager.getAnnotations(CCommunicationManager.java:1828)
     at acmedesktop.annotations.CViewAnnotations.getAnnotations(CViewAnnotations.java:826)
     at acmedesktop.annotations.CViewAnnotations.createView(CViewAnnotations.java:583)
     at acmedesktop.annotations.CViewAnnotations.setData(CViewAnnotations.java:736)
     at acmedesktop.annotations.CViewAnnotations.init(CViewAnnotations.java:205)
     at acmedesktop.hitspanel.CHitsPanel.viewAnnotations(CHitsPanel.java:281)
     at acmedesktop.hitspanel.CHitsTab$3.mousePressed(CHitsTab.java:316)
     at java.awt.AWTEventMulticaster.mousePressed(AWTEventMulticaster.java:263)
     at java.awt.Component.processMouseEvent(Component.java:6260)
     at javax.swing.JComponent.processMouseEvent(JComponent.java:3267)
     at java.awt.Component.processEvent(Component.java:6028)
     at java.awt.Container.processEvent(Container.java:2041)
     at java.awt.Component.dispatchEventImpl(Component.java:4630)
     at java.awt.Container.dispatchEventImpl(Container.java:2099)
     at java.awt.Component.dispatchEvent(Component.java:4460)
     at java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:4574)
     at java.awt.LightweightDispatcher.processMouseEvent(Container.java:4235)
     at java.awt.LightweightDispatcher.dispatchEvent(Container.java:4168)
     at java.awt.Container.dispatchEventImpl(Container.java:2085)
     at java.awt.Window.dispatchEventImpl(Window.java:2478)
     at java.awt.Component.dispatchEvent(Component.java:4460)
     at java.awt.EventQueue.dispatchEvent(EventQueue.java:599)
     at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:269)
     at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:184)
     at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:174)
     at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:169)
     at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:161)
     at java.awt.EventDispatchThread.run(EventDispatchThread.java:122)-----
The classes of our desktop product are contained within the 'acmedesktop' and 'acmeapi' packages. It requires access to the hard drive of the workstation, and therefore, all jar files included with the application are signed using the following ANT task when compiled:
<signjar keystore="resources/codesigning/keystore.pfx" storetype="pkcs12" storepass="myPassword" alias="myAlias">
     <fileset dir="${jws_dist}/app" includes="*.jar"/>
     <fileset dir="${jws_dist}/app/lib" includes="*.jar" excludes="jhall__V${dt_version}.jar"/>
</signjar>-----
Therefore, all classes, within all jar files, are signed with the same certificate (with the exception of the JavaHelp libraries, which are already signed by Sun - but the class in question attempting to be loaded here is not contained within the JavaHelp jar file anyway). So, the point being, that the exception message stating that the "signer information of the acmeapi.communication.CDocImpl class doesn't match the signer information of other classes in the same package", is simply not correct. All classes within that jar file were signed using the same certificate.
I downloaded the JRE 6 source from dev.java.net and picked through this issue with a debugger. The ClassLoader.checkCerts() method compares the certificate used to sign the current class which is attempting to be loaded, with the certificates which signed all other previously loaded classes within the same package. If they don't match, the exception above is thrown. What is causing the issue is when the checkCerts() method attempts to get the certificates which signed the currently loading class, null is returned. And obviously, comparing null, with an array of the certificates which signed the previously loaded classes, isn't going to match; therefore this exception is thrown.
The checkCerts() method gets the certificates of the currently loading class by calling the java.security.CodeSource.getCertificates() method. Tracing deeper in the debugger, the CodeSource object ultimately gets the certificates from the 'signersRef' member variable of the com.sun.deploy.cache.CachedJarFile class. signerRef is a SoftReference object and can therefore be garbage collected at some point. If it has already been garbage collected, the CachedJarFile class will attempt to retrieve it again from the loaded cache entry by calling com.sun.deploy.cache.MemoryCache.getLoadedResource().
The MemoryCache class maintains the cache entries to the jar files as MemoryCache.CachedResourceReference objects, which subclass WeakReference, and therefore these objects can be garbage collected as well. If the cache entries have also been garbage collected, this leaves the CachedJarFile class with no ability to repopulate the CachedJarFile.signerRef object. Therefore it is completely out of luck getting the certificates which signed the currently loading class, which ultimately causes the above exception.
When the com.sun.deploy.cache.Cache class attempts to retrieve a cache entry using its getCacheEntry() method, it will attempt to get the entry from the MemoryCache class, if null is returned, it will recreate the cache entry and add it back to the MemoryCache. In contrast, when the CachedJarFile class attempts to get a cache entry from the MemoryCache class, if null is returned, it just gives up.
(from com.sun.deploy.cache.CachedJarFile:244)
private CacheEntry getCacheEntry() {
     /* if it was not created by Cache do not search for entry */
     if (resourceURL == null)
          return null;
     CacheEntry ce = (CacheEntry) MemoryCache.getLoadedResource(resourceURL);
     if (ce == null) {
          //This should not happen because CacheEntry should not get collected
          // before CachedJarFile is collected.
          Trace.println("Missing CacheEntry for " + resourceURL + "\n" + ce,
               TraceLevel.CACHE);
     return ce;
When debugging, code execution falls within the code block with the comment stating "This should not happen...", but it is happening in my case.
On an interesting side note, using the jvisualvm.exe tool included with JDK 6, I was able to tell that it seems as though these objects are collected the first time that the JVM allocates more heap space, and then the issue will occur. If I set the initial heap size very large (using -Xms) this issue won't occur at all. But that is kind of a bad solution which I would rather not do, but it is interesting to note for the sake of troubleshooting this issue. The max heap size (-Xmx) is plenty big enough, so the issue is not that we are running out of memory here.
Does anyone have any insight as to what could be causing this? I've searched, and found a couple threads with similar problems but with no clear solutions. It is not just one workstation either, it happens everywhere I deploy the app as a Java Web Start application in a JRE 6 environment. I have been using version 1.6.0_18 on XP, but it seems to happen on any update version of 1.6. Is the fact that the CachedJarFile class doesn't attempt to reload the resource when it can't retrieve it from MemoryCache a bug? I've dug as deep as I can on this and I'm at wits end, does anybody have any ideas?
Thank you
Jake
Edited by: jkc532 on Nov 12, 2010 10:35 AM

jkc532 wrote:
.. Is the fact that the CachedJarFile class doesn't attempt to reload the resource when it can't retrieve it from MemoryCache a bug? From your comprehensive investigation and report, it seems so to me.
..I've dug as deep as I can on this and I'm at wits end, does anybody have any ideas?Just after read the summary I was tired, so I have some understanding of the effort you have already invested in this (the 'wits' you have already spent). I think you should raise a bug report and seek Oracle's response.

A few questions about signing JARs for Web start

I'm still a bit new to all this, so just want to clear a few things up.
I'm currently trying to publish an application using Web start, so i know I have to sign all the JARs, as it needs to do some writing to the hard drive.
1. I have my main JAR file, and then two "third party" JAR files in the /lib subfolder, I take it I need to sign those two as well, does it matter that I don't have the .class file for those two, as I didn't write them?
2. I'm running the JARSIGNER program with exactly the same command line apart from the filename of the .jar file, is that correct? or do I need a different certificate for each .jar file?
Just can't seem to get all three signed, Web start says one different one isn't signed each time I try it out.
3. When signing, does it add something to the end of the JAR file itself? as I can't see any extra files created.

Signing adds entries in the mainifest, not in the main file list in the jar file.
You can sign third party jar files, but it is not advisable. An alternative is to put third party jars in a seperate extension jnlp file, if they need all-permissions, you can get the third party jars already signed by whoever supplied them. If not, you do not need to request all-permissions in the extension jnlp file, and that part of the code will be run in the secure sandbox.
/Andy

Multiple jnlp's for signed jars

Hi,
I'm trying to solve the issue where you have several different certificates trying to sign the jars ... I've found out that you can just add extentions to your main jnlp and add the jars there.
Problem: I have loads of jars, all with different certificates.
At the moment I just generate my jnlp by usign a template, and entering $dependencies to list all jars in the file. That didn't work (JAR resources in JNLP file are not signed by same certificate), so I added my main jar in the main jnlp, and all the other jars in the extended jnlp, which is not working. Probably because (correct me if I'm wrong) I have to split every jar with another certificate into another jnlp ?
Is there any way I can split up the signed jars without having to add them manually in the jnlp file ?
Edited by: ReggieBE on May 16, 2008 1:17 AM

Oh, and I'm using webstart-maven-plugin from mojo.codehouse.org ;)

Updating to signed JARs causes problems for older Java versions?

Bear with me on this one -- not a Java developer, but an end user of Java products looking for a little clarification.
We use a product which delivers a Java application via JAR file / web to end users (GlobalScape's EFT server). With the recent release of Java 7 Update 51, users have been running into issues running these JAR files as they are not properly "signed". We're working with the vendor to get updated signed JAR files in place, but they've warned us that these new JAR files will cause errors (or maybe not work at all) on folks who aren't running Java 7 Update 51.
Trying to wrap my head around why that might be. Best theory I can come up with from perusing threads here along with the Java team blogs is that the new security attributes used in the updated JAR files aren't "trusted" by older versions of Java (prior to Update 51?).
We're pushing our vendor for clarification, but curious if someone here could help explain.
Thanks!

I suspect the problem with 'new JAR files will cause errors' is mainly because the vendor keeps enhancing their product, and may not any more support older JREs, or the new jars are no more compatible For example, we build our product on JDK 1.5 ... as some users out there must use that one because the 'newer and better' release does not work for them.
But so far, we have not seen any problems running the 'JRE 7 Compliant' applications on older releases ... provided you can make your application run on latest JRE 7.
In most cases, one can simply remove the previous signature, add (now required) attributes, and sign the same jar again.
But I have yet to find a vendor that would simply add attributes to some older release and re-sign those. Perhaps they can't repeat the build / QA cycle, and would not 'trust' the re-signed jars.
Our curse are signed Cryptographic Provider jars.
Those must be signed by certificates rooted by Sun/Oracle, and adding attributes invalidates that signature - we can re-sign them, but then they won't work. In our case, we are stuck with 5+ year old Bouncy Castle jars, and it does not help us that their 'current' jars are signed with attributes - they are completely incompatible..
IMHO, Oracle failed to think this all thru - or does not care.

Three questions about signed jar file and applet

I use three signed jar file. Each of them signed by different certificate. First of JARs contain applet class. When I start applet from html page I see message “This applet was signed by…… but Java cannot verify it… Do you trust…?”. All times I press “Yes I trust” and after this questions applet stop to work end exit. If I use only one certificate for signing of three JARs then applet continue to work after question. 1) What should I do to fix this bug? 2) Is it any method to check from applet that user press Trust button? Is it any method to emulate work of SecurityManager to check that Certificate object is trusted (I want do call some method check(Certificate) and if certificate is not trusted I want to see message with question: “Do you want to trust this certificate” and so on)?

Hello Jarman,
1. If I have a signed jar file, then as long as the
certificate is recognised as trusted that applet can
run as a fully trusted application on the client
machine. So I should not have to add lines such as
permission java.lang.RuntimePermission
"readFileDescriptor", "read" ;
permission java.lang.RuntimePermission
"writeFileDescriptor", "write" ;
to my java.policy file. true/false ?true
2. If I am running a signed jar file in the Java
plugin then I do not need to have a verisign or thawte
certificate (however to allow my certificate to be
accepted I do have to import it into the cacerts file
on the client machine). True/false?true
3. Following on from question 2, if I want to be able
to run an applet on a client machine, without messing
around with ANY files on those machines, I need a
verisign or thawte certificate. True/false?true
4. (And finally) Apart from a security exception
saying that I need to add one of the lines like those
of question 1, is there any way I can get other debug
information as to why the signed jar file is not being
recognised as signed?No. This could be a problem of importing your certifcate into the wrong place.
The information on the following link is a little bit dated but it helped me to successfully install a testcertificate and sign an applet with it.
http://www.suitable.com/Doc_CodeSigning.shtml

Error with Java WebStart Signed Jars on 1.6.0_19's new Mixed Code

All,
First, we have a valid code signing certificate/keystore from Thawte that works for signing webstart jars as of update 18. For some reason, if you run our webstart application on update 19 JRE, the runtime believes that some of the jars are not signed and some are. Even though we create and sign the jars in the exact same way and after inspecting the jar the JRE believes are not signed they have the necessary signing entries/files in the manifest folder. Not sure why the signing process would work for some of our jars and not for others. There is nothing really all that different.
So, because the JRE believes some of the jars are not signed the new security warning "...contains both signed and unsigned code." pops up ( [Error Description|http://java.com/en/download/help/error_mixedcode.xml] ). If I press yes, then I get the following exception.
java.lang.SecurityException: trusted loader attempted to load sandboxed resource from https://path-to-our.jar
     at com.sun.deploy.security.CPCallbackHandler$ParentCallback.check(Unknown Source)
     at com.sun.deploy.security.CPCallbackHandler$ParentCallback.access$1400(Unknown Source)
     at com.sun.deploy.security.CPCallbackHandler$ChildElement.checkResource(Unknown Source)
     at com.sun.deploy.security.DeployURLClassPath$JarLoader.checkResource(Unknown Source)
     at com.sun.deploy.security.DeployURLClassPath$JarLoader.getResource(Unknown Source)
     at com.sun.deploy.security.DeployURLClassPath.getResource(Unknown Source)
     at java.net.URLClassLoader$1.run(Unknown Source)
     at java.security.AccessController.doPrivileged(Native Method)
     at java.net.URLClassLoader.findClass(Unknown Source)
     at com.sun.jnlp.JNLPClassLoader.findClass(Unknown Source)
     at java.lang.ClassLoader.loadClass(Unknown Source)
     at java.lang.ClassLoader.loadClass(Unknown Source)
     at main.JwsMain.main(JwsMain.java:32)
     at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
     at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
     at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
     at java.lang.reflect.Method.invoke(Unknown Source)
     at com.sun.javaws.Launcher.executeApplication(Unknown Source)
     at com.sun.javaws.Launcher.executeMainClass(Unknown Source)
     at com.sun.javaws.Launcher.doLaunchApp(Unknown Source)
     at com.sun.javaws.Launcher.run(Unknown Source)
     at java.lang.Thread.run(Unknown Source)If I press "no" I get the following exception (I get this exception if I try to run our WebStart application with no signed jars as well, no warnings about missing certs, just straight to error)
java.lang.NullPointerException
     at com.sun.deploy.cache.CachedJarFile.findMatchingSignerIndices(Unknown Source)
     at com.sun.deploy.cache.CachedJarFile.entryNames(Unknown Source)
     at com.sun.deploy.cache.DeployCacheJarAccessImpl.entryNames(Unknown Source)
     at com.sun.deploy.security.CPCallbackHandler.assertTrust(Unknown Source)
     at com.sun.deploy.security.CPCallbackHandler.access$700(Unknown Source)
     at com.sun.deploy.security.CPCallbackHandler$ParentCallback.check(Unknown Source)
     at com.sun.deploy.security.CPCallbackHandler$ParentCallback.access$1400(Unknown Source)
     at com.sun.deploy.security.CPCallbackHandler$ChildElement.checkResource(Unknown Source)
     at com.sun.deploy.security.DeployURLClassPath$JarLoader.checkResource(Unknown Source)
     at com.sun.deploy.security.DeployURLClassPath$JarLoader.getResource(Unknown Source)
     at com.sun.deploy.security.DeployURLClassPath.getResource(Unknown Source)
     at java.net.URLClassLoader$1.run(Unknown Source)
     at java.security.AccessController.doPrivileged(Native Method)
     at java.net.URLClassLoader.findClass(Unknown Source)
     at com.sun.jnlp.JNLPClassLoader.findClass(Unknown Source)
     at java.lang.ClassLoader.loadClass(Unknown Source)
     at java.lang.ClassLoader.loadClass(Unknown Source)
     at main.JwsMain.main(JwsMain.java:32)
     at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
     at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
     at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
     at java.lang.reflect.Method.invoke(Unknown Source)
     at com.sun.javaws.Launcher.executeApplication(Unknown Source)
     at com.sun.javaws.Launcher.executeMainClass(Unknown Source)
     at com.sun.javaws.Launcher.doLaunchApp(Unknown Source)
     at com.sun.javaws.Launcher.run(Unknown Source)
     at java.lang.Thread.run(Unknown Source)Does anyone know why this would be happening? It only occurs with the new update. We use the same keystore and process for signing all of our jars so it really doesn't make since why some of them work and some of them don't. Also, our JNLP is correct or it wouldn't work in update 18.
Edit: We've tried it on Windows XP SP3 and compiled the code using update 18 and used jarsigner both from 18 and 19 with same results.
Edited by: chenthor on Apr 1, 2010 8:44 AM
Edited by: chenthor on Apr 1, 2010 8:51 AM

Hi All,
So we've been battling this bug for a year or so now, and I've come up with a solution to the webstart bugs
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6967414
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6805618
(see the bugs for more details)
From what we can tell the bug stems from the way that the jar signers information is "cached" by webstart.
When a jar is loaded by webstart, it is represented by a CachedJarFile instance. When loading and using classes the signature for the jar is verified. The signers used is the one that is stored in the CachedJarFile instances. These "signers" are stored as SoftReferences. SoftReferences are like WeakReferences, except that they only become eligible for garbage collection when there is a small amount of available heaps space remaining and that the object is only softly reachable. (That's a pretty crude description, but it will do for now)
So what we found was happening is that when the JVM reached a certain heap size threshold and needed to allocate more heap, that these soft references (and hence the signers information) werebeing garbage collected. if you attempt to load a class after this you get the security error.
So I came up with a hack to work around this. At application startup, iterate through all of the CachedJarFile objects on the classpath and create a hard reference to each of the signers info by putting them in a static list somewhere. From our tests this seems to work. (though with the intermittent nature of the problem, it has been hard to prove conclusively, though we've had some success repro-ing the issue, by reducing the intial heap size and using VisualVM to watch for heap expansions and forcing gc's)
Below is the code for the hack, to run it just call JarSignersHardLinker.go() and it will do some sanity checks (running on webstart on java 1.6 update 19 or higher) before spawning a new thread to create hard refs for all signers info for all jars on the classpath.
import java.io.IOException;
import java.lang.ref.SoftReference;
import java.lang.reflect.Field;
import java.lang.reflect.InvocationTargetException;
import java.lang.reflect.Method;
import java.net.JarURLConnection;
import java.net.URL;
import java.net.URLConnection;
import java.util.ArrayList;
import java.util.Enumeration;
import java.util.LinkedHashSet;
import java.util.List;
import java.util.Set;
import java.util.jar.JarFile;
* A utility class for working around the java webstart jar signing/security bug
* see http://bugs.sun.com/view_bug.do?bug_id=6967414 and http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6805618
* @author Scott Chan
public class JarSignersHardLinker {
    private static final String JRE_1_6_0 = "1.6.0_";
     * the 1.6.0 update where this problem first occurred
    private static final int PROBLEM_JRE_UPDATE = 19;
    public static final List sm_hardRefs = new ArrayList();
    protected static void makeHardSignersRef(JarFile jar) throws java.io.IOException {
        System.out.println("Making hard refs for: " + jar );
        if(jar != null && jar.getClass().getName().equals("com.sun.deploy.cache.CachedJarFile")) {
             //lets attempt to get at the each of the soft links.
             //first neet to call the relevant no-arg method to ensure that the soft ref is populated
             //then we access the private member, resolve the softlink and throw it in a static list.
            callNoArgMethod("getSigners", jar);
            makeHardLink("signersRef", jar);
            callNoArgMethod("getSignerMap", jar);
            makeHardLink("signerMapRef", jar);
//            callNoArgMethod("getCodeSources", jar);
//            makeHardLink("codeSourcesRef", jar);
            callNoArgMethod("getCodeSourceCache", jar);
            makeHardLink("codeSourceCacheRef", jar);
     * if the specified field for the given instance is a Softreference
     * That soft reference is resolved and the returned ref is stored in a static list,
     * making it a hard link that should never be garbage collected
     * @param fieldName
     * @param instance
    private static void makeHardLink(String fieldName, Object instance) {
        System.out.println("attempting hard ref to " + instance.getClass().getName() + "." + fieldName);
        try {
            Field signersRef = instance.getClass().getDeclaredField(fieldName);
            signersRef.setAccessible(true);
            Object o = signersRef.get(instance);
            if(o instanceof SoftReference) {
                SoftReference r = (SoftReference) o;
                Object o2 = r.get();
                sm_hardRefs.add(o2);
            } else {
                System.out.println("noooo!");
        } catch (NoSuchFieldException e) {
            e.printStackTrace();
            return;
        } catch (IllegalAccessException e) {
            e.printStackTrace();
     * Call the given no-arg method on the given instance
     * @param methodName
     * @param instance
    private static void callNoArgMethod(String methodName, Object instance) {
        System.out.println("calling noarg method hard ref to " + instance.getClass().getName() + "." + methodName + "()");
        try {
            Method m = instance.getClass().getDeclaredMethod(methodName);
            m.setAccessible(true);
            m.invoke(instance);
        } catch (SecurityException e1) {
            e1.printStackTrace();
        } catch (NoSuchMethodException e1) {
            e1.printStackTrace();
        } catch (IllegalArgumentException e) {
            e.printStackTrace();
        } catch (IllegalAccessException e) {
            e.printStackTrace();
        } catch (InvocationTargetException e) {
            e.printStackTrace();
     * is the preloader enabled. ie: will the preloader run in the current environment
     * @return
    public static boolean isHardLinkerEnabled() {
         boolean isHardLinkerDisabled = false; //change this to use whatever mechanism you use to enable or disable the preloader
        return !isHardLinkerDisabled && isRunningOnJre1_6_0_19OrHigher() && isRunningOnWebstart();
     * is the application currently running on webstart
     * detect the presence of a JNLPclassloader
     * @return
    public static boolean isRunningOnWebstart() {
        ClassLoader cl = Thread.currentThread().getContextClassLoader();
        while(cl != null) {
            if(cl.getClass().getName().equals("com.sun.jnlp.JNLPClassLoader")) {
                return true;
            cl = cl.getParent();
        return false;
     * Is the JRE 1.6.0_19 or higher?
     * @return
    public static boolean isRunningOnJre1_6_0_19OrHigher() {
        String javaVersion = System.getProperty("java.version");
        if(javaVersion.startsWith(JRE_1_6_0)) {
            //then lets figure out what update we are on
            String updateStr = javaVersion.substring(JRE_1_6_0.length());
            try {
                return Integer.parseInt(updateStr) >= PROBLEM_JRE_UPDATE;
            } catch (NumberFormatException e) {
                //then unable to determine updatedate level
                return false;
        //all other cases
        return false;
      * get all the JarFile objects for all of the jars in the classpath
      * @return
     public static Set<JarFile> getAllJarsFilesInClassPath() {
          Set<JarFile> jars = new LinkedHashSet<JarFile> ();
         for (URL url : getAllJarUrls()) {
             try {
                 jars.add(getJarFile(url));
             } catch(IOException e) {
                  System.out.println("unable to retrieve jar at URL: " + url);
         return jars;
     * Returns set of URLS for the jars in the classpath.
     * URLS will have the protocol of jar eg: jar:http://HOST/PATH/JARNAME.jar!/META-INF/MANIFEST.MF
    static Set<URL> getAllJarUrls() {
        try {
            Set<URL> urls = new LinkedHashSet<URL>();
            Enumeration<URL> mfUrls = Thread.currentThread().getContextClassLoader().getResources("META-INF/MANIFEST.MF");
            while(mfUrls.hasMoreElements()) {
                URL jarUrl = mfUrls.nextElement();
//                System.out.println(jarUrl);
                if(!jarUrl.getProtocol().equals("jar")) continue;
                urls.add(jarUrl);
            return urls;
        } catch(IOException e) {
            throw new RuntimeException(e);
     * get the jarFile object for the given url
     * @param jarUrl
     * @return
     * @throws IOException
    public static JarFile getJarFile(URL jarUrl) throws IOException {
        URLConnection urlConnnection = jarUrl.openConnection();
        if(urlConnnection instanceof JarURLConnection) {
            // Using a JarURLConnection will load the JAR from the cache when using Webstart 1.6
            // In Webstart 1.5, the URL will point to the cached JAR on the local filesystem
            JarURLConnection jcon = (JarURLConnection) urlConnnection;
            return jcon.getJarFile();
        } else {
            throw new AssertionError("Expected JarURLConnection");
     * Spawn a new thread to run through each jar in the classpath and create a hardlink
     * to the jars softly referenced signers infomation.
    public static void go() {
        if(!isHardLinkerEnabled()) {
            return;
        System.out.println("Starting Resource Preloader Hardlinker");
        Thread t = new Thread(new Runnable() {
            public void run() {
                try {
                    Set<JarFile> jars = getAllJarsFilesInClassPath();
                    for (JarFile jar : jars) {
                        makeHardSignersRef(jar);
                } catch (Exception e) {
                    System.out.println("Problem preloading resources");
                    e.printStackTrace();
                } catch (Error e) {
                     System.out.println("Error preloading resources");
                     e.printStackTrace();
        t.start();
}

SA520W: difficulty getting self certificate request signed by trusted 3rd party

Please forgive me if this is a dumb question or if I am fundamentally confused, but I have pored over the manual, forum, and web. Very simply I need a trusted third party to sign my CSR and then for the SA520W to accept it as the active self certificate. In principle this is straightforward but I cannot figure out how to make this work in practice. Two examples.
1) GoDaddy: they require a 2048 bit signature and the router only generates 1024. I can generate my own CSR with OpenSSL but then am unable to upload my 2048 bit key to the router, and thus the signed certificate is not accepted
2) Verisign. They will take the router's 1024 bit signature, but they require lots of fields in the CSR, like country and state, that are not supported by the router's generate CSR function. Thus Verisign will not accept the CSR.
Is there any way to get the router to accept a CSR signed by GoDaddy? Or any CA?
Thanks in advance.
Andy

Sorry to dredge up an old thread, but I've been trying to get this to work for the last three weeks also.
The firmware supports a 2048 bit key, so that's not the issue.
I entered all the information that the registrar wanted into the CN field, in the correct format.
The registrar has accepted the CSR and generated the certificate, and returned it to me.
I'm using a Geotrust quickSSL certificate.
Now, the issue is that I can't upload the certificate. If I try and load it, I get the error;
"No trusted certificate found, Can't Upload Self Certificate"
So, I'm guessing it is a chaining issue. I go to http://www.geotrust.com/resources/root-certificates/
I download the Root 1 "Download - Equifax Secure Certificate Authority (Base-64 encoded X.509) Right Click, Save As"
and then I try to add it to the SA520 as a trusted certificate...
"Added Trusted Certificate"
Now I try adding my signed certificate again, and get the error;
"No trusted certificate found, Can't Upload Self Certificate"
So we're still missing something (intermediate certificate(?)), so I try adding the next one in the list;
I download Root 2 "Download - GeoTrust Global CA (Base-64 encoded X.509) Right Click, Save As"
and try to add it to the SA520 as a trusted certificate...
"Cannot Add Trusted Certificate"
So I try the next one...
I download Root 3 "Download - GeoTrust Primary CA (.pem file) Right Click, Save As"
and then I try to add it to the SA520 as a trusted certificate...
"Added Trusted Certificate"
So, once again, I try my signed certificate and get the same error;
"No trusted certificate found, Can't Upload Self Certificate"
So I give up on the Cisco, and go to a Mac which has great keychain management.
I open my signed certificate on the mac, and see it is issued by "GeoTrust DV SSL CA"
Hang on, that's the "Root 2" certificate above that wouldn't load. I try add the Root 2 again, but I get the same error
So I contact Geotrust and get them to send me the DV SSL CA file, which I upload successfully.
Now, I have three trusted Certificates from Geotrust loaded.
Trusted Certificates (CA Certificate)
CA Identity (Subject Name)
Issuer Name
Expiry Time
C=US, O=GeoTrust Inc., CN=GeoTrust Global CA
C=US, O=GeoTrust Inc., CN=GeoTrust Global CA
May 21 04:00:00 2022 GMT
C=US, O=GeoTrust Inc., OU=Domain Validated SSL, CN=GeoTrust DV SSL CA
C=US, O=GeoTrust Inc., CN=GeoTrust Global CA
Feb 25 21:32:31 2020 GMT
C=US, O=GeoTrust Inc., CN=GeoTrust Primary Certification Authority
C=US, O=GeoTrust Inc., CN=GeoTrust Primary Certification Authority
Jul 16 23:59:59 2036 GMT
So I try once again to upload my signed certificate, and once again, I get:
"No trusted certificate found, Can't Upload Self Certificate"
So, the question is, WHAT is going on ? Has anyone at Cisco managed to load a GeoTrust certficate into this device, if so, step by step, HOW ?
Thanks !

Signed Jars

I have a web based project that includes numerous iamges. As a result of the images I must sign the jar files. However, to date I have been unsuccessful. I have reviewed the threads and deployment information and would appreciate a straightforward way to accomplish this with Net Beans (the signing function there has not worked for me as well). I would appreciate any assistance.

If you can place the images inside your jar file and load them from there or place them on a server that hosts crossdomain.xml (*exactly* this file http://static.flickr.com/crossdomain.xml) in the root directory of it's domain, then you do not need to sign your jar file. If you cannot do either of these things and the images must be hosted on a different server than the one hosting your jars, then read on.
Do not try to use the javafxpackager command line tool to sign jars as that does not currently work => this issue can be tracked here: http://javafx-jira.kenai.com/browse/RT-18246
Signing documentation is here =>
http://docs.oracle.com/javafx/2.0/deployment/packaging.htm#BABJGFBH
http://docs.oracle.com/javafx/2.0/deployment/javafx_ant_task_reference001.htm#CIAFJGAB
But you have already read all that.
Signing requires the following steps.
1. Generate a Certificate Signing Request (CSR).
2. Submit the CSR to a Certificate Authority (CA).
3. The CA will generate a code signing certificate for you.
4. Package your application as a bunch of jar files.
5. Sign the jar files using your code signing certificate.
If you are just using a self signed certificate and you are already using NetBeans, then NetBeans can do all of this for you.
Here are the steps I used to sign a JavaFX project consisting of multiple Jar files using NetBeans nightly build 201112120600
1. Right click Project and choose Properties.
2. Project Properties | Libraries | Compile |Add Library... and add your dependent jars.
3. Project Properties | Packaging
Check Compress JAR File
Check Build JAR after Compiling
Check Copy Dependent Libraries
Do not check Binary Encode JavaFX CSS Files as that might be buggy.
4. Project Properties | Deployment
Check Request unrestricted access
Signing Certificate: Edit...
a) choose Self-signed by a generated key OR
b) use your own keystore if you have a certificate from a trusted public CA.
Download Mode for Libraries: Use the mix of eager and lazy appropriate for your app. Signing wise, it doesn't matter as all of the jars need to be signed anyway.
5. Project Properties | Run
Configuration | New... | Configuration Name => enter browser
Application Class | Browse... choose your Application's main class.
Check Use Preloader if you have one (the preloader jar will be signed). If you are having difficulties with basic signing, get that to work first before enabling the Preloader.
Select Run | in Browser
Set a Width and Height for the page.
Leave Web Page empty until you get an empty web page with your app in it to work.
Choose the Web Browser you want to launch the app in.
Press OK.
6. Select the browser config from the drop down combo and hit the run arrow.
Netbeans will compile your app, package it, generate a self signed certificate, sign all of your application's jars and launch the application in a browser.
A trick to getting all of the above to work more than one time, is to make sure that you close the browser tab after you have finished testing and before you try to run again, otherwise NetBeans seems to fail with weird errors because the distribution files get locked by the app running inside the browser under Windows.
If you are still stuck, you can try opening this JavaFX project which uses self-signed jars in NetBeans 7.1 RC2 or later => http://willow-browser.googlecode.com/files/willow-src-prerelease-0.1-netbeans-project.zip

Verifying signed Jar using Java code

Hi,
I have been looking for a way to verify signed or unsigned jar from java code.
I have to use the jar name and from here, I have to verify the digital signature. For this goal I have found some Java classes which can be useful for me. These classes would be JarEntry class, from which I could get the certificates. Signature class, whose methods let me verify the digital signatures, and Certificate class. I also found a class called SignedObject from I could get the signature data which the method getSignature (), but the problem here it is that I need a private key in the SignedObject constructor, which is not possible since I want to verify a signed jar which I am not able to know the private key, just public key. So, could anybody tell me how I could solve this problem?
My code would be some as shown below:
jar = new JarEntry (location);
          jarcertificates = jar.getCertificates();
          /* We should check all the certificates
          if (jarcertificates != null){
               for (int i=0;i<jarcertificates.length;i++){
                    sig.initVerify(jarcertificates);
                    sig.update(jar.getExtra());
                    sig.verify( DIGITAL SIGNATURE FROM JAR SHOULD BE HERE);
I guess that I have to use jar.getExtra () in order to get the data to put in Signature.update() method but I am not sure, am I wrong?
Thanks in advance

Here is some sample code to verify a jar file:
        JarFile jf = new JarFile(args[0], true);
        byte[] buffer = new byte[8192];
        Enumeration e = jf.entries();
        ArrayList entries = new ArrayList();
        while (e.hasMoreElements()) {
            JarEntry je = (JarEntry) e.nextElement();
            entries.add(je);
            InputStream is = jf.getInputStream(je);
            while (is.read(buffer, 0, buffer.length) != -1) {
                // we just read. this will throw a SecurityException
                // if a signature/digest check fails.
            is.close();
        }To validate the certificate chain, you can call JarEntry.getCertificates(), create a CertPath from the array of Certificates (using a CertificateFactory), and then use the CertPathValidator APIs. For more information, see the PKI Programmer's guide: http://java.sun.com/javase/6/docs/technotes/guides/security/certpath/CertPathProgGuide.html

How do I sign my VB / VS 2010 based shared COM add-in for Excel so it loads when the user has checked "Require application add-ins to be signed by a trusted publisher"?

My COM add-in is developed using VS 2010 and VB. It's a shared COM add-in (not VSTO) and it works with Excel 2007 - 2013. My installer is signed with a code signing certificate but it would appear that my add-in's .dll should also be signed if the user has
checked the "Require application add-ins to be signed by a trusted publisher" option.
The "Sign the assembly" option is checked in my add-in's VB -> My Project -> Signing. I have a .snk file selected which I seem to recall generating 6 or 7 years ago when I ported the COM add-in from VB6 to .NET.
I have an up-to-date Comodo code signing certificate (a pfx file called MyCompanyCodeSigningCertificatePrivateKey.pfx) which I purchased to use with the installer and was wondering if and how I could use this.
I tried selecting my pfx file in the My Project -> Signing -> "Choose a strong name key file" dialog. It made a copy of the pfx file in my project folder but when I tried to build the project, I got the following error:
Error 1 Cannot import the following key file: MyCompanyCodeSigningCertificatePrivateKey.pfx. The key file may be password protected. To correct this, try to import the certificate again or manually install the certificate to the Strong Name CSP with the
following key container name: VS_KEY_C0B6F251F0FB6016
After a little research, I found out I might be able to use signtool to sign the dll in a post-build step.
I added the following command to the post-build event, before the command I use to regasm the assembly.
"path to signtool\signtool" sign /f "MyCompanyCodeSigningCertificatePrivateKey.pfx" /p "xxxx" /v "$(TargetPath)"
When I built the project, the dll appeared to get signed (the output window showed a bunch of confirming text as well as "Successfully signed: c:\MyAddIn\bin\Release\MyAddIn.dll") but the next step in the post-build (regasm myaddin.dll /codebase)
issued a warning RA0000 (see below) but reported "Types registered successfully".
Here's the message I get from regasm, even though the output window says the dll was sucessfully signed:
RegAsm : warning RA0000: Registering an unsigned assembly with /codebase can cause your assembly to interfere with other applications that may be installed on the same computer. The /codebase switch is intended to be used only with signed assemblies. Please give your assembly a strong name and re-register it.
Types registered successfully
I'm not using a shim if that makes a difference.
How do I sign my add-in so it loads when the user has checked "Require application add-ins to be signed by a trusted publisher"?
Any tips would be appreciated.

Hello,
Why do you need to use the regasm utility from the post-build action?
There is a difference between signing the assembly with a strong name and digital signature. The
How to: Sign an Assembly with a Strong Name article in MSDN explains how to sign an assembly with a strong name (.snk). See
How to digitally sign a strong named assembly for adding a digital signature.
You may also find the
What's the Difference, Part Five: certificate signing vs strong naming article helpful.

"Symantec Class 3 EV SSL CA - G2" intermediate Certificate Authority is not trusted by Firefox ?

''locking as duplicate of [https://support.mozilla.org/en-US/questions/1014430 /questions/1014430]''
Hallo
We recently purchased a certificate from Symantec. It's intermediate authority is Symantec Class 3 EV SSL CA - G2, but Mozilla firefox doesn't seem to trust it. Other browsers (IE and Chrome) have the certificate chain trusted. Is there a way to add this certificate chain in Firefox, because many of our clients using Firefox are complaining and asking about our site's security.

hello JKlecherov, firefox shouldn't give any error, when the intermediary certificate is properly linked to the root ca. please refer to symantec's documentation how to install it on your server or you can also use their tool at https://ssltools.websecurity.symantec.com/checker/views/certCheck.jsp

Add intermediate certificate to signed jar

Similar Messages

Maybe you are looking for