0 Replies Latest reply on Nov 9, 2017 3:06 PM by 3584002

    Has the way of validating the TSA certificate changed in java 1.8.0_151/152?


      We have an application that starts with JNLP. The jars are signed (using SHA1withRSA algorithm) with a certificate from VeriSign and timestamped by GeoTrust timestamping Signer TSA on 2015. Our certificate has already expired but because of timstamp our application kept working until 31 Oct 2017. At that date the TSA certificate expired:


      Owner: CN=GeoTrust Timestamping Signer 1, O=GeoTrust Inc, C=US

      Issuer: CN=Thawte Timestamping CA, OU=Thawte Certification, O=Thawte, L=Durbanville, ST=Western Cape, C=ZA

      Valid from: Wed Oct 31 01:00:00 CET 2007 until: Tue Oct 31 00:59:59 CET 2017

                     Signature algorithm name: SHA1withRSA


      After this date we noticed that when using older java versions ( 1.8.0_144 and bellow ) running our JNLP will throw this error:


      “Your security settings have blocked an application signed with expired or not-yet-valid certificate from running.”


      However, when using java 1.8.0_151 and 1.8.0_152 we do not get the error and the application runs fine.

      So there are a couple of things that we will like to know.

                     - Is there anything that has been changed with the way Java validates the certificates that can explain this ( in java 1.8.0_151/152) ? Or how signed jars, with expired certificate but timestamped, are verified?

                     - Does the fact, that our application runs now even with a TSA certificate expired, mean that java from now on accepts such signature? It would make sense as it was already timestamped. We want to know this because if that is not the case then we could see this problem again when a new java update is released.

      Remark: I have seen that there have been some changes on the restriction related to SHA1 signature algorithm in java 1.8.0_151 which looks at the timestamp of the signature. Could this be related to our situation?