UrlBlogGrey

At work, we ran into a problem where older releases of our product incorporate a Java Applet that's digitally-signed with a certificate about to expire in a few weeks. The role of digital-signatures is to verify the authenticity and integrity of electronic information based on the shared-trust of a certificate-authority (CA), such as Verisign or Thawte. Most CA's issue certificates that are valid for at most two years because the quality of the trust relationship between the CA and the organization seeking a certificate degrades over time. To combat this (& to sustain the CA's business model), the certificate must be renewed at regular intervals.

So, we needed to determine what behavior to anticipate from our customers when our certificate expires. I set the system clock forward on a VMware image of Windows XP and experimented with the Java Plug-in versions 1.4 and 1.5. To my surprise, the Applet functioned without any warnings when the certificate had already been imported into the plug-in keystore. And when the certificate was not in the keystore, the normal certificate acceptance dialog was presented with just an additional warning message about the expiration status of the certificate.

This puzzled me since the plug-in should honor the expiration of certificates by treating code bearing their signature as untrusted. I googled the subject and learned that the Sun JSSE stops verifying the certificate chain once it encounters a certificate it trusts. In the case where the certificate has been imported into the plug-in keystore, this occurs immediately and the CA certificates aren't consulted. Still, the expiration date of the certificate could be enforced regardless of the keystore-status. But this is not the case.

This represents a minor security vulnerability since it implies that all certificates issued to an organization can be viewed as "active". The private keys of expired certificates must be guarded in the same manner as non-expired certificates. This translates well to the old-world of corporate letterhead. Most companies are careful not to leak unused paper stock bearing the company's letterhead since it may be used to impersonate someone from the company. Similarly, the private keys for expired certificates should be destroyed or stored safely so that they may not be used under false pretenses. Failure to do so could result in the distribution of malicious software bearing an innocent organization's name, resulting in possible legal and economic damages.

I also learned that the Sun Java Plug-in 1.5 supports a time-stamp property in digital signatures that honors any code signed by a certificate at a time when the certificate was active, even if it is now expired. This makes sense for organizations looking to extend the use of their signed-code. It relies on the use of a time-stamping authority who can vouch that the signature was generated on the date/time indicated. This sounds like an interesting idea, but I think it works in opposition to the CA-model where the currency of a certificate is used as a measure of trust.