Code Signing Myths: Why a Valid Digital Signature Does Not Equal File Safety

Digital signatures are frequently treated as proof that a file is trustworthy. In practice they answer a narrower question: the file was produced by a named publisher at a specific moment and has not been altered since. They do not state that the file is safe today, that the signer is still the legitimate owner of the key, or that the key has never been stolen.

Attackers obtain usable certificates through several non-cryptographic routes. A private key left on a CI build agent can be exfiltrated during a compromise, exactly as occurred with the Stuxnet samples signed by certificates stolen from Realtek and JMicron. Supply-chain attacks such as ShadowHammer against ASUS Live Update in 2019 replaced payload contents while preserving the original publisher signature. Certificates can also be purchased from resellers that perform minimal identity checks, allowing an attacker to operate under a formally valid but effectively fictitious legal entity.

Expired certificates remain dangerous because signature verification evaluates the chain at the time recorded by an RFC 3161 timestamp token rather than the current date. Using the OpenSSL -attime flag demonstrates that a chain rejected today as expired will validate when tested against a date inside the original validity window. The same mechanism applies to Authenticode signatures; Windows accepts signatures timestamped while the certificate was still valid even if the certificate has since expired. The 2022 Nvidia certificate leak illustrated the issue: both keys were already expired yet were still used to sign drivers that Windows loaded without complaint.

Signature hashes do not cover the entire file. Authenticode deliberately excludes the PE checksum field, the certificate table directory entry, and the attribute certificate table itself. Historical implementations of WinVerifyTrust performed no additional checks on the excluded region, enabling the padding abuse documented in CVE-2013-3900. Microsoft published Security Advisory 2915720 and the EnableCertPaddingCheck registry key, yet the stricter behavior remains opt-in because it can break legitimate distribution workflows.

Revocation is equally unreliable for code-signing scenarios. When CRL or OCSP endpoints are unreachable, most verifiers treat the certificate as valid. Even when revocation succeeds, the revocation date can be set after the actual compromise, preserving a window during which timestamped malicious signatures continue to pass checks.

Practical defenses therefore focus on concrete identity rather than the mere presence of a signature. Maintain explicit thumbprint allow-lists in WDAC or AppLocker, treat timestamp tokens as first-class telemetry, block known-compromised certificates by thumbprint, and enforce strict revocation checking for high-risk categories. Signing keys must reside only in hardware security modules; build agents should submit hashes for signing rather than hold extractable private keys.