Signing JARs & Ant issues
I need to sign my JARs because of WebStart. I use Ant's signjar to do that and works fine: my JARs are signed.
The build process goes like this: compile, pack, sign & deploy. However, when I run my build file again, even if nothing was updated, Ant packs all my JARs again. Which in turn loses the signing, so they all are signed again.
Is there a way to avoid this?
Also, my library JARs are all signed everytime. I added the attribute lazy="true" to signjar that doesn't seem to work.
N.
Yes It has to do with swing.
I used the following command in ant.
<target name="signjar" depends="cpappletjars">
<signjar jar="${dir.webapp}/fileupload/*.jar" alias="me" storepass="applet" keystore="${dir.webapp}/fileupload/myKeyStore"/>
<delete file="${dir.webapp}/fileupload/myKeyStore"/>
</target>
It worked fine for windows but for linux it gives error as "unble to open file *.jar "
Can u please let me know where I am gone wrong ?
similar sort of problem seen at http://forum.java.sun.com/thread.jspa?threadID=5301675&messageID=10278840 But no solution.
Similar Messages
-
Hello,
I want to sign jars using the ant 1.7. I am using the
<signjar alias="E:\buildforcertify\filefolderupload.jar" keystore="myKeyStore.keystore" storepass="day" verbose="true"/>
but it it doesnot work.
Please help me in signing jars using ant. If u can provide an link, it would be of great help.
TIA,
SarwaYes It has to do with swing.
I used the following command in ant.
<target name="signjar" depends="cpappletjars">
<signjar jar="${dir.webapp}/fileupload/*.jar" alias="me" storepass="applet" keystore="${dir.webapp}/fileupload/myKeyStore"/>
<delete file="${dir.webapp}/fileupload/myKeyStore"/>
</target>
It worked fine for windows but for linux it gives error as "unble to open file *.jar "
Can u please let me know where I am gone wrong ?
similar sort of problem seen at http://forum.java.sun.com/thread.jspa?threadID=5301675&messageID=10278840 But no solution. -
Peculiar issue with signed .jars and Linux (Debian unstable, 2.4.20-custom)
BACKGROUND:
I am a developer working on a Java3D application, which is to be deliverable over
the Web. Delivery as an applet seemed a natural choice, and so I spent a considerable amount of effort learning (I won't say "mastering") the process of
creating a self-signed .jar containing java3d-<some_version>.exe. I have in fact
successfully created a fully-fuctional from-scratch JPI/Java3D/myapp install. By
this I mean that Windows machine with only stock IE installed could hit my URL,
get the proper JPI installed, followed by the Java3D runtime I'd chosen, as well
as a third-party DXF loader, and finally (after much clicking of 'Yes', 'Accept',
'OK', etc.) see my app in a browser window.
That was on my old, slow, Windows2000 workstation. Now I have a shiny, new
workstation upon which my employer has graciously allowed me to run Linux. Sadly,
the re-creation of the self-signed .jar files under a new JDK has not gone smoothly.
PROBLEM DESCRIPTION:
When a user attempts to download the self-signed .jar containing the auto-install
executable for the Java3D runtime, the normal security warning prompts are displayed (one for granting to install the extension, one to accept the "suspect" certificate from me alone). The plugin happily downloads the .jar file, and then
a NullPointerException is thrown, with a
stack trace like:
NPE!
at java.util.zip.ZipFile.getInputStream (unknown source)
at java.util.jar.JarFile.getInputStream (unknown source)
<something>doPrivileged<something>
etc.
I apologize for the lack of a full stack trace; I would essentially have to type it in by hand after printing it out on the remote test box; I hope that I've caught the important details above.
After this, the pure-java signed .jar is downloaded and installed, and then the applet "loads" with the predictable ClassNotFoundException for javax.media.j3d.SceneGroup.
Downloading and installing the J3D runtime by hand and then re-visiting the URL results in a fully-functional applet.
I've tried Blackdown Linux JDKs 1.4 and 1.3.1, as well as Sun's JDKs 1.3.1_07 and 1.3.1_05 for the compiling, jar'ing, and jarsigner'ing of these files, all with the same result. At each new JDK, I re-did the HTML conversion so that he appropriate
JPI version was required on the client. I did complete uninstallations of all client JPI instances (including Web Start for 1.4.1_x, as well as cleaning the registry on the client).
When this strategy worked, it was on Sun JDK 1.3.1_05 for Windows runnning on Windows2000, unknown service pack.
DESIRED BEHAVIOR:
I would like my clients to be able to go from stock Windows2K/IE (this being an intranet without any other options) to some JPI version running the J3D extension, with only the need to click 'OK', 'Accept', 'Grant This Session', etc. a bunch of times on the part of the user. I want this to happen without my having to resurrect my decrepit old Compaq Deskpro just to play the role of "build host" for my
Java3D and loader .jar files, if at all possible.
FILES:
Here's what gets merged into the "main" applet's mainfest at creation time:
Manifest-Version: 1.0
Extension-List: java3d DxfLoader
java3d-Extension-Name: javax.media.j3d
java3d-Implementation-Vendor-Id: com.sun
java3d-Implementation-Version: 1.3
java3d-Specification-Title: Java 3D API Specification
java3d-Specification-Version: 1.3
java3d-Specification-Vendor: Sun Microsystems, Inc
java3d-Implementation-URL: http://10.1.1.1/heartcad/lib/java3d.jar
DxfLoader-Extension-Name: eupla.dxfloader
DxfLoader-Implementation-Title: Eupla DXFLoader
DXFLoader-Implementation-URL: http://10.1.1.1/heartcad/lib/DxfLoader.jar
And into the manifest for the J3D .jar:
Manifest-Version: 1.0
Implementation-Version: 1.3
Specification-Version: 1.3
Extension-Installation: "java3d-1_3-windows-i586-directx-rt.exe"
Extension-Name: javax.media.j3d
Implementation-Vendor-Id: com.sun
Implementation-Vendor: Sun Microsystems, Inc
Specification-Vendor: Sun Microsystems, IncI have seen that bug, and the problem I'm having seems to be different than it. The extension installer is in the first extension .jar my applet asks for, and it
never works automatically, regardless of how many times the applet is loaded.
The second .jar, which doesn't have to run any installer, always works fine, but the first one will never work (a manual install of the Java3D runtime is required). This seems to not be the behavior described in the bug.
I will continue to search for an answer to this problem, and of course if I should find anything I'll post it here. -
HI,
i am not able to avoid the applet warning message.Though we created the sign-jar.
Regards
Muthukumari am not able to avoid the applet warning message.Though we created the sign-jar.
Correct. One cannot and should no be able to turn off the applet warning message. Applets are applications running on your computer and could be malicious. Signing the jar does not guarantee they are not malicious since anyone can obtain a certificate signed by one of the major CAs. All a CA certifies is that the owner of the certificate is who they say they are and not that they are trustworthy. If he had been alive today, Al Capone could have obtained a legitimate signed certificate under his own name but would you trust an application created by Al Capone? -
I am having a problem with signed jar and deploy in html
get this error on the page
self signed
/dist/testfx.html
JavaFX application could not launch due to system configuration. See java.com/javafx for troubleshooting information.Unsigned jar works perfectly but has security and permission issues when using classes.
This was working in beta 45Can you post an example project that demonstrates the problem? There were changes to the ant tasks and netbeans support around B45 that could cause problems depending on which version of the SDK and NetBeans you have. Similarly, if you wrote ant scripts prior to B44 and then use them with a later build you could have problems. And of course, if you're producing the Jar file and deployment artifacts without using the provided ant tasks (for example, using the normal ant jar task) you'll have problems.
I've verified that this works as expected in the FX 2.0 GA release using ant from the command line, and with the NetBeans 7.1 beta release using the FX 2.0 GA release. -
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 NagelHello 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 -
JNLP: Signed jars but still not trusted
I have an applet that has signed jars that were signed by the same key, the applet shows the correct warnings on startup and works fine (allows access to the local file system, etc), however there still exists the 'yellow triangle warning' on one of two popups frames that the applet produces (but not the other one).
The applet does use native code (packaged in a signed jar and referenced in the JNLP). The jars are all signed by the same certificate from a CA. I originally didn't have the JNLP signed (by placing it in the main jar in JNLP-INF/APPLICATION.JNLP) but this didn't help. Also I didn't have the JNLP codebase set to a real URL (and really cant in production because its a solution we deploy to customers servers - its packaged software not hosted) but even after I tested with a codebase to a test server, it still didnt remove the famed yellow triangle. I have all-permissions set in the JNLP.
So two related questions:
1) Other than having not having signed jars (or not signed correctly), what other reasons cause the 'yellow triangle'?
2) The warning only appears on one of the popup Frames. What could be the possible reasons for that? Are there some privileges that show the icon whether the applet is signed or not?
Note: While changing the client policy setting (showWindowWithoutWarningBanner) works, this cant be a solution.
From the Java Console:
...It goes through all the jars (I only included one for brevity - there are 23 of them). Note it says 'have 1 common certificates'.. which I think indicates everything is signed by the same cert.
Is there any indication in the console logs I can use to determine why it is not trusted? It looks (to me) that everything is OK, until it says 'istrusted=false'.
security: Validating cached jar url=http://10.192.252.26/QMDesktop/native.jar ffile=C:\Documents and Settings\bunkowm\Application Data\Sun\Java\Deployment\cache\6.0\34\1df0b62-2c3ce377 com.sun.deploy.cache.CachedJarFile@d964af
cache: Reading Signers from 995 http://10.192.252.26/QMDesktop/native.jar | C:\Documents and Settings\bunkowm\Application Data\Sun\Java\Deployment\cache\6.0\34\1df0b62-2c3ce377.idx
security: Have 1 common certificates after processing http://10.192.252.26/QMDesktop/native.jar
security: Istrusted: null false
security: Loading certificates from Deployment session certificate store
security: Loaded certificates from Deployment session certificate store
security: Validate the certificate chain using CertPath API
security: Obtain certificate collection in Root CA certificate store
security: Obtain certificate collection in Root CA certificate store
security: Start to check whether root CA is replaced
security: The root CA hasnt been replaced
security: No timestamping info available
security: Found jurisdiction list file
security: No need to checking trusted extension for this certificate
security: The CRL support is disabled
security: The OCSP support is disabled
security: This OCSP End Entity validation is disabled
security: Checking if certificate is in Deployment denied certificate store
security: Checking if certificate is in Deployment permanent certificate store
security: Checking if certificate is in Deployment session certificate store
security: Mark trusted: nullAndrew - of course you were correct about the signed cert - I misspoke when the CA signed applet didn't show a warning. (You were also right that I must have checked 'always accept' the certificate on the server I had the CA signed cert on).
I think you guys are on to something about the privileged actions. It would explain where one popup has the icon and the other doesn't. We have Javascript making calls into the applet and we do use JNI (although I don't think there are any calls back). We do wrap these calls in privileged actions but maybe we missed something. What I've seen before is a security exception is thrown if we don't wrap them - but maybe there are areas where we don't and it doesn't throw an exception or it does and we eat it somehow (and for whatever reason doesn't cause anything noticeable).
Now that I know it could likely be the applet code and not necessarily a build issue with signing the jars, I have another place to look...
I'll check it out and let you know what I find. -
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!
RichHi,
yes, the pkcs12 certificate includes the private key, as opposed to pb7 which does not.
Sent from Cisco Technical Support Android App -
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 AMOh, 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. -
Hi folks,
I do have long used PGP keys (over 7 years). I would like
to sign jar file using those my PGP key. How should I do that?
I mean I can just sign jar in standard PGP way, but I would like
to sign jar file in way jarsigner does. Such that in jar meta
one would see PGP signature and could verify it using jarsigner
or other software of that kind. How it's possible?
Please help. Bunch of dukes are awaiting you! Urgent!
PaulSure it knows nothing about PGP. You have to use PGP
tools to export that key to one of the formats those
can be understanded by keytool (such as x509 or
pkcs12). I do know nothing about these PGP tools to export PGP keys
to x509 and/or pkcs12 - please hint me what tools you
are talking about?The universal hint is: Google -> "PGP key export" -> Search
Another possibility is to export RSA key to the DER
encoding and then write a little program to read it
and then add to the keystore. This is looks like an
easy task. I believe you can easily find source to
convert pkcs12 keystore to JKS and use that one as a
starting point.I would be happy if you will point me the source to convert
pkcs12 keystore into JKS. BTW what's JKS?Google -> "convert pkcs12 to JKS" -> Search
JKS == Java Key Store
Sorry for my stupidity... I've last touched PGP/RSA issues
5 or 6 years ago, since that time technology a bit changed :)It is a good idea to read some fundamental first. Take a look at http://java.sun.com/products/jce/index-14.html -
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 AMHi 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();
} -
Problem occuring when extending classes coming from 2 signed JAR
Hi everyone,
I have 2 signed jar called "base_signed.jar" and "extended_signed.jar" using keytool with a testing certificate generated at runtime. All goes well because with both signed JARs I can use the URLClassLoader without any java.security.AccessControlException exception.
But the first JAR contains abstract class B, the latter JAR contains a concrete class A.
The problem occurs when I try to instantiate some class A coming from "extended_signed.jar" using Class.forName("blablaclassA").newInstance() and occurs only if this class A extends some other abstract class B contained inside "base_signed.jar" .
Pratically if the class A is casted as its common JVM ancestor of B (JInternalFrame) all goes well, otherwise if I try to cast A using its direct ancestor B, I receive the following exception:
network: Connessione a http://www.orion.lan/~antares/it/weev/wipidea/plugins/MeteoradarArpavPlugin$7.class con proxy=DIRECT
Exception in thread "AWT-EventQueue-35" java.lang.ClassCastException: it.weev.wipidea.plugins.MeteoradarArpavPlugin cannot be cast to it.weev.wipidea.base.AWipideaPlugin
at it.weev.wipidea.base.PluginLoader.loadNetworkPlugin(Unknown Source)
at it.weev.wipidea.applet.WipideaApplet.loadPlugin(Unknown Source)
at it.weev.wipidea.applet.WipideaApplet$1.actionPerformed(Unknown Source)
at javax.swing.AbstractButton.fireActionPerformed(Unknown Source)
at javax.swing.AbstractButton$Handler.actionPerformed(Unknown Source)
at javax.swing.DefaultButtonModel.fireActionPerformed(Unknown Source)
at javax.swing.DefaultButtonModel.setPressed(Unknown Source)
at javax.swing.plaf.basic.BasicButtonListener.mouseReleased(Unknown Source)
at java.awt.Component.processMouseEvent(Unknown Source)
at javax.swing.JComponent.processMouseEvent(Unknown Source)
at java.awt.Component.processEvent(Unknown Source)
at java.awt.Container.processEvent(Unknown Source)
at java.awt.Component.dispatchEventImpl(Unknown Source)
at java.awt.Container.dispatchEventImpl(Unknown Source)
at java.awt.Component.dispatchEvent(Unknown Source)
at java.awt.LightweightDispatcher.retargetMouseEvent(Unknown Source)
at java.awt.LightweightDispatcher.processMouseEvent(Unknown Source)
at java.awt.LightweightDispatcher.dispatchEvent(Unknown Source)
at java.awt.Container.dispatchEventImpl(Unknown Source)
at java.awt.Component.dispatchEvent(Unknown Source)
at java.awt.EventQueue.dispatchEvent(Unknown Source)
at java.awt.EventDispatchThread.pumpOneEventForFilters(Unknown Source)
at java.awt.EventDispatchThread.pumpEventsForFilter(Unknown Source)
at java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown Source)
at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
at java.awt.EventDispatchThread.run(Unknown Source)
network: Voce cache non trovata [url: http://www.orion.lan/~antares/it/weev/wipidea/base/PluginLoader.class, versione: null]
network: Connessione a http://www.orion.lan/~antares/it/weev/wipidea/base/PluginLoader.class con proxy=DIRECT
network: Voce cache non trovata [url: http://www.orion.lan/~antares/it/weev/wipidea/base/network-classpath.class, versione: null]
---The strange thing is that if I don't sign both JARs the class A is casted on B without any exception, could for security reason like hash or other? Ideally I need all JAR signed only because I plan to load classes from all over the net, but seems that URLClassLoader throws an AccessControlException when called.
Anyway just now I solve all using only the common JVM ancestor of A and B, but what could be the final solution?
Thanks, bye.Hi Sean,
The file in question has been signed which causes issues in both OSB directly and in Eclipse when we do an import into that tool first.Can you let us know what issues you faced? Any errors? If yes, please post the same here.
Regards,
Anuj
Edited by: Anuj Dwivedi on Feb 23, 2011 9:10 PM -
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 -
I can not access my itune/cloud music & apps! My pc crashed & I'm signed on as a temp. user; I can't sign-on ant other way! I lost my icon also.
Re: That garbage is unreadable.
If you really want help, stop messing with the fonts and post so that others can read and offer suggestions.
Or better yet... try a search, I'm certain you'll find a solution to whatever issue you're experiencing.
I have found that many times it is the things that make you most angry that push you to action. This was the case here. Thank you for causing me to get so angry that I found the answer myself.
Maybe you are looking for
-
How to install 2 instances of minisap on the same computer
Hello, is that possible to install 2 instances of minisap on windows? (so that to make RFC tests from system to system, but I could try some other features, like system landscape, etc.) In particular, I have an old minisap 6.20 installed, and I want
-
Logic Pro 9.1.8 + Mountain Lion 10.8.2 - Frequently crashes when using plug-ins
I'm really hoping someone can help. I suspect this problem is new since I can't find a definitive answer. When using the third party plug-in Superior Drummer 2, Logic Pro 9.1.8 frequently crashes giving problem report 'Logic Pro quit unexpectedly whi
-
ISync 2.2 and Mac OS X 10.4.6 Update released: READ THIS before installing
Apple has released iSync 2.2 as part of the Mac OS X 10.4.6 Update package, and it has serious ramifications for current or first-time users of iSync. READ this information below before you perform the installation. This information is extracted from
-
In IPHOTO5 ..It look that i can not sort my photo by films roll and in the same time have my pictures in these films roll sort by following growing numbers (keywords) I do not know why but if i choose to to sort my photo by growing numbers (ex: 1234-
-
Itunes still does not fit on my screen. How can I make this happen?
Itunes does not fit my screen so I cannot even see the scroll bar. Can I fix this?