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

Plugin1.3.0 and lower
If signed applet is run after certificate has expired, signature will fail, and applet will run as untrusted. Applet must be resigned with valid certificate.
Plugin1.3.0_01, 1.3.0_02 (first versions supporting Netscape 6)
If signed applet is run after certificate has expired, user will be prompted with information that certificate has expired, but will be allowed to run the privileged applet anyway. Prompt will occur each time signed JAR is loaded.
Plugin1.4 (Merlin pending)
If signed applet is run after certificate has expired, user will be prompted with information that certificate has expired, but will be allowed to run the privileged applet. User will see this ONCE ONLY if user selects "Grant Always"

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

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).