-tsa or -tsacert timestamp for applet jar self-signed - java

When I was trying to self-sign in the jar like below.
jarsigner -keystore my keystore myjar.jar myalias
It gives warning like:
No -tsa or -tsacert is provided and this jar is not timestamped. Without a timestamp, users may not be able to validate this jar after the signer certificate's expiration date (2014-05-08) or after any future revocation date.
Please help to resolve the problem.

The Java 7 release provides a (courtesy?) warning about something which has been in place for a decade...
Trusted Timestamping was introducing in Java 5 (2004). The motivation was so that developers would not be forced "to re-sign deployed JAR files annually" when the certificates expired.
→ http://docs.oracle.com/javase/1.5.0/docs/guide/security/time-of-signing.html
A URL-based Time Stamp Authority (TSA) is usually provided by the issuing Certificate Authority (CA) to work with the same certificates the CA issued. For example, the digicert tsa url can be access as follows:
jarsigner -tsa http://timestamp.digicert.com [.. other options]
→ http://www.digicert.com/code-signing/java-code-signing-guide.htm
Time stamping with self-signed certificate may be an elusive goal since (1) a TSA timestamp needs to be an trusted arms-length transaction (which rules out "self timestamping"), and (2) typical TSA URLs are setup to work with the certificates provided by the same CA organization (i.e. the TSA URL does not process a self-signed certificate)
Update:
URLs to try for timestamping self-signed certificates:
Symantec: -tsa http://sha256timestamp.ws.symantec.com/sha256/timestamp (per comment by brad-turek)
For a private network, one could consider an internal Timestamp Authority such as such as Thales (nCipher) Time Stamp Server (or historically OpenTSA)

This warning tells you that your jar's certificate will expire in may. Hence, users will not be able to execute your program after this date.
To improve the situation, the timestamp feature was added. This way, you can tell users: "I used the certificate at this point of time (which is provided and verified by the time stamp agency - tsa), when it was still valid!" As long as you do not change and resign your jar, it will still run, even after the certificate expires, because users see that at the point of creation the certificate was indeed valid.
For reference: http://docs.oracle.com/javase/7/docs/technotes/guides/security/time-of-signing.html
tl;dr: if you ignore the warning, your jar won't run after 14-05-08. Add a timestamp, and it will still run as long as you don't modify anything.
Regards

I was facing the same problem. Without the timestamp the jar would not get signed.
When you add -tsa http://timestamp.digicert.com, it would not give any warning or error but still the jar would not be signed.
But then I added the following part and it worked for me.
-tsacert alias
So, basically my final command was
jarsigner -verbose -tsa http://timestamp.digicert.com -tsacert alias -sigalg SHA256withRSA -digestalg SHA1 -keystore my-release-key.keystore android-release-unsigned.apk alias_name
Remember the alias_name in the command and the one in keystore should be the same.

This error is caused if updates were made with JDK Java/Oracle 1.7 u51. This JDK is NOT identical to the previous one.
You can install a previous version of the JDK BEFORE u51 (for exemple 1.7u45), or install JDK 6.
Then, when you re-compile, you won't see the error.

Related

SSL HANDSHAKE FAILURE: A signer with SubjectDN CN=*.facebook.com

I am using Liberty 16.0.0.4 and i want to get image from facebook account image so i ran this next command to add facebook certificate to Liberty server
keytool -importcert -keystore /pathToServer/Servers/'03- Liberty 16.0.0.4'/wlp/usr/servers/MyProjectServer/resources/key.jks -file facebook.crt -alias facebooksigner
and the certificate successfully added to liberty key.jks file and i see it when list certificates on this file.
But my problem when i try to get image using URL url = new URL(pictureUrl);
it fires
[ERROR ] CWPKI0022E: SSL HANDSHAKE FAILURE: A signer with SubjectDN CN=*.facebook.com, O="Facebook, Inc.", L=Menlo Park, ST=California, C=US was sent from the target host.
Note: i added <keyStore id="defaultKeyStore" password="{xor}EzY9Oi0rJg=="/> into server.xml
So can u guess why this happen? thanks :)
For SSL to work, the client needs to trust the chain that the server presents to it - from the top (root) level all the way down.
You say that you've put a Facebook cert into your trust store, but is the full chain trusted? At the very least, the root CA that signed the Facebook cert needs to be in the trust store.
In 16.0.0.4 (and earlier), java SE API's will never use the keystore or truststore defined in server.xml. They'll use the JRE's 'cacerts' or whatever alternative you define in the well-known SE system properties that control the trust and key stores.
In 17.0.0.1 (and later), java SE callers can use keystores defined in server.xml if transportSecurity-1.0 is loaded.

