Time-Stamp Protocol (TSP), defined by RFC 3161, is used to prove the point in time at which an object (such as a software executable) existed and was signed. RFC 3161, together with root store policies, also defines the requirements a trusted third party must adhere to so it can operate as a Time-Stamping Authority (TSA). Time stamping and digitally signing an object can:

• Establish the point in time at which an object existed and was digitally signed.
• Prove that the digital certificate used to sign the object was valid at that point in time.
• Be assured of the identity of the entity (such as a person or organization) that signed the item for purposes of non-repudiation.
• Guarantee that data has not changed since that point in time.

A trusted time stamping / code signing combination is an integral part of secure software distribution processes. Including time stamping when digitally signing a piece of software implements Long-Term Validation (LTV) of the digital signature. The main idea is that a digitally signed and time stamped software executable should be valid at any later time, irrespective of the future status of digital certificate used to sign it (including revoked or expired).

As with any certificates, the longer the lifetime, the higher the risk of compromise. In practice, time stamping certificates expire as well. The validity of a time stamping service is bound to the validity period of its TSA server certificate. Some time stamps issued through timestamp.comodoca.com TSA use a time stamping certificate that expires on July 9, 2019.

What is the Impact of the Upcoming timestamp.comodoca.com TSA Certificate Expiry?

The impact of the TSA server certificate expiry varies by software application platform, as follows:

Windows

• Software developed for Windows using Authenticode will not be impacted. It will continue working before, on, and after July 9, 2019, regardless of the status of the code signing certificate.

Java

• Java checks both code signing and time stamping certificate validity and considers the application unsigned / invalid only in the case that both the code signing and time stamping certificates are expired.

• The time stamping certificate for timestamp.comodoca.com will expire on July 9, 2019.

  • If a Java application is signed with a code signing certificate that is still valid on July 9, 2019, the Java application will continue working. Signed Java applications may experience errors at the later date of July 9, 2019 OR when the code signing certificate becomes invalid (expires or is revoked).

  • If a Java application is signed with a code signing certificate that will already be invalid or expired on July 9, 2019, both the code signing and time stamp digital signatures on that application may be considered invalid and experience errors.

Other Platforms

• No impact.

For more information on this topic, please refer to the Recommended Actions and Q&A sections of this document.

Recommended Actions

Software Vendors

Software vendors of non-Java applications, including those developed on Microsoft platform, do not need to take any action, as there is no impact due to this event.

The following recommendations are designated for software vendors of Java applications.

Software vendors who used code signing and time stamp services for Java applications should promptly check if their signed Java application bears a time stamp signed by a certificate expiring on July 9, 2019. They should check the validity of their own code signing certificates. After obtaining the status of both certificates, the Java application status and resulting action required will fall under one of the categories described in the following table.

Certificate Status		Action
Time stamping	Code signing
Expiring after July 9, 2019	Expiring after July 9, 2019	No action required.
Expiring after July 9, 2019	Expired	No action required.
Expiring on July 9, 2019	Expiring after July 9, 2019	No immediate action required. Re-sign time stamped code prior to your code-signing certificate’s expiration.
Expiring on July 9, 2019	Already expired, or expiring before July 9, 2019	Immediate renewal or replacement of code signing certificate is required so that the application may be re-signed. Otherwise the application’s original signature may become unverifiable on July 9, 2019. Re-sign time stamped code with a valid code signing certificate prior to July 9, 2019.

Status of both certificates can be obtained by running the following command:
C:\>"\Program Files\Java\jdk-12.0.1\bin\jarsigner.exe" -verify my_file.jar

An example output is as follows:

jar verified.
Warning:
The timestamp will expire within one year on 2019-07-09. However, the JAR will be valid until the signer certificate expires on 2020-05-30.
Re-run with the -verbose and -certs options for more details.

As long as the message contains “jar verified”, the application is currently running without problems. The “Warning:” always contains precise information, clearly presenting the status of both certificates.

End-users of Java Applications

Time stamped code affected by the July 9, 2019 certificate expiration may experience errors or outages, depending on the runtime environment. Developers and IT managers who control Java applications should replace them with re-signed code to avoid the potential for such errors.

For processes depending on time stamped Java code from other providers, the following steps may be necessary to ensure continued operation of some Java applications:

• Download a fresh copy of your application from its developer if a newly signed version if available.

• Add the application to your platform’s Exception Site List.

  • Do not forget to remove the application from the Exception Site List as soon you obtain a new version; otherwise you could lose the protection that code signing offers.

  • If the developer of your application is no longer in business, keep your application on the Exception Site List for as long as you use it.

Q&A

Q: Am I affected by this issue?
A: This issue affects a small percentage of code-signing certificate owners:

• If you do not sign Java applications, you are not affected.
• If you do not use time stamps in your signatures of Java applications, you are not affected.
• If you do not use time stamps signed by a time stamping certificate that expires on July 9, 2019 in your signatures of Java applications, you are not affected.
• SSL and other types of certificates are not affected in any way.

Q: What conditions need to be met to be affected by this issue?
A: Only the applications meeting following criteria will be affected:

• The application is Java-based.
• The application was signed.
• The code signing certificate has already expired or will expire before July 9, 2019.
• The application carries a time stamp originating from timestamp.comodoca.com.
• The time stamp was signed by a certificate that expires on July 9, 2019.

Q: How can I find out whether or not my signed Java application used the time stamping certificate expiring on July 9, 2019?
A: You can examine your signed Java application to find information on expiry of certificates used for its signature and time stamp. Please refer to the Recommended Actions - Software Vendors section of this document for details.

Q: As a current owner of a code signing certificate, I would like to continue signing Java applications without encountering any problems after July 9, 2019. Do I need to replace my certificate?
A: No, you do not need to replace your certificate until its expiry date. You should continue signing your Java applications as you would previously have done, except that we recommend you use a time stamp from http://timestamp.sectigo.com instead of http://timestamp.comodoca.com.
All new time stamps are valid for more than ten years from the date of signing.

Q: Are applications developed for the Microsoft Windows platform affected by this issue?
A: No, applications developed for Microsoft Windows platform are not affected.

Q: What are the potential consequences if my Java application is not re-signed before July 9, 2019?
A: Users and processes depending on this application might experience outages or other issues. Please see the Recommended Actions - End-users of Java applications section of this document for details.

Q: I used an EV code signing certificate with a time stamp issued by timestamp.comodoca.com TSA to sign my Java applications. Do I still have to re-sign my applications before July 9, 2019?
A: If your EV code signing certificate has already expired or will expire before July 9, 2019, you should re-sign your Java application.

Q: I have determined that my Java application code signing certificate will be in an expired state on July 9, 2019. What steps do I have to take to ensure my application is working past that date?
A: Obtain a new code signing certificate issued by Sectigo. We recommend time stamping it using the newly established TSA timestamp.sectigo.com. To get assistance with expired Sectigo code signing certificates, contact Sectigo customer support at https://sectigo.com/support.

Q: Are time stamps generated today from timestamp.sectigo.com going to expire on July 9, 2019?
A: No. Since May 4, 2019, timestamp.comodo.com has been an alias for timestamp.sectigo.com, and the time stamps are therefore valid for more than ten years from that date.