Develop Reference

jarsigner reporting different certificate expiration

I have a certificate from Comodo that I use to sign my builds: DLLs for native code, .NET DLLs, and a JAR file for Java.
I obtained the certificate on Sep 30, 2021 and it's good until Sep 30, 2024 :
$ openssl pkcs12 -in ./My_Code_Signing_CertAndPrivateKey.pkcs12.pfx -passin pass:"********" -clcerts -nokeys | openssl x509 -noout -enddate
notAfter=Sep 30 23:59:59 2024 GMT
I followed these instructions to generate a Java KeyStore (JKS) certificate and confirmed its expiration is Sep 2024:
keytool -list -v -keystore My_Code_Signing_CertAndPrivateKey_JavaKeyStore.jks -storepass "*****" | grep until
Valid from: Thu Sep 30 20:00:00 EDT 2021 until: Mon Sep 30 19:59:59 EDT 2024
Valid from: Sun Mar 21 20:00:00 EDT 2021 until: Fri Mar 21 19:59:59 EDT 2036
Valid from: Mon May 24 20:00:00 EDT 2021 until: Sun Dec 31 18:59:59 EST 2028
Valid from: Wed Dec 31 19:00:00 EST 2003 until: Sun Dec 31 18:59:59 EST 2028
Valid from: Sun Jan 21 19:00:00 EST 2018 until: Sat Jan 22 18:59:59 EST 2022
Valid from: Wed May 08 20:00:00 EDT 2013 until: Mon May 08 19:59:59 EDT 2028
Valid from: Mon Jan 18 19:00:00 EST 2010 until: Mon Jan 18 18:59:59 EST 2038
Warning:
<le-7a277b0a-1b66-4d55-8b15-11d2734d9e16> uses the SHA1withRSA signature algorithm which is considered a security risk. This algorithm will be disabled in a future update.
The JKS keystore uses a proprietary format. It is recommended to migrate to PKCS12 which is an industry standard format using "keytool -importkeystore -srckeystore Nucleuz_Code_Signing_CertAndPrivateKey_JavaKeyStore.jks -destkeystore Nucleuz_Code_Signing_CertAndPrivateKey_JavaKeyStore.jks -deststoretype pkcs12".
But when I use the JKS certificate to sign my JAR file it reports the signer certificate is already expired (Jan 22, 2022):
$ jarsigner -keypass CodeSignPwd -keystore ./My_Code_Signing_CertAndPrivateKey_JavaKeyStore.jks -storepass "*****" -tsa http://timestamp.comodoca.com/rfc3161 -digestalg SHA-256 myjar.jar "***** comodo ca limited id"
jar signed.
Warning:
The signer certificate has expired.
The signer certificate expired on 2022-01-22. However, the JAR will be valid until the timestamp expires on 2033-08-10.
jarsigner also reports the JAR signature is already expired (Jan 22, 2022):
$ jarsigner -verify -verbose -certs myjar.jar
[entry was signed on 2/14/23 4:20 PM]
>>> Signer
X.509, CN=*****, O=*****, OID.2.5.4.18=*****, STREET=*****, ST=**, OID.2.5.4.17=*****, C=US
[certificate expired on 1/22/22 6:59 PM]
X.509, CN=COMODO RSA Code Signing CA, O=COMODO CA Limited, L=Salford, ST=Greater Manchester, C=GB
[certificate is valid from 5/8/13 8:00 PM to 5/8/28 7:59 PM]
X.509, CN=COMODO RSA Certification Authority, O=COMODO CA Limited, L=Salford, ST=Greater Manchester, C=GB
[trusted certificate]
>>> TSA
X.509, CN="Sectigo RSA Time Stamping Signer #3", O=Sectigo Limited, ST=Manchester, C=GB
[certificate is valid from 5/10/22 8:00 PM to 8/10/33 7:59 PM]
X.509, CN=Sectigo RSA Time Stamping CA, O=Sectigo Limited, L=Salford, ST=Greater Manchester, C=GB
[certificate is valid from 5/1/19 8:00 PM to 1/18/38 6:59 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
- Signed by "CN=*****, O=*****, OID.2.5.4.18=*****, STREET=*****, L=*****, ST=**, OID.2.5.4.17=*****, C=US"
Digest algorithm: SHA-256
Signature algorithm: SHA256withRSA, 2048-bit key
Timestamped by "CN="Sectigo RSA Time Stamping Signer #3", O=Sectigo Limited, ST=Manchester, C=GB" on Tue Feb 14 21:20:26 UTC 2023
Timestamp digest algorithm: SHA-256
Timestamp signature algorithm: SHA384withRSA, 4096-bit key
jar verified.
Warning:
This jar contains entries whose signer certificate has expired.
The signer certificate expired on 2022-01-22. However, the JAR will be valid until the timestamp expires on 2033-08-10.
My native-code DLLs and the .NET DLLs have the proper expiration: Sep 30, 2024.
Any suggestions?

java web start jnlp Application is Blocked by Java Security on apache https web server

I have a JNLP/Web Start application on a secure apache http server (no Tomcat - do I need it?). It has been signed with the free keystore I generated by java. When I launch it, I get the following error:
For security, applications must now meet the requirements for the High
or Very High security settings, or be part of the Exception Site List,
to be allowed to run.
I have added the location to the Exception Site List (with a trailing slash to include all subdirectories and files) but I continue to get this error.
Of course it won't work in Chrome. I have tried launching the jnlp file from the command line, the URL from Firefox and Internet Explorer and they all give me the same error.
I have obtained a certificate and signed my jar file. I have run jarsigner -verify on the jar file and everything looks in order (but I am not sure what I am looking for):
jarsigner -verify -verbose -keystore garageMonitor.jks ../GarageMonitorFinder.jar
s k 1561 Fri Oct 09 18:19:48 UTC 2015 META-INF/MANIFEST.MF
1425 Fri Oct 09 18:19:50 UTC 2015 META-INF/8D95B904.SF
8149 Fri Oct 09 18:19:50 UTC 2015 META-INF/8D95B904.RSA
0 Fri Oct 09 14:13:14 UTC 2015 META-INF/
0 Fri Oct 09 14:13:14 UTC 2015 com/
0 Fri Oct 09 14:13:14 UTC 2015 com/thompco/
0 Fri Oct 09 14:13:14 UTC 2015 com/thompco/garagemonitor/
smk 107 Fri Oct 09 14:13:12 UTC 2015 META-INF/INDEX.LIST
smk 1128 Fri Oct 09 14:13:14 UTC 2015 com/thompco/garagemonitor/GarageMonitor.class
smk 2320 Fri Oct 09 14:13:14 UTC 2015 com/thompco/garagemonitor/GarageMonitorBroadcastClient.class
smk 3631 Fri Oct 09 14:13:14 UTC 2015 com/thompco/garagemonitor/GarageMonitorFinder.class
smk 903 Fri Oct 09 14:13:14 UTC 2015 com/thompco/garagemonitor/GarageMonitorGui$1.class
smk 903 Fri Oct 09 14:13:14 UTC 2015 com/thompco/garagemonitor/GarageMonitorGui$2.class
smk 903 Fri Oct 09 14:13:14 UTC 2015 com/thompco/garagemonitor/GarageMonitorGui$3.class
smk 822 Fri Oct 09 14:13:14 UTC 2015 com/thompco/garagemonitor/GarageMonitorGui$4$1.class
smk 954 Fri Oct 09 14:13:14 UTC 2015 com/thompco/garagemonitor/GarageMonitorGui$4.class
smk 8192 Fri Oct 09 14:13:14 UTC 2015 com/thompco/garagemonitor/GarageMonitorGui.class
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 run the jnlp file, I still get the aforementioned error. Is there any way to trouble-shoot this?
Is there anyway to trouble-shoot/debug this?

OK, after pulling the remainder of my hair out, I stumbled on this thread. Turns out you:
go to your java control panel and settings... uncheck 'Keep temporary
internet files on my computer'. Apply changes and try again your .jnlp
it works! Well it did. Once.
I subsequently found this EXTREMELY useful JNLP debugger from Andrew Thompson (no relation) called JaNeLa. The website it was originally hosted is down, but AlBundy (and we thought he was just a shoe salesman) put it on github here
Turns out it is extremely easy to use: Just run the jar and point it at the URL or file (URL is better.)

For me, after moving to Java 8, I saw this same error. The solution for me was to add:
Permissions: all-permissions
to the jar manifest. For more information, see this oracle blog and info on the Permissions Attribute. (It seems as if Permissions attribute was needed with Java 7, but it didn't become an issue for me until I started using Java 8.)

Java Webstart: JRI (Java R Interface) as nativelib in JNLP not found

I am trying to load the JRI in my webstart-application. I always get this exception:
Cannot find JRI native library!
Please make sure that the JRI native library is in a directory listed in java.library.path.
JNLP file:
...
<resources>
...
<jar href="JRI.jar" />
...
<nativelib href="JRI.jar" />
</resources>
...
I use a batch script to run my application under Windows 7:
set R_HOME=C:\ProgramData\R\R-2.14.0
set R_PATH=C:\ProgramData\R\R-2.14.0\library\rJava\jri
set JNLP_URL=http://localhost/app/app.jnlp
set WEBSTART="C:\Program Files\Java\jre7\bin\javaws.exe"
SET PATH=%PATH%;%R_HOME%\bin\i386;%R_PATH%
%WEBSTART% %JNLP_URL%
I try to use an sh script to start my application under Linux (Ubuntu):
#!/bin/bash
export R_HOME=/usr/lib/R/
export r_home=/usr/lib/R/
export rHome=/usr/lib/R/
export rhome=/usr/lib/R/
export rHOME=/usr/lib/R/
export R_PATH=/usr/lib/R/site-library/rJava/jri/
export r_path=/usr/lib/R/site-library/rJava/jri/
export rPath=/usr/lib/R/site-library/rJava/jri/
export rPATH=/usr/lib/R/site-library/rJava/jri/
export rpath=/usr/lib/R/site-library/rJava/jri/
export WEBSTART=/usr/lib/jvm/java-7-oracle/jre/bin/javaws
export JNLP_URL=http://localhost/app/app.jnlp
export PATH=$PATH:$R_HOME/bin:$R_PATH
$WEBSTART $JNLP_URL
For some reason it does work under Windows, but not under Linux. The two batch scripts should do the same...
The application works fine under both, Windows and Linux, until I try to use a method which tries to use R.
It also works completely (including R), when I start my application with the following sh script as a non-webstart version:
#!/bin/bash
export R_HOME=/usr/lib/R/
export rPATH=/usr/lib/R/site-library/rJava/jri/
export JAVA=/usr/lib/jvm/java-7-oracle/jre/bin/java
LIB=<<Libraries>> # I left out this very long line for this post :)
$JAVA -classpath $LIB:. -Djava.library.path=./FAST:$rPATH de.app.MainWindow $*
I have no clue why it is not working with webstart and Linux...
A jar -tvf JRI.jar gives me:
0 Sun Oct 07 12:28:14 CEST 2012 META-INF/
68 Sun Oct 07 12:28:14 CEST 2012 META-INF/MANIFEST.MF
0 Sun Oct 07 12:28:12 CEST 2012 org/
0 Sun Oct 07 12:28:12 CEST 2012 org/rosuda/
0 Sun Oct 07 12:28:12 CEST 2012 org/rosuda/JRI/
1079 Sun Oct 07 12:28:14 CEST 2012 org/rosuda/JRI/RVector.class
582 Sun Oct 07 12:28:14 CEST 2012 org/rosuda/JRI/RMainLoopCallbacks.class
2158 Sun Oct 07 12:28:14 CEST 2012 org/rosuda/JRI/RList.class
1723 Sun Oct 07 12:28:14 CEST 2012 org/rosuda/JRI/RFactor.class
10424 Sun Oct 07 12:28:14 CEST 2012 org/rosuda/JRI/Rengine.class
734 Sun Oct 07 12:28:14 CEST 2012 org/rosuda/JRI/RBool.class
1010 Sun Oct 07 12:28:14 CEST 2012 org/rosuda/JRI/RConsoleOutputStream.class
3082 Sun Oct 07 12:28:14 CEST 2012 org/rosuda/JRI/Mutex.class
9887 Sun Oct 07 12:28:14 CEST 2012 org/rosuda/JRI/REXP.class
190345 Sun Oct 07 12:28:12 CEST 2012 libjri.so
JaNeLA gives me
XML encoding not known, but declared as utf-8
'short' description is longer than 'default' description.
and for every resource jar I specified I got (example for persistence-api-1.0.jar):
Downloads can be optimized by specifying a resource size for 'persistence-api-1.0.jar'.
The resource download at persistence-api-1.0.jar can be optimized by removing the (default) value of download='eager'.
The resource download at persistence-api-1.0.jar can be optimized by removing the (default) value of main='false'.
It might be possible to optimize the start-up of the app. by specifying download='lazy' for the persistence-api-1.0.jar resource.
Lazy downloads might not work as expected for persistence-api-1.0.jar unless the download 'part' is specified.
All those notices are green or yellow.

Does java cryptography extensions(JCE) come bundled with the JRE?

I need to be certain that jce is available even in JRE environments out of the box. After furious googling I only managed to verify that jce comes bundled with the JDK after Java 1.4. Does the jce come bundled with the plain JRE download as well?
Could you point out where you found the information, so I can verify for myself and know what I missed?

yes, the jce is included in all versions of java these days, relevant announcement.

Have you had a look at $JRE_HOME/lib/jce.jar?
~$ jar tvf jce.jar
6399 Thu Jul 27 16:03:42 CEST 2006 META-INF/MANIFEST.MF
6305 Thu Jul 27 16:03:42 CEST 2006 META-INF/JCE_RSA.SF
2015 Thu Jul 27 16:03:42 CEST 2006 META-INF/JCE_RSA.RSA
0 Thu Jul 27 16:03:26 CEST 2006 META-INF/
0 Thu Jul 27 16:03:24 CEST 2006 javax/
0 Thu Jul 27 16:03:24 CEST 2006 javax/crypto/
0 Thu Jul 27 16:03:24 CEST 2006 javax/crypto/interfaces/
210 Thu Jul 27 16:03:24 CEST 2006 javax/crypto/interfaces/DHKey.class
330 Thu Jul 27 16:03:24 CEST 2006 javax/crypto/interfaces/DHPublicKey.class
...etc
Note that the unlimited strength crypto policy files is (still) a separate download.
Cheers,

As mentioned, the JCE does come with all versions of Java.
However, if you wish to implement certain key sizes, be aware that you will need the Java Unlimited Strength Policy files. This is due to US laws on Key sizes.

Why does Java Web Start say a signed jar file is unsigned?

Java Web Start (JWS) says that it can't launch my application because the jar file is unsigned:
Error: Unsigned application requesting unrestricted access to system
Unsigned resource: .../dynaccn.jar
But the jar file is signed:
$ jarsigner -keystore ... dynaccn.jar idv
$ jar tf dynaccn.jar
META-INF/MANIFEST.MF
META-INF/IDV.SF
META-INF/IDV.RSA
META-INF/
edu/
edu/ucar/
edu/ucar/unidata/
edu/ucar/unidata/dynaccn/
App$1.class
...
$ jarsigner -verbose -certs -verify dynaccn.jar
28325 Tue Aug 17 09:41:58 MDT 2010 META-INF/MANIFEST.MF
28404 Tue Aug 17 09:41:58 MDT 2010 META-INF/IDV.SF
2880 Tue Aug 17 09:41:58 MDT 2010 META-INF/IDV.RSA
0 Tue Aug 17 09:41:58 MDT 2010 META-INF/
0 Mon Aug 16 10:10:34 MDT 2010 edu/
0 Mon Aug 16 10:10:34 MDT 2010 edu/ucar/
0 Mon Aug 16 10:10:34 MDT 2010 edu/ucar/unidata/
0 Mon Aug 16 10:10:34 MDT 2010 edu/ucar/unidata/dynaccn/
...
sm 486 Mon Aug 16 10:10:34 MDT 2010 App$1.class
X.509, CN=University Corporation for Atmospheric Research, OU=UNIDATA, O=University Corporation for Atmospheric Research, L=Boulder, ST=Colorado, C=US
[certificate will expire on 2/6/11 4:59 PM]
X.509, CN=Thawte Code Signing CA, O=Thawte Consulting (Pty) Ltd., C=ZA
[certificate is valid from 8/5/03 6:00 PM to 8/5/13 5:59 PM]
[KeyUsage extension does not support code signing]
X.509, EMAILADDRESS=premium-server#thawte.com, CN=Thawte Premium Server CA, OU=Certification Services Division, O=Thawte Consulting cc, L=Cape Town, ST=Western Cape, C=ZA
[certificate is valid from 7/31/96 6:00 PM to 12/31/20 4:59 PM]
[CertPath not validated: null]
...
jar verified.
Warning:
This jar contains entries whose signer certificate's KeyUsage extension doesn't allow code signing.
This jar contains entries whose signer certificate will expire within six months.
This jar contains entries whose certificate chain is not validated.
This jar contains signed entries that's not signed by alias in this keystore.
and both JWS and my browser have a certificate for "Thawte Premium Server CA".
The problem occurs even if the JWS cache and the browser download area are empty.
I don't believe the "KeyUsage" message is relevant because 1) the same certificate chain is used for another application that does launch successfully; and 2) documentation I've read indicates that the Thawte Code Signing CA is only used to verify the UNIDATA certificate and not to sign code.
My environment is Linux 2.6.27.41-170.2.117.fc10.x86_64, Firefox 3.6.8 (i686), and Java 1.7.0-ea.
Why won't this application launch?
UPDATE: I've discovered that the application launches if the "codebase" attribute in the JNLP file references a local directory but not if it references a URL that lies behind user authentication. In the latter case, javaws(1) interprets the authentication webpage as a JNLP file (with obvious results) if invoked from the command-line. If invoked by the "deployJava" script from a user-authenticating webpage (so that the browser has a session cookie), then javaws(1) says that the application isn't signed. I find both of these failure modes odd as the javaws(1) documentation says that it understands user authenticating web pages and the jar file is signed.

I'm on Gentoo Linux, running OpenJDK 7, and I think I experienced the same problem.
I could not get it to work with OpenJDK 7. Only re-signing with a release of the Sun Java 6 JDK ultimately signed the application correctly. (I also re-built it all due to it being managed by ant, I don't know if that is necessary, though).
Merely switching to the official JDK 6 without rebuilding only makes the "[CertPath not validated: null]" warning when varifying with "jarsigner -verify -verbose -certs" disappear, but does not appear to work in the application I ultimately use.

make sure you are not using a cached (unsigned) version of the jar. Clean the temp folder where JWS downloads jars
make sure that all dependencies (jars) of your jar, that require special permissions, are also signed

Make sure you wrap your calls in the applet with a doPrivileged block. I am unsure why it works like this but seems to work like a charm.