Cordova android release build jar verification warnings

I am using cordova to build an android app. Now I want to release it hence I have generated the keys,etc using https://developer.android.com/tools/publishing/app-signing.html
On running
jarsigner -verify -verbose -certs my_application.apk
i am getting the following errors
at the beginning of the output for this i get
[certificate is valid from 9/11/15 3:29 PM to 27/3/43 3:29 PM]
[CertPath not validated: Path does not chain with any of the trust anchors]
at the end of the output
jar verified.
Warning:
This jar contains entries whose certificate chain is not validated.
This jar contains signatures that does not include a timestamp. Without a timestamp, users may not be able to validate this jar after the signer certificate's expiration date (2043-03-27) or after any future revocation date.
What do I do here?
To include a timestamp you have to sign your app with your private key like this
jarsigner -verbose -tsa http://timestamp.digicert.com -sigalg SHA1withRSA -digestalg SHA1 -keystore my-release-key.keystore my.apk my_alias
You must add the path to your keystore in order to use correct entries.
jarsigner -verify -keystore /path_to_my/key.keystore my_application.apk

Signing a jar file with trusted certificate for JWS deployment

I've developed an open source program, WPCleaner, which is distributed through Java Web Start. Current version is available at http://site4145.mutu.sivit.org/WikiCleaner/WikiCleaner.jnlp
With the recent updates in Java, it becomes more and more difficult to deploy Java applications through Java Web Start when you need the application to have a few permissions (writing in the preferences, accessing other web sites, ...)
My application was self-signed, which was ok before but new updates require users to accept the application every time they run it, not just once and for all if they wish. So, I decided to use a trusted certificate for signing my application.
I got one from Certum (apparently, they're free for open source developers), following this discussion: Code signing certificate for open-source projects?
I've generated a new jar file, signed with this certificate (jar file available at http://site4145.mutu.sivit.org/WikiCleaner/WikipediaCleanerTest.jar), but I still have problems: when I start the application through JWS, Java still displays a warning windows not letting me trust the application once and for all. Editor is still displayed as UNKNOWN, but when I look in the details of the message, it's my new certificate from Centrum that's being used.
Does anyone have an idea on what I'm doing wrong ?
I thought that having a certificate from a trusted CA (Centrum seems to be in Java cacerts) would allow users to accept the certificate once and for all.
Thanks
PS: When I run jarsigner -verify, I get the following warning
"This jar contains entries whose certificate chain is not validated."
[Update 2017] Open Source code signing from Certum now uses a cryptographic flash card as a Private Key and must be plugged-in for certificate activation & installation, as well as for code signature. The key costs 125$ (+ shipping fee) and the 1-year certificate alone costs 40$. You can ask for a discount.
Here are the following steps to sign your jar file from scratch.
Instructions
Instructions in English are hard to find and not up to date. The following procedure is based on these 2 documents:
Partial Instructions for Installation and Activation (English) - The part about file "bundle.pem" is missing.
Complete Instructions for Installation and Activation (Polish)
Create, activate and install your certificate:
Go on the "Certum Certification" website in the "OpenSource Code Signing" section and order your certificate.
Once the cryptographic flash card is received (it took 15 days for me), plug it, install the driver and the proCertum CardManager software from the card.
Go to your Certum account and follow the activation process of your newly ordered certificate.
Tip: The CryptoAgent Java Web Start application runs only with a JDK (not JRE) < 9 (so, JDK 7 or 8).
You'll receive a mail asking for some official documents (ID card, rent bill, etc.) and an e-mail verification procedure.
Send the activation required documents and information. You'll receive another mail asking for installing the certificate (the verification was done within 1 hour).
Install the certificate on the cryptographic card following the procedure Storing the Certificate on the card (see the instructions in English, part 4)
Obtain the file "bundle.pem"
This file is mandatory for obtaining a valid certificate chain when signing your application (see the part 7.1.2 in the instructions in Polish).
Basically, it consists of concatenating in a plain text format file 1) your certificate and 2) the Certum Code Signing CA SHA2 public key.
Open proCertum CardManager >> Read Card >> tab Common >> Select your certificate and click "Show details"
Export your certificate: x509 - base-64
Download the Certum Code Signing CA SHA2 in PEM format (from the list of root certificates of Certum).
Create the text file "bundle.pem" by concatenating these 2 certificates (first your certificate and second the Certum certificate).
Sign your jar file with Jarsigner
Create the "provider.cfg" file as explained in the point 7.2 of the instructions in English.
You need the alias of your certificate (and not the owner name) to sign your jar. To obtain it execute the following command:
keytool -list -v -keystore NONE -storetype PKCS11 -providerClass sun.security.pkcs11.SunPKCS11 -providerArg "provider.cfg" -storepass "[your_pin]"
Once you got the alias, the provider.cfg and bundle.pem files ready, just sign your jar with the following command:
jarsigner -keystore NONE -certchain "bundle.pem" -tsa "http://time.certum.pl" -storetype PKCS11 -providerClass sun.security.pkcs11.SunPKCS11 -providerArg "provider.cfg" -storepass "[your_pin]" "[your_code].jar" "[your_alias]"
Personally, I use an Ant script to sign my application jar files. See signjar task from ANT project.
I think I finally managed to do it following this procedure:
Installed the certificate provided by Certum in Chrome through their web site interface
Exported the private key as a .pfx from Chrome (Settings, Manage certificates, Export, Export the private key, PKCS#12, ...)
Used KeyTool GUI (java fronted GUI for keytools) to create a complete p12: imported Certum root certificate as a trusted certificate, imported intermediate certificates as trusted certificates, imported my .pfx as a key pair
Signed the jar with this p12
Seems to work for me, I'm waiting for other users feedback to be sure that it works for them also.
Edit: I tried again to export the certificate from Chrome, and I saw that there's an option to include the certificate chain in the export. When doing this, I don't even need to use the KeyTool GUI afterwards. I've redeployed the test version signed with this new p12 :
Installed the certificate provided by Certum in Chrome through their web site interface
Exported the private key as a .pfx from Chrome (Settings, Manage certificates, Export, Export the private key, PKCS#12 + include certificate chain, ...)
Signed the jar with this p12
I'm waiting for other users feedback to be sure that it works for them also.
Based on JaNeLA for the file - valid JNLP. Most importantly known publisher for WikiCleanerTest..
So there is one result of 'seems to work here for identifying the publisher'. Great work and thanks for description of the process.
Works so much better than the one I looked at before. :P
Jarsigner -verify
s 292828 Sun Oct 20 17:57:58 EST 2013 META-INF/MANIFEST.MF
292645 Sun Oct 20 17:57:58 EST 2013 META-INF/WPCLEANE.SF
2017 Sun Oct 20 17:57:58 EST 2013 META-INF/WPCLEANE.RSA
0 Sun Oct 20 17:57:52 EST 2013 META-INF/
0 Wed Feb 11 15:04:50 EST 2009 META-INF/maven/
..
0 Sun Oct 20 17:57:32 EST 2013 org/xnap/commons/i18n/
sm 2837 Thu Sep 09 16:00:54 EST 2004 META-INF/info.xml
..
sm 214 Wed Feb 11 00:57:02 EST 2009 org/xnap/commons/i18n/LocaleChangeListener.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.
Warning:
This jar contains entries whose certificate chain is not validated.
Re-run with the -verbose and -certs options for more details.
I understand the warning:
This jar contains entries whose certificate chain is not validated.
..can be ignored.
JaNeLA Report
JaNeLA shows one error.
JaNeLA Report - version 11.05.17
Report for http://site4145.mutu.sivit.org/WikiCleaner/WikiCleaner.jnlp
cvc-complex-type.2.4.a: Invalid content was found starting with element 'homepage'. One of '{description, icon, offline-allowed, shortcut, association, related-content}' is expected.
cvc-complex-type.2.4.a: Invalid content was found starting with element 'homepage'. One of '{description, icon, offline-allowed, shortcut, association, related-content}' is expected.
XML encoding not known, but declared as utf-8
Codebase + href 'http://site4145.mutu.sivit.org/WikiCleaner.jnlp' is not equal to actual location of 'http://site4145.mutu.sivit.org/WikiCleaner/WikiCleaner.jnlp'.
Desktop icons were subject to bug nnnn in earlier J2SE versions
Optimize this application for off-line use by adding the <offline-allowed /> flag.
'short' description is longer than 'default' description.
Downloads can be optimized by specifying a resource size for 'WikipediaCleaner.jar'.
The resource download at WikipediaCleaner.jar can be optimized by removing the (default) value of download='eager'.
Lazy downloads might not work as expected for WikipediaCleaner.jar unless the download 'part' is specified.
Resource type png of resource commons-nuvola-web-broom.png is not one of the allowable types of gif, jpg, jpeg.
Downloads can be optimized by specifying a resource size for 'commons-nuvola-web-broom.png'.
Icon loading & use can be optimized by specifying the width and height for commons-nuvola-web-broom.png
See the JNLP validated, and a corrected version with tweak, below.
Launch
But here is the real bad news:
Here are some details of the certificate:
Nicolas Vervelle (Nicolas Vervelle)
Subject: CN=Nicolas Vervelle,
OU=WikipediaCleaner,
O=WikipediaCleaner,
L=Paris,
ST=France,
C=FR
Out Of Date Java
Here is a strange warning I do not understand..
The app. is requesting 1.5.0+ so any version 1.7+ should be accepted without question.
It claims to be requesting 1.6 (probably because I have no 1.5 run-time installed). The only thing I can think is triggering the warning is the inclusion of a micro-version, which is unnecessary.
JNLP
Here is the JNLP validated above:
<?xml version="1.0" encoding="utf-8"?>
<jnlp spec="1.5+" codebase="http://site4145.mutu.sivit.org/WikiCleaner" href="WikiCleaner.jnlp">
<information>
<title>WPCleaner</title>
<vendor>User:NicoV</vendor>
<description>WPCleaner</description>
<description kind="short">A tool for Wikipedia maintenance</description>
<homepage href="http://en.wikipedia.org/wiki/WP:WPCleaner"/>
<icon href="commons-nuvola-web-broom.png"/>
<shortcut>
<desktop/>
</shortcut>
</information>
<security>
<all-permissions/>
</security>
<resources>
<j2se version="1.5.0+" java-vm-args="-Xmx512M"/>
<jar href="WikipediaCleaner.jar" download="eager" main="true"/>
</resources>
<application-desc main-class="org.wikipediacleaner.WikipediaCleaner"/>
</jnlp>
Here is a suggested replacement. It is valid according to JaNeLA (bar warnings that we can ignore). It also includes another tweak to the minimum version attribute.
<?xml version="1.0" encoding="utf-8"?>
<jnlp spec="1.5+" codebase="http://site4145.mutu.sivit.org/WikiCleaner" href="WikiCleaner.jnlp">
<information>
<title>WPCleaner</title>
<vendor>User:NicoV</vendor>
<!-- Should be here.. -->
<homepage href="http://en.wikipedia.org/wiki/WP:WPCleaner"/>
<description>WPCleaner</description>
<description kind="short">A tool for Wikipedia maintenance</description>
<icon href="commons-nuvola-web-broom.png"/>
<shortcut>
<desktop/>
</shortcut>
</information>
<security>
<all-permissions/>
</security>
<resources>
<!-- the micro-version request might be triggering the
Out-Of-Date Java version warning -->
<j2se version="1.5+" java-vm-args="-Xmx512M"/>
<jar href="WikipediaCleaner.jar" download="eager" main="true"/>
</resources>
<application-desc main-class="org.wikipediacleaner.WikipediaCleaner"/>
</jnlp>
On Linux, the following procedure worked for me. It is based on the answer by Eric David.
Get your Certificate
Go on the "Certum Certification" website in the "OpenSource Code Signing" section. Buy a certificate and follow the creation procedure.
Get the Public Key for Code Signing
Get the Public Key of Certum Code Signing CA, probably the CA SHA2 key cscasha2.cer.
Convert the certificate to pkcs12 format
Import your own certificate (the one you got from Certum) into Firefox: menu item settings - advanced - certificates - show certificates.
Import the CA SHA2 puplic key (used by Certum to sign your certificate): tab cert. authorities - import.
Verify. It should tell that it has been verified: tab own certificates - show.
Export the certificate: tab own certificates - save - as pkcs12 (e.g. to mycert.p12)
Convert from pkcs12 format to jks format
Find the alias used in your pkcs12 file. It will be similar to "unizeto technologies s.a. id von open source developer, YOUR NAME".
keytool -list -v -storetype pkcs12 -keystore mycert.p12 > out.txt
grep Aliasname out.txt
Then convert the pkcs12 file into java's jks format. This step could be omitted, but once done it is convenient.
keytool -importkeystore -srckeystore mycert.p12 -srcstoretype pkcs12 -srcalias "ALIASNAME" -destkeystore mycert.jks -deststoretype jks -deststorepass PASSWORD -destalias SHORTALIAS
Sign your jar file
To avoid warnings to the webstart user, the jar manifest file should contain the following attributes:
Application-Name: APPNAME
Permissions: all-permissions
Codebase: URL
Application-Library-Allowable-Codebase: URL
Sign your jar file using the following command:
jarsigner -keystore mycert.jks -tsa http://time.certum.pl FILENAME.jar SHORTALIAS
I solved the same problem on mine today with this :
Manifest-Version: 1.0
Trusted-Library: true
Application-Library-Allowable-Codebase: *
Trusted-Only: false
Application-Name: My app
Permissions: all-permissions
Created-By: 1.6.0_16 (Sun Microsystems Inc.)
Caller-Allowable-Codebase: *
Codebase: *
As mentioned here, to remove the UNKNOWN PUBLISHER warning you can add the certificate you used to sign the jar into the Signer Jar of the Java Control Panel: Configure Java -> Security -> Manage Certificates -> Signer Jar option -> Import.

Error with signing jar files using jarsigner with a real certificate

I have a problem with signing my jar files with jarsigner. I used this tutorial to sign my jar files, but with the last step(signing the jar), I got this error:
jarsigner error: java.lang.RuntimeException: keystore load: Invalid keystore format
and I didn't use step #10, I used instead step #5 from this site since, I'm using a real certificate not a fake one ...
Note:
I'm having my certificate in .spc & .pvk format...
But, since I'm using jarsigner, I have to convert them to .p12 format. So, I convert them first to .pfx using pvkimprt.exe then to .p12. I used the method that I specified in the link that I mentioned it before.
Also, I tried to create a fake certificate to make sure that the problem is not from the pvkimprt.exe tool or from the certificate. It gave me the same error.
The certificate is just fine. So, where is the problem came from?
The error you are facing indicates that jarsigner does not understand the format of the keystore containing the key.
If you converted your key & certificate into a PKCS#12 file you have to specify the type of used keystore to jarsigner with the -storetype PKCS12 command line option and the P12 password with -storepass mystorepassword
(actually most of the time .pfx and .p12 are used for the same file format therefore I am not sure that the firefox import/export step in the tutorial is mandated)
Not really an answer, just a comment - I found that the upper case was crucial - "pkcs12" didn't work but "PKCS12" did, using Jcs's answer.
This is what I did and that worked:
<ant:signjar alias="le-f0b73c88-1f82-4497-8c3f-e10d399b4c9c" storetype="pkcs12"
storepass="fount-current"
keystore="/vobs/oam_base/loadbuild_tools/common/src/conf/kunal.pfx">
Store pass should be the lower case, this is the working order or arguments, some time wrong order with throw the runtime padding exception.
[signjar] jarsigner error: java.lang.RuntimeException: keystore load:

How to test the code signing of a JAR file on a client machine?

We have signed a JAR file using a certificate generated by MS Active Directory Certificate Services. However, when accessing it via Java Web Start we are getting the prompt that the digital signature cannot be verified even though we've installed the root CA into the certificate store on the client machine.
Now trying to look at the root CA on the client machine, using "keytool -list", I'm seeing an exception (invalid URI:file://\my_msadcs_server\path\to\CRL.crl). So now I'm not sure exactly what is going wrong.
Anyone have a suggestion or sample Java code on how I can test the downloaded JAR file's signature on the client machine in an attempt to figure out exactly why JWS is complaining? It could be that the root CA certificate has a problem (and I will chase down that avenue when my AD admin gets in) but I'd like to rule out other possibilities first. Currently the only thing I have to go on is the exception from "keytool -list", but keytool had no issues importing the root CA certificate in the first place.
Thanks in advance!,
mG.
I use jarsigner with the -verify, -verbose and -certs options. You may have to specify your -keystore, too.
I think the invalid URI message is a clue. Java file URI takes the following form: file://host/path

Categories

Resources