Compromised certificates: Revocations alone are insufficient
Revoking a digital certificate does not automatically invalidate, for instance, software signatures that have been made with this certificate. What matters is the revocation date, which determines the point in time after which a signature will no longer be validated.
According to a report from anti-virus specialist Norman, the signatures of several recently discovered trojans were validated by Windows as a result, and no warning was issued before installing the malware. The trojans were signed with a key that had been stolen from a Japanese company. The corresponding certificate was reported as compromised on 29 July 2011 and revoked by its issuing Certificate Authority (CA), VeriSign, which is now part of Symantec. However, that date was also entered as the revocation date.
Unfortunately, the trojans were signed with the key on 13 April 2010, 3 July 2010, and 22 January 2011 – long before the revocation date. Because of this, the signature code remained valid for the older signatures, and systems would only invalidate signatures that were made after the revocation date.
Norman believes that the issue is down to Certificate Authorities being overly cautious when setting the revocation date, and that they tend to choose a date that is too late over one that is too early. One of the likely reasons for this is that CAs want to avoid invalidating software and documents that have been signed by legitimate customers. In the aforementioned case, after being notified by Norman, Symantec changed the revocation date to 12 April 2010, which invalidated the trojans' signatures.