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

Question

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.

Petula

Answer 1

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)

Ogletree

Symantec has a TSA URL that will timestamp your self-signed app, -tsa http://sha256timestamp.ws.symantec.com/sha256/timestamp ` – Epilate

Answer 2

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

Seeress

Answer 3

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.

Quadrisect

Answer 4

The timestamp url in the answer (http://sha256timestamp.ws.symantec.com/sha256/timestamp) will no longer work after 7/24/2024

The latests timestamp URL is:

• timestamp.digicert.com
• 216.168.244.9

Note Explaining:

On July 24, 2024, at 17:00 MDT (23:00 UTC) DigiCert will shut down our legacy Symantec timestamping service. If you or customers use timestamping when signing executables or documents, you may need to change the timestamp URL in your signing tool to the newer DigiCert service, timestamp.digicert.com, before the shutdown occurs.

Puritanical

Answer 5

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.

Appalachia

Advising to use an older JDK is not a proper solution. – Secondbest

The correct answer for op's question is: jarsigner -tsa http://timestamp.digicert.com -keystore my keystore myjar.jar myalias – Ehling

This is no future safe solution and therefor should not be accepted as correct anwser. https://mcmap.net/q/348610/-tsa-or-tsacert-timestamp-for-applet-jar-self-signed is correct – Rickeyricki

This is not an error, it is a warning; it is produced when signing, not compiling; and the solution is to heed it, not put your head in the sand or engage in time-travelling. Answer is completely incorrect. – Grossman