Sectigo’s Timestamping Service is Set to Expire July 9

What to know about the expiration of one of Comodo CA’s timestamping certificates

Note: Let’s start by mentioning that this article pertains to software developers and distributors who pair timestamping with Comodo code signing certificates to sign Java code. If this is not you, then you can move on to other tasks. If this is you, then you’ll want to keep reading. 

Sectigo, formerly known as Comodo CA, gave notice that one of their intermediate timestamping certificates will expire on Tuesday, July 9, 2019. The expiration of this certificate, which works in conjunction with code signing certificates, is important because it means that any Java code signed with the timestamping service at timestamp.comodo.com may be affected.

While certificate expiration is a normal occurrence, it’s still something that requires action on your part to avoid any service interruptions. Here’s what you need to know:

How to Determine Whether You’re Affected

The timestamping certificates that are set to expire on July 9 are those associated with timestamp.comodoca.com. If your certificates are instead associated with timestamp.sectigo.com, then it means you have a newer timestamped certificate and you’re already set – no further action needs to be taken.

If you’re not sure whether your organization will be affected by this certificate expiration, ask yourself: Do you use Windows or other applications to sign your Java code? If so, then you’re good to go. However, if you use any code signing certificate issued by Sectigo (formerly Comodo CA) before March 4, 2019 – regardless of whether it’s an extended validation (EV) certificate – in a Java environment, then you may be impacted by this certificate expiration.

Ask yourself the following questions:

• Is the application signed in Java?
• Is the application signed and timestamped?
• Does the application have a timestamp from timestamp.comodoca.com?
• Is the timestamp signed by a certificate that is set to expire July 9?

If you answered yes to the above, then your application will be affected. However, there is good news: If your code signing certificate is not yet expired, you can simply resign your code at any time. It’s that easy. 

Another good way to check the status of both your code signing and timestamping certificates is to run the following command:

Are the words “jar verified” included in your output message? If so, great. That means your application is running without any issues. This should be the case for everyone prior to the July 9 deadline.

If your answer is no, it’s likely because you’re reading this after the July 9 deadline has passed, that means your timestamping certificate is expired and isn’t running. You’ll need to re-sign your code.

The Relationship Between Timestamping and Code Signing

Although timestamping Java code is viewed as a best practice, the truth of the matter is that not all software developers and distributors choose to do so. Timestamping, when paired with code signing:

• Establishes a specific point in time in which an object existed and was signed by a valid certificate; and
• Validates that the object has not been altered in any way since it was signed. (Any subsequent changes would invalidate the certificate.)

Java checks the validity of both the timestamping and code signing certificates. As long as at least one of the two is still valid, the signed application will be trusted. Even after your code signing certificate has expired, the timestamped code will still be trusted because timestamping certificates have a significantly longer lifespan — though they’re not indefinite. Timestamping certificates will eventually expire, too, and that will be the case on July 9 for those types of Sectigo certificates.