How does a timestamp prevent use of a leaked expired certificate to sign a malignant executable?

If it is supposedly fine to share or leak expired certificates then why is it safe to allow use of such certificate to sign code if the signature is timestamped? Should not verification reject all signatures that were created after the certificate is expired?

Here is a sample message from jarsigner, that confused me:

$ jarsigner -verify -verbose -certs xxx.jar
 [entry was signed on 2/1/24, 1:15 PM]
jar verified.
This jar contains entries whose signer certificate has expired.
The signer certificate expired on 2024-01-01. However, the JAR will be valid until the timestamp expires on 2031-11-01.

jarsigner -verify does fail when used with -strict argument, but the message implies that it has nothing to do with timestamp.

I envision a following scenario where timestamping signatures of expired certificates does nothing useful.

  • Alice purchases a certificate from a recognized CA.
  • Alice works with certificate until it is expired.
  • Alice considers expired certificate to be harmless
  • Alice relaxes security of the certificate handling and leaks the private key
  • Chad uses leaked certificate to sign malignant code with a public timestamping service
  • Bob verifies the signed code (with a jarsigner?) and sees:
    • The certificate is expired
    • But the signature has a timestamp
    • As timestamp is valid, he ignores the signing date
  • Bob assumes Alice has produced the code
  • Bob uses the malignant JAR and takes damages

To my understanding, either certificate expiration date should be absolute (all signing should be done before expiration) or all expired certificates have to revoked (which is ridiculously expensive).

Why is neither the case?

UPDATE: A lot of comments imply that is is impossible to sign code with an expired certificate. Please note, that output of jarsigner (verbose) verification lists a date of expiration and a later date of signing, proving that is possible. This question is specifically "why is it possible given security implications?" and not "is it possible?".

  • Welcome to the commuinity. In my opinion it's that the usage of the signed certificates shall be greeted by a warning or similar, but I wouldn't recommend sharing certs (even expired ones) still Feb 4 at 13:54
  • The cert can be shared... the private key used to generate the certificate cannot. You can't sign any code without the private key. (in general .crt files do not have the private key... .pfx files usually do but are often password protected.) Feb 5 at 18:27
  • I'd fine-tune it to verification and expiration dates. Verification just checks the hash of the file against the signature. (It tells you that the file has not been modified and that it was signed by the signer.) The date of expiration has no bearing on verification. "jarsigner -verify" doesn't even check a revocation list, but if you explicitly tell it to, it won't matter if it's past the expiration date. It's the signing that is restricted to before the expiration. Feb 5 at 23:28
  • Now you could just rollback the date of the machine signing it, so Timestamp server verified dates are usually used to sign so that the cert can stay valid forever until/unless revoked. Feb 5 at 23:29
  • "either certificate expiration date should be absolute (all signing should be done before expiration)" - Signing should be done before expiration. It makes no sense to sign after certificate expired, because signature will not be trusted.
    – mentallurg
    Feb 6 at 3:34

1 Answer 1


(I haven't tested this, and am taking your word for how it works.)

This might be a vulnerability in the JAR signing scheme / verification tool. You should not be able to use an expired certificate to create a new timestamped signature (or rather, the signature shouldn't be trusted... technically you can always sign anything if you have a private key).

It is common for a timestamped signature to be trusted after the signer's certificate expires, especially if the certificate only expired and wasn't revoked, as the purpose of such a signature is to state that the data was as specified on the date of the timestamp, and is authentic as per the signer. The "data was as specified" part is what you get from the timestamp (timestamp + hash of the data, signed by a time stamping authority a.k.a. "TSA") and is generally considered valid until the TSA revokes its private key. TSA certificates are generally valid for at least 10 years (the first two I checked, one used 10 year certs with RSA-4096/SHA2-512 and the other used a 20-year cert signed with 384-bit ECC), and might be re-issued with the same private key if there is no reason to expect key compromise in the interim.

However, that only proves the data existed, somewhere, on the specified date. The "data is authenticated by the signer" part should not be trusted if the authentication signer's certificate was invalid (expired, revoked, incorrect key usage info, etc.) when the signature was created, as an invalid certificate is assumed to prove nothing at all about the identity of the private key holder and thus proves nothing about the authenticity of anything signed with said private key. The only exception might be if a new certificate was issued for the same subject with the same key pair, but even that's sketchy; why use an expired certificate at the time of signing if you could get a new one with that key pair?

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .