Signing Jars For JWS

My company just got me a Java coding signing cert from Verisign for signing the jar files used by our JWS application. At first I could not get cert to inport using keytool. So based on a suggestion from someone, I imported the cert into IE to verify it was a valid cert. This worked fine, so I exported the cert from IE in 509 format. I was then able to import the cert into a keystore. The problem is when I attempt to sign my jar files I get the error: jarsigner: Certificate chain not found for: signfiles. signfiles must reference a valid KeyStore key entry containing a private key and corresponding public key certificate chain.
What does this mean, and how do I fix it?
Thanks,
Jim Urban

I got the same error.
But then I found out that a pkcs12 file could be used directly as a keystore by jarsigner. So you can skip the keytools step.
I exported my certificate from Netscape Communicator using the Security tool as a .p12 file. Then I pointed jarsigner at my pkcs12 file.
jarsigner -storetype pkcs12 -keystore cert.p12 MyClasses.jar keyname
You can find your keyname alias by entering:
keytool -list -storetype pkcs12 -keystore cert.p12

Similar Messages

SSL Cert used to sign Jars for distribution via WebStart

Hi,
I have an SSL cert (Comodo InstallSSL) for my website and wondered if I can use it to sign jars so, when distributed via webstart, the old "untrusted source" message doesn't get displayed. I've been doing a lot of reading but, to be honest, I can't really find my bearings! I have imported the cert into my keystore but get the message when I try to sign a jar:
Certificate chain not found for: myalias myalias must reference a valid KeyStore key entry containing a private key and corresponding public key certificate chain.I have the following files in relation to my cert:
xxx.cabundle (this can be imported into keytool easily)
cert/xxx.crt (looks like a PGP file, cannot be imported (-import) into keytool)
private/xxx.key
My questions I suppose are:
1. Can I use a cert issued for SSL to sign jars for webstart distribution?
2. If yes to 1; what steps other than importing the cert alone (which generates the message above) do I need to do to achieve this?
Any help would be appreciated!
Rich

Hi,
yes, the pkcs12 certificate includes the private key, as opposed to pb7 which does not.
Sent from Cisco Technical Support Android App

Error when i try to sign .jar for webutil

i have try to use signwebutil.bat in webutil 1.0.6 but i have the follow error_
Generating a self signing certificate for key=webutil2...*
Errore keytool: java.lang.Exception: Non è stata generata la coppia di chiavi, l'alias <webutil2> è già esistente*
+.+
There were warnings or errors while generating a self signing certificate. Please review them.*
+.+
Backing up d:\w\jacob.jar as d:\w\jacob.jar.old...*
+1 file copiati.+
Signing d:\w\jacob.jar using key=webutil2...*
+.+
There were warnings or errors while signing the jar. Please review them.*
Generating a self signing certificate for key=webutil2...*
Errore keytool: java.lang.Exception: Non è stata generata la coppia di chiavi, l'alias <webutil2> è già esistente*
+.+
There were warnings or errors while generating a self signing certificate. Please review them.*
+.+
Backing up d:\w\frmwebutil.jar as d:\w\frmwebutil.jar.old...*
+1 file copiati.+
Signing d:\w\frmwebutil.jar using key=webutil2...*
+.+
There were warnings or errors while signing the jar. Please review them.*

Maybe you could try to change the values in your sign_webutil.bat file:
REM Give your alias key here.
REM
SET JAR_KEY=webutil3
REM
REM Key Password for the given key to be used for signing.
REM
SET JAR_KEY_PASSWORD=webutil3
REM
REM Number of days before this certificate expires
REM
SET VALIDDAYS=360
Francois

Common jars for JWS and non-JWS Java Apps?

Java Application 'A' is installed to file system - not JWS. App 'A' has some jars in common with Java Application 'B', which we would like to deploy using JWS. Do I have to:
a) duplicate the common jars - once on the file system for App 'A' and once in the cache for App 'B'?
b) keep the common jars only on the file system - but somehow make them visible to the JWS App 'B'?
c) keep the common jars only in the JWS cache - but somehow make them visible to the non-JWS App 'A'?
Please advise.
Thanks in advance.
-eman

