This discussion is archived
6 Replies Latest reply: Feb 2, 2011 3:57 PM by baftos RSS

Purpose of code signing with Timestamp Authority

822266 Newbie
Currently Being Moderated
I develop Java applets hosted on embedded platforms. We sign our .jar files using a code signing certificate, but this certificate expires every three years. This requires us to either provide a means of updating all of our embedded platforms (a monumental task) or having customers just put up with the sketchy "invalid certificate" errors in their browsers.

Recently I discovered the new ability for jarsigner to use a Timestamp Authority (TSA) when signing the .jar. My impression from what I read was that this would allow the browser to recognize .jar files signed during the time period that the code signing certificate was valid. The idea, I thought, was that this would make it unnecessary to warn the user. I've successfully re-signed the modules using a TSA, however when I push my system clock forward I still get the certificate errors after the certificate expiration date. The TSA signing seems to have no affect.

I'm hoping someone can tell me whether I'm doing this correctly, and this is the expected (although unsatisfactory) result. Or whether I'm doing something wrong and by using a TSA to sign the jar, the browser should happily except the expired certificate which was valid when the signature was applied.

Or...if you have any suggestions on how I might accomplish this using any other approach, I am happy for new ideas. Any solution that would allow us to avoid updating this jar on our embedded platforms would be a huge help.
  • 1. Re: Purpose of code signing with Timestamp Authority
    800207 Newbie
    Currently Being Moderated
    Sorry this is not a direct answer to your question, but something similar exists for Microsoft Windows executables. In those, the time stamping authority signature is not a replacement for the CA, it is in addition to the CA. The TSA signature appears as a countersignature in the appropriate spot. I don't know how or if any of this maps onto the jarsigner facility but it might give you a few ideas.
  • 2. Re: Purpose of code signing with Timestamp Authority
    822266 Newbie
    Currently Being Moderated
    The same process takes place when signing Java jar files with a TSA. The signature is first applied with the code signing certificate, and then signed again by the TSA to include the timestamp. The problem is that the browser based Java plugin seems to ignore this timestamp when deciding whether the applet code is a security threat. Documentation seems to indicate that as long as the certificate was valid when the code was signed (which is why I'm now using the timestamp) then the Java plugin won't spawn a security warning. However this does not seem to be the case, the security warning appears regardless of the timestamp. This means that our Java jar files must be upgraded every two years as the certificate expires - a huge undertaking.

    So my question is, am I doing something wrong? Or is ignoring the timestamp the expected pluging behavior, and I need to revise my expectations?
  • 3. Re: Purpose of code signing with Timestamp Authority
    baftos Expert
    Currently Being Moderated
    Late reply, but it is only now that I discovered the answer.
    The timestamp server certificate must be signed by one of JRE's trusted roots.
    I don't know about older JRE's, but my JRE1.6.0_23 recognizes https://timestamp.geotrust.com/tsa.
    Therefore, when signing, use this as your tsa.
    The source of info is: http://www.thawte.com/resources/ssl-information-center/ssl-beyond-ecommerce/code-signing-faq/
  • 4. Re: Purpose of code signing with Timestamp Authority
    EJP Guru
    Currently Being Moderated
    The timestamp server certificate must be signed by one of JRE's trusted roots.
    Or else its certificate must be imported into the truststore you are using.
    The source of info is: http://www.thawte.com/resources/ssl-information-center/ssl-beyond-ecommerce/code-signing-faq/
    All it says there is that this is a timestamp server you can use with Java, because Thawte doesn't have one. It is not the source of your first statement above.
  • 5. Re: Purpose of code signing with Timestamp Authority
    baftos Expert
    Currently Being Moderated
    The source of info is: http://www.thawte.com/resources/ssl-information-center/ssl-beyond-ecommerce/code-signing-faq/
    All it says there is that this is a timestamp server you can use with Java, because Thawte doesn't have one. It is not the source of your first statement above.
    Ok, bad wording 'source'. I did what the link says and suddenly everything worked. So I went more in depth, looked at the trusted roots and realized why it did not work before and why it works now. I wanted to provide some reference for the solution rather than just saying 'use such and such server and it will work'.
  • 6. Re: Purpose of code signing with Timestamp Authority
    baftos Expert
    Currently Being Moderated
    EJP wrote:
    The timestamp server certificate must be signed by one of JRE's trusted roots.
    Or else its certificate must be imported into the truststore you are using.
    Not very practical in an applet context! My grandma loves my applets but does not know how to import certificates into truststores.

Legend

  • Correct Answers - 10 points
  • Helpful Answers - 5 points