Certificate Expiry Issues

M. Gallant 03/29/2001

Digital signatures applied to Java code for web deployment (JAR or CAB archives) are considered valid signatures during the lifetime of the certificate used to sign the code. Typical code-signing (or "software developers, object-signing") certificates are generally issued with a validity period of 1 year. Unfortunately, legitimate signed Java code that is executed on the client AFTER THE CODE-SIGNING CERTIFICATE HAS EXPIRED, is treated differently by the various authentication implementations. The information below describes the current state of affairs for the Win32 OS:

Signed JAR for Netscape JVM

Signed JAR archives for Netscape JVM (i.e. NOT plugin), will continue to be authenticated and run properly, even after the certificate used to sign the Java code has expired (so long as the certificate was valid at the time of signing).

Signed JAR for JavaPlugin Sun JVM

The following Bug report summarizes the current status of signature expiry versus certificate expiry for JavaPlugin:

Signed CAB for IE MS-JVM

Microsoft CAB signing for Authenticode/cryptoAPI does allow for controlled authentication of signatures after the code-signing certificate has expired, but ONLY if the VeriSign (or any other) "time-stamp server" is used in the "signcode.exe" step. Currently, the only such Internet time-stamp service is operated by VeriSign. The time-stamping process places more certificates in the signature block of the CAB archive, and guarantees that the code-signing certificate was in "good standing" at the time of signing, and therefore by implication should reasonably be trusted on an on-going basis (unless, the certificate becomes revoked, of course).