After update to Java version7 update 51, I purchased the code signing certificate and signed my applet(s). I have main applet (AppletDemo.jar) and another two applets (commons-codec-1.7.jar and FDxSDKPro.jar) which are used by main applet. I signed them all, with DigiCert certificate.
All of them are signed, and verified with jarsigner tool where i get such message:
*s = signature was verified
m = entry is listed in manifest
k = at least one certificate was found in keystore
i = at least one certificate was found in identity scope
jar verified.*
When I try to load the applet I get the following message in the java debug console (the real url is replaced with tag):
basic: Plugin2ClassLoader.addURL parent called for <url>/fpApplet/AppletDemo.jar
basic: Plugin2ClassLoader.addURL parent called for <url>/fpApplet/FDxSDKPro.jar
basic: Plugin2ClassLoader.addURL parent called for <url>/fpApplet/commons-codec-1.7.jar
security: Certificate revocation enabled. Disable security validation optimizations.
security: Validate the certificate chain using CertPath API
security: Trust for: <url>fpApplet/FDxSDKPro.jar has ended: Thu Jan 01 01:00:00 CET 1970
security: Validate the certificate chain using CertPath API
security: Trust for: <url>/fpApplet/commons-codec-1.7.jar has ended: Thu Jan 01 01:00:00 CET 1970
security: Validate the certificate chain using CertPath API
network: Cache entry not found [url: <url>/fpApplet/, version: null]
security: Grant socket perm for <url>/fpApplet/ : java.security.Permissions#199a51e (("java.net.SocketPermission" "<url>" "connect,accept,resolve"))
basic: Your security settings have blocked an untrusted application from running
basic: exception: Your security settings have blocked an untrusted application from running.
com.sun.deploy.security.BlockedException: Your security settings have blocked an untrusted application from running
I assume, that Applet is blocked because of this and two following lines (Trust for: fpApplet/FDxSDKPro.jar has ended: Thu Jan 01 01:00:00 CET 1970).
I do not know how this can happen if jars are signed? Has anyone had such problems?
Bydefault the JAVA security in version 7 is high, so change the security to medium from control panel.follow the link http://www.java.com/en/download/help/jcp_security.xml
We have a Java application that uses RxTx to update the firmware of our game console. To avoid security alerts when the users starts the Java application on our website through WebStart we have bought a trusted certificate and signed the application with that. All checks indicate that it is successfully signed and if I launch the application via Safari on my Mac(OS X 10.6.8) with Java 1.6.0_41 it starts without any complains.
But if I launch it using IE9 on a Windows 8 machine I get an alert saying "Do you want to run this application? This application will run with unrestricted access which may put your computer and personal information at risk. Run this application only if you trust the publisher. This application's digital signature has expired. More Information".
If I click the More Information I get "This application will run with unrestricted access to your personal files and other facilities(webcam, microphone) on your computer.
Although the application has a digital signature, the application's associated file(JNLP) does not have one. A digital signature ensures that a file is from the vendor and that it has not been altered.
The digital signature was generated with a trusted certificate."
I have tried to find a solution how to not get this message and think what I need to do is sign the JNLP file(i.e. copy it into the jar as pointed out here) but what I cannot find is how to get NetBeans to do that! I'm using NetBeans 6.9.1. Anyone know how to do this and if it is enough to sign the JNLP?
To verify that the file was correctly signed I did the following:
jarsigner -verify -certs -verbose OribooDesktopClient.jar
6396 Thu Feb 28 17:14:14 CET 2013 META-INF/MANIFEST.MF
6354 Thu Feb 28 17:14:14 CET 2013 META-INF/MOVINTOF.SF
1843 Thu Feb 28 17:14:14 CET 2013 META-INF/MOVINTOF.RSA
0 Thu Feb 28 17:07:28 CET 2013 META-INF/
0 Thu Feb 28 17:07:26 CET 2013 oribooDesktopClient/
0 Thu Feb 28 17:07:26 CET 2013 oribooDesktopClient/resources/
0 Thu Feb 28 17:07:26 CET 2013 oribooDesktopClient/resources/busyicons/
sm 3912 Thu Feb 28 17:07:26 CET 2013 oribooDesktopClient/BBDatabase.class
X.509, CN=Movinto fun AB, O=Movinto fun AB, STREET=?rev?gen 138, L=?re, ST=J?mtland, OID.2.5.4.17=83013, C=SE
[certificate is valid from 2/28/13 1:00 AM to 3/1/14 12:59 AM]
sm 2497 Thu Feb 28 17:07:26 CET 2013 oribooDesktopClient/Binary.class
X.509, CN=Movinto fun AB, O=Movinto fun AB, STREET=?rev?gen 138, L=?re, ST=J?mtland, OID.2.5.4.17=83013, C=SE
[certificate is valid from 2/28/13 1:00 AM to 3/1/14 12:59 AM]
....
The important part is:
This application's digital signature has expired.
See Appearance of Java Security dialog for details, but you should be expecting something like:
To remove the 'expired' message, the answer is to renew the certificate and sign the jars again. The dialog will still display words to the effect:
This application will run with unrestricted access which may put your computer
and personal information at risk. Run this application only if you trust the
publisher.
The differences will however be:
'Always trust' will default to true.
The yellow diamond with exclamation mark will be changed to something more friendly.
The 'digital signature has expired' message, along with the yellow shield image in the lower left, will be absent.
I'm trying to code sign a JAR file and am using JDK 1.7u1. We acquired a GoDaddy Code Signing certificate and I followed the instructions (Approach 1) here: http://help.godaddy.com/article/4780
The JAR signs fine, however whenever I try to run the command:
jarsigner -verify on my signed JAR using JDK 1.7u1 I get the following output:
s 180 Mon Dec 05 10:24:32 EST 2011 META-INF/MANIFEST.MF
[entry was signed on 12/5/11 10:24 AM]
X.509, CN=Removed Company Name, O=Removed Company Name, L=Removed City, ST=Removed State, C=US
[certificate is valid from 12/2/11 4:30 PM to 12/2/13 4:30 PM]
X.509, SERIALNUMBER=00000000, CN=Go Daddy Secure Certification Authority, OU=http://certificates.godaddy.com/repository, O="GoDaddy.com, Inc.", L=Scottsdale, ST=Arizona, C=US
[certificate is valid from 11/15/06 8:54 PM to 11/15/26 8:54 PM]
X.509, OU=Go Daddy Class 2 Certification Authority, O="The Go Daddy Group, Inc.", C=US
[certificate is valid from 6/29/04 1:06 PM to 6/29/34 1:06 PM]
[CertPath not validated: null]
342 Mon Dec 05 10:24:34 EST 2011 META-INF/JAVACSC.SF
6180 Mon Dec 05 10:24:34 EST 2011 META-INF/JAVACSC.RSA
0 Mon Dec 05 10:24:30 EST 2011 META-INF/
sm 2161 Wed Nov 30 10:23:20 EST 2011 C:/Users/Seth/Desktop/JAR/RunAppSF.class
[entry was signed on 12/5/11 10:24 AM]
X.509, CN=Removed Company Name, O=Removed Company Name, L=Removed City, ST=Removed State, C=US
[certificate is valid from 12/2/11 4:30 PM to 12/2/13 4:30 PM]
X.509, SERIALNUMBER=00000000, CN=Go Daddy Secure Certification Authority, OU=http://certificates.godaddy.com/repository, O="GoDaddy.com, Inc.", L=Scottsdale, ST=Arizona, C=US
[certificate is valid from 11/15/06 8:54 PM to 11/15/26 8:54 PM]
X.509, OU=Go Daddy Class 2 Certification Authority, O="The Go Daddy Group, Inc.", C=US
[certificate is valid from 6/29/04 1:06 PM to 6/29/34 1:06 PM]
[CertPath not validated: null]
s = signature was verified
m = entry is listed in manifest
k = at least one certificate was found in keystore
i = at least one certificate was found in identity scope
jar verified.
Warning:
This jar contains entries whose certificate chain is not validated.
I also tried the jarsigner -verify command using the same JAR as above on JDK 1.6u26 and 1.6u14 and it came back as being fine. (Output below from 1.6u26).
180 Mon Dec 05 10:24:32 EST 2011 META-INF/MANIFEST.MF
342 Mon Dec 05 10:24:34 EST 2011 META-INF/JAVACSC.SF
6180 Mon Dec 05 10:24:34 EST 2011 META-INF/JAVACSC.RSA
0 Mon Dec 05 10:24:30 EST 2011 META-INF/
sm 2161 Wed Nov 30 10:23:20 EST 2011 C:/Users/Seth/Desktop/JAR/RunAppSF.class
[entry was signed on 12/5/11 10:24 AM]
X.509, CN=Removed Company Name, O=Removed Company Name, L=Removed City, ST=Removed State, C=US
[certificate is valid from 12/2/11 4:30 PM to 12/2/13 4:30 PM]
X.509, SERIALNUMBER=00000000, CN=Go Daddy Secure Certification Authority, OU=http://certificates.godaddy.com/repository, O="GoDaddy.com, Inc.", L=Scottsdale, ST=Arizona, C=US
[certificate is valid from 11/15/06 8:54 PM to 11/15/26 8:54 PM]
[KeyUsage extension does not support code signing]
X.509, OU=Go Daddy Class 2 Certification Authority, O="The Go Daddy Group, Inc.", C=US
[certificate is valid from 6/29/04 1:06 PM to 6/29/34 1:06 PM]
s = signature was verified
m = entry is listed in manifest
k = at least one certificate was found in keystore
i = at least one certificate was found in identity scope
jar verified.
Am I missing an extra step I need to take to get the JAR signed properly for JDK 1.7?
I have been having the same issue and if it can help others the problem is in how jarsigner finds the keystore.
In order to fix the issue do:
jarsigner -verify -keystore xxxx.jks mysignedjar.jar
You are not missing anything and you are definitely not alone with this problem. After a struggle of almost 12 hours, I figured out that the root of the problem lies in mixing binaries from JDK 1.7 with an older version of Java such as JRE-1.6. To be more precise, keytool comes with JRE, while JDK ships with both keytool and jarsigner.
So, to resolve the issue, I have completely uninstalled JDK-1.7 from my system and installed JDK-1.6 Update 30. Now, if I would do jarsigner -verify -verbose -certs blah.jar it would produce jar verified without any warning which I believe is what you expect.
It's just a warning you can ignore.
If you really don't want to ignore it then tell jarsigner where your keystore is when you verify.
jarsigner -verbose -verify -keystore ${KEYSTORE_PATH} ${YOUR_JAR_FILE}
This is just a new feature in JDK 7.
I had similar problem with the "DigiCert SHA2 Assured ID Code Signing CA". All oracle java versions as well as OpenJDK behaved the same. Digicert support redirected me to this page, but nothing stated here had helped me with the verification process neither.
I am trying to sign an applet, so I need it to be verifiable also in the browser, so the trick with providing the keystore path to jarsigner -verify is not applicable.
Main problem seems to be a bug in keytool when operating with certs using SHA2 instead of SHA1, because the same list of steps applied on SHA1 certs always works and never worked for SHA2 for me. It appears to me, that keytool is not capable of detecting the "chainability" of certificates imported to jks and thus jarsigner does not embed proper certs chain into the signed jar, there is only the final certificate stored in the META-INF/myalias.RSA file instead (verifiable by openssl pkcs7 -in myalias.RSA -print_certs -inform DER -out certs.crt).
Digicert suggested "...we sometimes see issues with the Root not actually being imported correctly or fully the first time, but running an import command that points to the Root again can fix this", even this did not help in my case.
As there is no way to say explicitly to keytool what certs are about to be in a chain, I've decided to build a chain using openssl and import it like this:
cat TrustedRoot.pem DigiCertCA2.pem my.crt >chain
openssl pkcs12 -nodes -export -in my.crt -inkey my.key -out tmp.p12 -name myalias -certfile chain
keytool -importkeystore -destkeystore mykeystore.jks -srckeystore tmp.p12 -srcstoretype PKCS12
After this mykeystore.jks appears to contains only my certificate, not DigiCertCA2 or the Root when listed by keytool -list command, but with -v (verbose) it discloses chain depth and its certs:
~/$ keytool --list --keystore mykeystore.jks -v|grep -e chain -e Certificate\\[
Enter keystore password: 123456
Certificate chain length: 3
Certificate[1]:
Certificate[2]:
Certificate[3]:
And this is what jarsigned needs to sign the jar properly, i.e. to embed proper certs chain and make jar verifiable also for final browser user.
I found that the message "This jar contains entries whose certificate chain is not validated" is also printed if you sign the Jar file using JRE 1.7.0_21 and verify it with a lower version of JRE 1.7.0.
Conclusion: no need to downgrade to Java 1.6, simply use the same jarsigner version for both signing and verification.
This is a security mechanism in JDK 7+. This prints the warning when signing jars without a timestamp, which can be passed with a -tsa flag. If a jar has no timestamp, it will stop working past its validity date.
If you are building an Android target, this warning will always print if you are using a JDK newer than 1.7.0_51. Android generally recommends passing 30 years validity, so this warning can be 100% ignored unless you business plan is to allow users to use the same .apk in 2046.
Here is the ticket for the feature, the purpose is to encourage timestamping, which I believe will be effective. http://bugs.java.com/view_bug.do?bug_id=8023338.
If your certificates are from Entrust, make sure you are using the newer root certificate.
http://www.entrust.net/knowledge-base/technote.cfm?tn=7875
Problem:
You receive an error message that states your SLL certificate
validation has failed due to a missing Basic Constraints field.
Solution:
In 2009, Entrust re-released the 2048-bit root certificate to include
the Basic Constraints field (cn=Entrust.net Certification Authority
(2048), valid to 7/24/2029). Entrust has stopped pushing out the
original 2048-bit root through root updates in Windows and Java
(starting from version 1.6 update 22). The updated root certificate
containing Basic Constraints can be found here:
https://www.entrust.net/downloads/binary/entrust_2048_ca.cer
When you create/export your certificate to a p12 (used by the jarsigner) make sure you ensure the following is selected (for example if you export using Internet explorer wizard) you will need to select the following in the export wizard.
"Export the private key”
“Include all certificates in the certification path if possible”
“Export all extended properties” checked under the option .PFX or PKCS #12.
If you create the p12 properly in the first place then jarsign requires no special effort.
I am having trouble with getting and applet to work on an HTML page. When I remove the socket connection from the applet class and test the applet on an HTML page the applet displays but when I add the socket connection back in the class file the applet doesn't display and the Java console appears with no stack trace. I'm sure this is a security reason because I'm using socket connections so what I did was create a signed jar file and placed that in the applet tag as so:
<APPLET codebase="classes" archive="captureaudio/AppletTest.jar" code="captureaudio/AppletTest.class" width=350 height=200></APPLET>
But creating this signature has not worked.
Can somebody help me with this?
UPDATED
In response to Andrew Thompson
No im not prompted to accept digital signed code
No the applet im currently testing is locally
Yes the applet is trying to connect back to the server, ther server is running locally
Im not sure the java console isnt showing me any exceptions.
HOW I CREATED THE SIGNED JAR FILE
The namespace of my Applet is captureaudio.AppletTest class
At cmd prompt, where teh class file is located:
You need to use the keytool.exe here is where i found how to create a jar signature for applets www.xinotes.org/notes/note/434/
jar -cf AppletTest.jar AppletTest.class
>jarsigner AppletTest.jar MyCert Warning: This jar contains entries whose signer certificate will expire within six months
4.>jarsigner -verify -verbose -certs AppletTest.jar
s k 153 Thu Oct 13 11:28:38 BST 2011 META-INF/MANIFEST.MF
X.509, CN=xxxxx, OU=None, O=None, L=xxxxx, ST=xxxxx, C=GB (myce
rt)
[certificate will expire on 10/01/12 20:55]
315 Thu Oct 13 11:28:40 BST 2011 META-INF/MYCERT.SF
1352 Thu Oct 13 11:28:40 BST 2011 META-INF/MYCERT.RSA
0 Thu Oct 13 11:28:10 BST 2011 META-INF/
smk 11015 Thu Oct 13 10:49:08 BST 2011 AppletTest.class
X.509, CN=xxxxxx, OU=None, O=None, L=xxxxxxxx, ST=xxxxx, C=GB (myce
rt)
[certificate will expire on 10/01/12 20:55]
s = signature was verified
m = entry is listed in manifest
k = at least one certificate was found in keystore
i = at least one certificate was found in identity scope
jar verified.
JAVA CONSOLE
Java Plug-in 10.0.0.147
Using JRE version 1.7.0-b147 Java HotSpot(TM) Client VM
User home directory = C:\Users\xxxxxxx
c: clear console window
f: finalize objects on finalization queue
g: garbage collect
h: display this help message
l: dump classloader list
m: print memory usage
o: trigger logging
q: hide console
r: reload policy configuration
s: dump system and deployment properties
t: dump thread list
v: dump thread stack
x: clear classloader cache
0-5: set trace level to
Detected from bootclasspath: C:\PROGRA~1\Java\jre7\lib\deploy.jar
UPDATE
Folder locations
web root>
------AppletTest.jar
------classes>
-----------captureaudio>
---------------------AppletTest.class
Use the Java Network Launching Protocol (JNLP). That is the right way to distribute you applet. And yes, it must be signed, to access the socket functionality.
http://en.wikipedia.org/wiki/Java_Web_Start#Java_Network_Launching_Protocol_.28JNLP.29
http://www.oracle.com/technetwork/articles/javase/jnlp-142088.html
I was trying to sign a jar applet archive with our company .pfx certificate using this guide
(and few others from the internet):
http://www.globalsign.com/support/ordering-guides/SignJavaCodeAppletsPFX.pdf
Everything seems to be fine, but when I try t run apple through the browser I see that
'Publisher' is UNKNOWN (untrusted). And when I go to details I'm able to see proper company
name and certificate vendor (GlobalSign). Why it's not properly displayed as known/trusted?
The one thing which looks suspicious to me is output of command
jarsigner -verify -verbose -certs Applet.jar:
(...)
sm 1936 Wed Apr 13 03:00:50 CEST 2011 org/my/Applet.class
X.509, CN=CompanyName, O=CompanyName, L=Tilst, ST=ProperState, C=DK
[certificate is valid from 18.02.10 14:58 to 18.02.13 14:58]
s = signature was verified
m = entry is listed in manifest
k = at least one certificate was found in keystore
i = at least one certificate was found in identity scope
So looks like 'k = at least one certificate was found in keystore' is missing
(should be smk and it is sm). Is it signed only partially? Or what?
Is it possible that .pfx file given to me by GlobalSign is somehow wrong
on not enough to sign applets? For normal executables it was working just fine...
Any ideas? ;)
EDIT
#Jcs
Looks like you are totally right. I checked my PFX file with keytool and I get:
Your keystore contains 1 entry
Alias name: company_alias
Creation date: Apr 13, 2011
Entry type: PrivateKeyEntry
Certificate chain length: 1
Certificate[1]:
So looks like chain is not complete.
I'm not sure if it matters, but there are also few extensions like for example:
#1: ObjectId: (some_numbers_here) Criticality=true
KeyUsage [
DigitalSignature
]
#2: ObjectId: (some_numbers_here) Criticality=false
AuthorityInfoAccess [
[
accessMethod: (some_numbers_here)
accessLocation: URIName: http://secure.globalsign.net/cacert/ObjectSign.crt]
]
(...)
Question is: is my PFX file totally wrong, or somehow I need to add globalsign root to it?
According to your post, it seems that there is only one certificate in the signature certificate chain. I verified an applet I signed (this applet works correctly in a browser)
(...)
sm 2419 Thu Mar 31 15:49:14 CEST 2011 org/xml/sax/helpers/XMLReaderFactory.class
X.509, CN=Company Name, O=Company Name, L=Paris, ST=Ile de France, C=FR
[certificate is valid from 8/4/10 2:00 AM to 8/4/12 1:59 AM]
X.509, CN=Thawte Code Signing CA - G2, O="Thawte, Inc.", C=US
[certificate is valid from 2/8/10 1:00 AM to 2/8/20 12:59 AM]
[KeyUsage extension does not support code signing]
(...)
We can see that there is 2 certificates in the chain since my signing certificate has been issued by the Thawte Code Signing CA.
In your case if there is only one certificate in the jarsigner output it may indicates that the intermediate CA is missing and I hardly doubt that GlobalSign is directly issuing certificates from the root CA (which is in the java trust store). Therefore when the applet is loaded and the signatures are verified the JVM is not able to rebuild a certificate chain between the signing certificate and the GlobalSign root CA, explaining the current behaviour.
Maybe the PKF file does not contains that intermediate CA. With OpenSSL you can check how many certificates are present:
[jcs#home:~/]$ openssl pkcs12 -in myfile.pfx
or with keytool
[jcs#home:~/]$ keytool -list -v -storetype pkcs12 -keystore myfile.pfx
Enter keystore password:
Keystore type: PKCS12
Keystore provider: SunJSSE
Your keystore contains 1 entry
Alias name: 2
Creation date: Aug 4, 2010
Entry type: PrivateKeyEntry
Certificate chain length: 2 <-- the chain length is here.
Certificate[1]:
(...)
Thanks a lot for all, especially Jcs :)
I finally discovered that .pfx file was just imported improperly.
I asked my boss to import it for me from scratch with all possible paths/chains/certificates included and now it works :)
So if anyone will have similar problem my advice is to try to get/import certificate again
- it's rather problem with certificate itself than with signing method.