Regarding "Enabling Single Sign-On from SAP J2EE Engine/EP to Non-SAP Java Applications" by Tim Mullé, Stephan Boecker
Could anyone who has this document say if "How to Enable Single Sign-on with Non-SAP Web Application" by Sudip Majumder (Tata Consultancy Services) is a direct replacement and contains all the same information?
It is currently at: https://www.sdn.sap.com/irj/sdn/go/portal/prtroot/docs/library/uuid/d0c78148-12de-2a10-27bf-960acc753aab
(until SAP deletes it

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

Signed jars and HTTPS

I'm running a web application from jetty, which involves an applet on the client-side, JSPs/servlets on the server.
The applet jars needs to be signed during our build proces (by my company's keystore based on our purchased cert) but the customer will need to provider their own cert to run the https pages.
Is there a way to do this? Right now, I"m getting the "signer information does not match signer information of other classes in the same package" when I try to run it in HTTPS. This could be due to my jetty HTTPS settings not being quite ready (pointing at a keystore which is incorrect) - but I want to make sure that I can at least do what I need to do? If so, any suggestions/advice/tips would be most welcome!
thanks

I'm trying to use the KeyStore that the applets were signed with on my local build as the KeyStore I'm pointing to when starting up Jetty. This still leads to the 'signer information does not match signer information of other classes in the same package' error when trying to accept one of my signed jars for use. I exported a cert from the keystore used in the build and imported that into my browser as well.
I also tried using a keystore with a self signed certificate for running Jetty and had the same problem.
When not running in HTTPS, I can use all the signed jars and everything works fine. Is the conflict between the signature on the jars and the one jetty's using for SSL? Why didnt using the same keysotreAnd if so, why doesn't accepting all the jars and certs help out? I may need to do something programatically in the code for this, I guess - tho I'm not sure where to start out.
If anyone's had a similar problem, I'd appreciate hearing how you'd worked it out.
thanks,
tOm

Signing a trusted jar for use with forms

I have not found sufficient documentation on how to sign a new jar for use in conjunction with forms.
I have read the descriptions in the getCLientInfo bean.
This doesn't cover the whole subject.
What must be done in Jinitiator? for instance.
Can someone direct me to a more exhaustive source of information?
I've done everything I can think of and /or discover and I'm still getting Security exceptions.
Mick

Adrienk wrote:
is the a tutorial on how to open a .jar file and use it with in eclipse by keeping the same file structure?Is your shift key broken, or are you just too lazy to apply once at the start of each sentence?
In any case, for Eclipse problems, see [http://www.google.com/#q=eclipse+forum].

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.

I look for guider in signing jars

Hi everybody
for what signing jars is good,for applet jars or desktop applications jars???
and how can I use it? please i need the answerer explanations not url to tutorials
Thanks to every reader to this topic

i need the answerer explanations not url to tutorialsA stupid remark. The tutorials are explanations, and they have already been reviewed, debugged, etc. Why on earth would you prefer someone's random opinion to a properly produced piece of documentation?
At best this is just lazy thinking.

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 ;)

Problem Packing Signed JARs of more than 10 MB

Hi friends of Java,
there seems to be a size issue when packing signed JARs.
When I try to pack a signed JAR of about 5 MEGs (such as the jbossall_client.jar file) it works (i.e. jarsigner can verify the result),
but if i try doing it with a JAR of about 11 MEGs the jarsigner can't verify the packed (and unpacked again) file.
Example:
C:\p\u\ccm_wa\basis_web\santafu~tnagel\santafu>dir temp\webstart\BasisWebClient.jar
06.03.2009 17:32 10.943.963 BasisWebClient.jar
C:\p\u\ccm_wa\basis_web\santafu~tnagel\santafu>pack200 --repack temp\webstart\BasisWebClient.jar
C:\p\u\ccm_wa\basis_web\santafu~tnagel\santafu>jarsigner -storepass xxxxxx -keystore resources\build\key\BasisWebKeystore temp\webstart\BasisWebClient.jar BasisWeb
C:\p\u\ccm_wa\basis_web\santafu~tnagel\santafu>jarsigner -verify temp\webstart\BasisWebClient.jar
jar verified.
C:\p\u\ccm_wa\basis_web\santafu~tnagel\santafu>pack200 temp\webstart\BasisWebClient.jar.pack.gz temp\webstart\BasisWebClient.jar
C:\p\u\ccm_wa\basis_web\santafu~tnagel\santafu>unpack200 temp\webstart\BasisWebClient.jar.pack.gz test.jar
C:\p\u\ccm_wa\basis_web\santafu~tnagel\santafu>jarsigner -verify test.jar
jarsigner: java.lang.SecurityException: SHA1 digest error for basisweb/vg/presenter/SchluesselBezeichnungDialogPresenter.class
The same with a smaller file:
C:\p\u\ccm_wa\basis_web\santafu~tnagel\santafu>dir temp\webstart\jbossall-client.jar
31.08.2007 07:31 4.895.807 jbossall-client.jar
C:\p\u\ccm_wa\basis_web\santafu~tnagel\santafu>pack200 --repack temp\webstart\jbossall-client.jar
C:\p\u\ccm_wa\basis_web\santafu~tnagel\santafu>jarsigner -storepass xxxxx -keystore resources\build\key\BasisWebKeystore temp\webstart\jbossall-client.jar BasisWeb
C:\p\u\ccm_wa\basis_web\santafu~tnagel\santafu>jarsigner -verify temp\webstart\jbossall-client.jar
jar verified.
C:\p\u\ccm_wa\basis_web\santafu~tnagel\santafu>pack200 temp\webstart\jbossall-client.jar.pack.gz temp\webstart\jbossall-client.jar
C:\p\u\ccm_wa\basis_web\santafu~tnagel\santafu>unpack200 temp\webstart\jbossall-client.jar.pack.gz test.jar
C:\p\u\ccm_wa\basis_web\santafu~tnagel\santafu>jarsigner -verify test.jar
jar verified.
It also works when I split the original JAR in multiple parts. Any ideas?
Used Java Version:
java version "1.6.0_12"
Java(TM) SE Runtime Environment (build 1.6.0_12-b04)
Java HotSpot(TM) Client VM (build 11.2-b01, mixed mode, sharing)
OS: Windows XP Pro Version 2002 SP2
PC: Intel Pentium 4 3.2GHz, 2GB RAM, 160 GB HD
Regards from Germany,
Thomas Nagel

Hello Bryan,
I dont have a solution yet. Currently we use the jars uncompressed. Sad, but that works.
For the future, we are not really sure wether we can stick with JWS, as the signed JNLP-file-issue might make us even more trouble.
I've done some error search. Look at the following.
Try for your own with some different sized jar's, and maybe post the results (definitely if they all pass):
--- snip ----
package ctest;
import java.io.File;
import java.io.FileOutputStream;
import java.io.IOException;
import java.util.Enumeration;
import java.util.Map;
import java.util.jar.*;
import java.util.jar.Pack200.*;
* @author tnagel
public class PackTest implements Runnable {
     String test1 = "junit";
     String test2a = "xalan";
     String test2 = "jbossall-client";
String test3 = "BasisWebClient2";
String dir = "/tmp/";
String ext1 = ".jar";
String ext2 = ".jar.pack.gz";
//String infile = "/tmp/BasisWebClient.jar";
//String outfile = "/tmp/BasisWebClient.jar.pack.gz";
//String testfile = "/tmp/testaus.jar";
* @param args the command line arguments
public static void main(String[] args) {
     PackTest me = new PackTest(args);
public PackTest(String[] args) {
this.run();
public void setProperties(Packer packer) {
// Initialize the state by setting the desired properties
Map p = packer.properties();
// take more time choosing codings for better compression
p.put(Packer.EFFORT, "9"); // default is "5"
//// use largest-possible archive segments (>10% better compression).
// p.put(Packer.SEGMENT_LIMIT, "-1");
//// reorder files for better compression.
//p.put(Packer.KEEP_FILE_ORDER, Packer.FALSE);
//// smear modification times to a single value.
//p.put(Packer.MODIFICATION_TIME, Packer.LATEST);
//// ignore all JAR deflation requests,
//// transmitting a single request to use "store" mode.
//p.put(Packer.DEFLATE_HINT, Packer.FALSE);
//// discard debug attributes
//p.put(Packer.CODE_ATTRIBUTE_PFX+"LineNumberTable", Packer.STRIP);
// throw an error if an attribute is unrecognized
p.put(Packer.UNKNOWN_ATTRIBUTE, Packer.ERROR);
//// pass one class file uncompressed:
//p.put(Packer.PASS_FILE_PFX+0, "mutants/Rogue.class");
@Override
public void run() {
     doTest(test1, true);
     doTest(test2, true);
     doTest(test3, true);
     doTest(test3, true);
     doTest(test3, true);
private void doTest(String test, boolean compare) {
String infile = dir + test + ext1;      // "/tmp/BasisWebClient.jar";
String outfile = dir + test + ext2; // "/tmp/BasisWebClient.jar.pack.gz";
String testfile = dir + test+ "-aus" + ext1;
try {
     countJar(infile, false);
     JarFile jarFile = new JarFile(infile);
FileOutputStream fos = new FileOutputStream(outfile);
// Create the Packer object
Packer packer = Pack200.newPacker();
setProperties(packer);
// call the packer
long startTimeMethode =System.currentTimeMillis();
packer.pack(jarFile, fos);
System.out.println("Time for Pack: " + (System.currentTimeMillis() - startTimeMethode));
jarFile.close();
fos.close();
File f = new File(outfile);
FileOutputStream fostream = new FileOutputStream(testfile);
JarOutputStream jostream = new JarOutputStream(fostream);
Unpacker unpacker = Pack200.newUnpacker();
// Call the unpacker
startTimeMethode =System.currentTimeMillis();
unpacker.unpack(f, jostream);
System.out.println("Time for Unpack: " + (System.currentTimeMillis() - startTimeMethode));
// Must explicitly close the output.
jostream.close();
     countJar(testfile, false);
     if(compare) compareJars(infile,testfile);
} catch (IOException ioe) {
     System.err.println(ioe);
ioe.printStackTrace();
private void countJar(String filename, boolean showDetails) {
     JarFile jarFile1 = null;
     try {
          int entries = 0;
          long sizeTotal = 0L;
          long compressedSum = 0L;
          jarFile1 = new JarFile(filename);
          Enumeration e = jarFile1.entries();
          while(e.hasMoreElements()) {
               JarEntry jarE = (JarEntry) e.nextElement();
               entries ++;
               sizeTotal += jarE.getSize();
               compressedSum += jarE.getCompressedSize();
               if(showDetails) {
                    System.out.println( jarE.getName() + " s= " + jarE.getSize() + " c= " + jarE.getCompressedSize() );
          System.out.println( filename + ": " + entries + " entries, " + sizeTotal + " Byte, compressed " + compressedSum + " Byte" );
} catch (IOException ioe) {
     System.err.println(ioe);
ioe.printStackTrace();
} finally {
     try { if(jarFile1 != null) jarFile1.close(); } catch (Exception e) { }
private void compareJars(String erstes, String zweites) {
     JarFile jarFile1 = null;
     JarFile jarFile2 = null;
     try {
          int fehler = 0;
          int entries = 0;
          jarFile1 = new JarFile(erstes);
          jarFile2 = new JarFile(zweites);
          Enumeration e1 = jarFile1.entries();
          Enumeration e2 = jarFile2.entries();
          while(e1.hasMoreElements()) {
               JarEntry jarE1 = (JarEntry) e1.nextElement();
               if(e2.hasMoreElements()) {
                    JarEntry jarE2 = (JarEntry) e2.nextElement();
                    entries++;
                    if(!jarE1.getName().equals(jarE2.getName())) {
                         System.out.println( "Name different at Index= " + entries+ " n1=" + jarE1.getName() + " n2=" + jarE2.getName() );
                         fehler ++;
                         break;
                    if(jarE1.getSize() != jarE2.getSize()) {
                         System.out.println( "Size different at bei " + jarE1.getName() + " Index= " + entries + " s1=" + jarE1.getSize() + " s2=" + jarE2.getSize());
                         fehler ++;
                    if(jarE1.getCrc() != jarE2.getCrc()) {
                         System.out.println( "CRC different at " + jarE1.getName() + " Index= " + entries + " s1=" + jarE1.getCrc() + " s2=" + jarE2.getCrc());
                         fehler ++;
                    if(jarE1.getMethod() != jarE2.getMethod()) {
                         System.out.println( "Method different at " + jarE1.getName() + " Index= " + entries + " m1=" + jarE1.getMethod() + " m2=" + jarE2.getMethod());
                         fehler ++;
          System.out.println( "Errors= " + fehler + " entries=" + entries );
} catch (IOException ioe) {
     System.err.println(ioe);
ioe.printStackTrace();
} finally {
     try { if(jarFile1 != null) jarFile1.close(); } catch (Exception e) { }
     try { if(jarFile2 != null) jarFile2.close(); } catch (Exception e) { }
--- snip ----
Cheers,
Thomas

Read binary files that are wraped in the downloaded executable signed jar

Hello, there:
I have created a Swing application and created a signed jar file and uploaded it to my site. The signed jar includes class packages, and a folder of binary files which are the datasource for my application.
jws downloads this signed executable jar, it'll automatically run it, but it has problems reading the binary folders wrapped in itself (the app is supposed to read the folder's structure and use the info to create a JTree object, and read the file's content as well). Is it the file path conversion problem? Do we need to use URL instead? I tried it after reading some threads on this forum but didn't make it.
As an alternatives, I want JWS to unjar the jar file and expand it to exploded files. I manually unjar it and run the app from command line, it works fine.
Plus, the app is supposed to manipulate the binary files when it's in process, like saving new content back to the files, zip the files and upload them to the remote sql server. therefore, I think it's easy to have it run when it's expanded.
So here is the question: JWS by default is running the executable jar, is there a way to tell JWS to unzip the jar and find the main class in the exploded files and run it?
Thanks a lot for your suggestions,
Sway

You can get to any resource in a jar file in your classpath. The code below will return InputStream for resource.bin nested two packages down.
InputStream in = YourClass.class.getResourceAsStream("/com/mypackage/resouce.bin"); //use '/' instead of '.'You can open a FileOutputStream to write that file.
OutputStream out = new FileOutputStream("myTempResource.bin");
IOUtil.streamAndClose(in,out);If the resouce is a nested zip or nested jar then you can use the Java Zip utilities to unwrap the stream.

DownloadService.loadResource for external jars for 1.6.0-19+

First, be kind with my english, i'm french (nobody's perfect...)
I have a JNLP into which i declare a signed jar resource main.jar. This application retreive at execution a list of signed jar names (+a.jar, b.jar+...) that i dynamically load on my need through DownloadService.loadResource. My a.jar, b.jar are cached and it rules! But if i made a new main.jar, a.jar and b.jar, and deploy them on my server, here what's happend:
- main.jar is tested for modification date on server (thanks to "If-Modified-Since" HTTP header), cache date is before this date, so JWS update main.jar by downloading this new main.jar. This is the behaviour described into specs and it is perfect for me!
- but for others resources (a.jar, b.jar) i was excpected the same behaviour but JWS does not seems to check for modification date. So a.jar and b.jar are not updated.
So my first question: Is there a way to tell to DownloadService.loadResource to check for modification date? i could deal with jar version but this basic date checking was great for me...
Except this cache minor problem, external jar download works just fine except i get the warning security problem [Mixing Signed and Unsigned Code |http://java.sun.com/javase/6/docs/technotes/guides/jweb/mixed_code.html].
All my jars are signed with the same certificate, so i was a bit confused.
Anyway, i follow indications and put the Trusted-Only: true attribut into the manifest of main.jar.
But it leads to this exception:
java.lang.SecurityException: Trusted-Only loader attempted to load sandboxed resource from http://monserveur/a.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 my.package.a$5.run(a.java:348)
     at java.lang.Thread.run(Unknown Source)I found some posts that deal with similar problems but it does not give me a working solution. The difference seems to be the fact that i load external jars (not defined into JNLP).
My JNLP is validated though JaNeLA.
I cannot set a.jar, b.jar as resources into jnlp because i retreive their location during execution...
My JNLP also declare:
<security>
        <all-permissions/>
</security>I think i'm a bit confused with the sandbox notion and the Trusted-Only: true attribut of the manifest. I also tried to add it to a.jar, b.jar and not main.jar but vainly. I also tried to set it on all jars but it does not work better.
Is there a way to load external jar without having the Mixing Signed and Unsigned Code warning popup? What do i not well understand?
Sorry to be so chatty...
Thanks in advanced for any answer.

So, I finally succed in finding a solution.
But this solution seems perhaps a barbarian way to solve my problem but it works.
The idea (as far as i understand) is that when you define "all-permission" into JNLP file, then these permission are granted for JNLP ClassLoader. When you load external jar through DownloadService.loadResource, then another classloader is used. It seems that this classloader does not inherit security policy from JNLP ClassLoader.
My solution is to define my own policy:
Policy.setPolicy(getAllPermissionPolicy());
    * @return a {@link Policy} with all permission granted
   private Policy getAllPermissionPolicy()
      Policy policy = new Policy() {
         private PermissionCollection m_permissionCollection;
         @Override
         public PermissionCollection getPermissions(CodeSource p_codesource)
            return getAllPermissionCollection();
         @Override
         public PermissionCollection getPermissions(ProtectionDomain p_domain)
            return getAllPermissionCollection();
          * @return an AllPermissionCollection
         private PermissionCollection getAllPermissionCollection()
            if (m_permissionCollection == null)
               m_permissionCollection = new AllPermission().newPermissionCollection();
               m_permissionCollection.add(new AllPermission());
            return m_permissionCollection;
      return policy;
   }For sure, you can decline this with permission you need. Here, all permission are allowed.
I'm not quite satisfied because it's seems to be a barbarian style solution. But for now, it fits my uses => no warning popup!
If anybody has a more proper way to deal with such an issue, i'll be glad to hear it!
Hope it helps.

Signed jars + CGLIB = SecurityException

Good Day!
I have the following problem:
My project uses a number of JARs signed with a jarsigner tool from JAVA distribution package including hibernate2.jar (the jar with all the hibernate stuff), spring.jar and cglib.jar (I think, exact names doesn't matter). All this jars are signed off course for security reasons.
Then, I have my project working with Hibernate, and it uses lazy-initialized ORM-classes, so Hibernate tries to generate a proxy via CGLIB for these classes. But during initialization of Hibernate SessionFactoryImpl I'm getting a java.lang.SecurityException:
java.lang.SecurityException: class "cern.spsea.hibernatebeans.BeamFileHibernateBean$$EnhancerByCGLIB$$773cc7e9"'s signer information does not match signer information of other classes in the same package
cern.spsea.hibernatebeans.BeamFileHibernateBean is one of my ORM-classes and all my classes are not signed because they are in development (they are not in jar, so they can not be signed).
I think it happens because signed code (from hibernate.jar and cglib.jar) tries to generate another signed code (cern.spsea.hibernatebeans.BeamFileHibernateBean$$EnhancerByCGLIB$$773cc7e9) but relate it to my unsigned package (cern.spsea.hibernatebeans).
So, I have a couple of questions:
1. Does signed code generates also signed code?
2. If so, what can I do for development? I really need to avoid this problem only at development, because at release my classes will be also in the signed jars. Can I force CGLIB to generate not signed classes? Is it some options in JVM start command to skip security checking? May be something else?
Any help is appreciated!
Thanks a lot in advance!
Roman

In my jboss environment I hit the problem because I had a JWS client download war with signed versions of the jar files.
The fix was to have unsigned versions of the server-side war files (session ejbs with hibernate + pojos inside) FIRST in my application.xml file (jars enter the "classpath" in the order that they are in that file) ahead of the web app .war file for the JWS downloads.

Signed jar works differently than unsigned jar - why?

I'm having a problem with one of my JWS applications (out of six!) -- the application runs fine locally out of the jars. However, when I sign the main jar for running with JWS, it goes into a loop trying to read a property file contained within the main jar. This occurs whether I run it locally or from the JWS server.
The only difference I can see is that the manifest file is affected, but they both have the same reference to the main class and it's also in the jnlp file.
Any thoughts?

I'm having a problem with one of my JWS applications
(out of six!) -- the application runs fine locally out
of the jars. However, when I sign the main jar for
running with JWS, it goes into a loop trying to read a
property file contained within the main jar.If several jars are involved, I would try to have each one signed. And then test again.
This
occurs whether I run it locally or from the JWS
server.Weird.
The only difference I can see is that the manifest
file is affected, but they both have the same
reference to the main class and it's also in the jnlp
file.So far I too believed that the signing just causes additional entry lines in the Manifest file, where for each jar entry some cryptographic hash (md5, sha-1, ..) value will be written.
What happens if you mention the main class as well, in case you test from running from a jar from the command line?
Regards,
Marc

Signing Jars For JWS

Similar Messages

Maybe you are looking for