Resolve Java Codesigning issues caused by expired Timestamping certificate

Software developed using Java code and signed with a code signing certificate should be signed again, if the code is signed by the Timestamping service supplied by timestamp.comodoca.com by a certificate issued before March 4, 2019. The timestamping certificate expires on July 9, 2019.

Cause

Although the signature applied via the code signing certificate itself does not expire, for a digital signature to be considered valid, the signing must happen while the code signing certificate is valid. This makes it necessary to know when the signature was applied.

A method to ensure that the signature was created with a valid code signing certificate, is to accept only code signed with certificates that are still valid at the time of checking the signature. The problem with this approach is that one would need to re-sign and re-distribute the code about once a year even if the code itself hasn’t changed. For Long-Term Validation (LTV) support it is easier to sign a certain version of your software using time stamping when digitally signing. This proves the the digital signature was valid at the time of signing.

The certificate of the timestamp.comodoca.com timestamp service is about to expire. This means (certain) Java applications should be resigned using the newer timestamp service located at timestamp.sectigo.com. This is because Java checks both code signing and time stamping certificate validity and considers the application unsigned or invalid only in the case that both the code signing and time stamping certificates are expired.

Impact

All Java-based applications that are signed using a Sectigo (Comodo) code signing certificate that has already expired or will expire before July 9, 2019 and the application carries a time stamp originating from timestamp.comodoca.com. Users and processes depending on this application might experience outages or other issues. Once the time-stamping server’s certificate expires, Java based applications will no longer be able to trust that the time-stamp was created when the certificate was valid. It will no longer be possible to confirm if the original signature was created before the code-signing certificate expired.

To check whether your signed JAR files are impacted, you can use the verify commando on your JAR bundle;

 C:\>"\Program Files\Java\jdk-12.0.1\bin\jarsigner.exe" -verify signed_file.jar

Action is required in the following cases:

Directly resign your application when the jar verify output contains the following text. This requires a new codesigning certificate that is still valid:

 The timestamp will expire within one year on 2019-07-09. However, the JAR will be valid until the signer certificate expires on 2019-07-09 (or earlier).

Resign your application before your codesigning certificate expires, when the jar verify output contains;

 The timestamp will expire within one year on 2019-07-09. However, the JAR will be valid until the signer certificate expires on 2019-07-10 (or later).

Solution

To guarantee Long-Term Validation for your signed Java application, it's required to sign your application again using the TSA service at the new TSA endpoint URL at http://timestamp.sectigo.com. All new time stamps are valid for more than ten years from the date of signing.

Further information

Further information can be found in the Sectigo knowledgebase.