Insights and updates on Java SE and OpenJDK from the Java Platform Group Product Management Team

  • October 10, 2013

Signing code for the long-haul

Guest Author

With recent code-signature requirements for Rich Internet Applications, I have received a few good questions from different types of developers

  • What is the role of code signing?
  • How do I prevent my signature from expiring? 

What is the role of code signing?

Code signatures allow people who will receive and use your code to determine that you are, in fact, the publisher and that no one else has intentionally or accidentally modified your deliverable. Code signatures protect against these modifications within your supply chain, when moving across a network, or when appearing through 3rd party distribution channels. Code signatures offer a level of repudiation: even though an imposter tries to look like your app, both you and your customers can prove that it isn’t.

There are two concepts for this level of trust:

  1. Identity, the application providing a claim as to who wrote it.
  2. Authentication, the JRE automatically validating this claim against a set of known trust stores.

The way that this information is provided and checked is through industry standard Certificates, which tie together information about the signers (their identity) with the ability to mathematically verify it (through a key).

For a description on why code signatures are taking a more prominent role within the Java Platform, please see our previous entry, Code Signing – Understanding Who and When.

How do I prevent my signature from expiring?

Trusted Timestamping, introduced in Java 5 (2004), allows your customers to validate your signature even after the certificate has expired. When you sign a JAR file, the Timestamp Authority uses their clock to act as a notary and cryptographically write the date and time into your file.

Without this timestamp, users would only be able to validate your signature based on their current date and time. This could be problematic for long-running or embedded systems because the standard X.509 Certificates contain a NotAfter date that typically ranges from one to four years.

You interact with timestamp authorities when signing code with jarsigner’s TSA argument:

jarsigner -tsa http://tsa.starfieldtech.com …

When your signed file provides a timestamp, Java is able to use that information within the PKIXParameters and determine:

  1. Do I trust this timestamp authority to act as a notary?
  2. Is the signature date before the certificate’s time of expiration?
  3. Based on Certificate Revocation Lists, was this certificate valid on or before the signature date?

If the answer to all questions is yes, then the signature is deemed valid even if the certificate has expired. Therefore, signed code on embedded devices will continue to operate beyond the Certificate’s lifetime.

Certificate revocation may affect the ability to trust a timestamped artifact even if the timestamp occurred before the revocation. Some Certificate Authorities do not currently allow back-dating of revocations, which call to question which happened first: the revocation or the timestamp. Java systems may ignore the timestamp when they identify that the code-signing certificate has been revoked.

Several trusted timestamp authorities are listed in the previous post, “Code signing: Understanding who and when.”

A note about Certificate Authorities and revocation lists

Part of the acceptance criteria for being included in Java’s root certificate authority program is allowing back-dating of certificate revocation in the event that a private key is lost or stolen and continuing to publish revocation information even after a Certificate’s public expiration.

Join the discussion

Comments ( 2 )
  • guest Thursday, November 7, 2013

    Your posts have been excellent! But I am missing a step...perhaps you can help?

    As a Windows system admin , I want to configure the Deployment Rule Set.

    I want to buy a certificate off a CA , no problem, I use the tool here to generate the right command for the CSR

    https://www.digicert.com/easy-csr/keytool.htm (pretty cool for a Java newbie)

    I wants me to enter a server name? does it matter what server name I give it? E.g. JavaCert.mydomain.com (the mydomain.com obviously needs to be correct…)

    I assume I am going to push the cert out to all PCs via group policy?

    I also assume I do not actually NEED a server called JavaCert.mydomain.com ?

    yours confused

  • costlow Friday, November 8, 2013

    Thank you.

    To clarify, SSL certificates and code-signing certificates are different. You want a code signing certificate but it looks like you are signing up for an SSL certificate. For DigiCert, they have code signing certificates listed on their home page so use that link instead.

Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.