Code Signing: Certificates, Timestamping, and What a Signature Proves

Code signing attaches a digital signature to software so a recipient can confirm who published it and that it has not been altered since. It is the mechanism behind every "verified publisher" prompt and every silently accepted driver installation. What it proves is narrower than most people assume, and that gap is where the exam questions live.

The mechanics

The publisher hashes the software and encrypts the hash with their private key. That signature, along with the signing certificate, travels with the file. On the receiving side, the system hashes the file, decrypts the signature using the public key from the certificate, and compares. A match means the file is byte-for-byte what was signed.

The certificate itself is validated up the chain to a trusted root, and revocation is checked. Signature valid plus chain valid plus certificate not revoked equals a trusted install; any failure produces a warning or a refusal depending on the platform's policy.

Certificate authorities verify publisher identity before issuing, with extended validation requiring stronger organizational checks. Operating systems increasingly demand hardware-backed key storage for code signing certificates, which exists specifically to make key theft harder.

Timestamping, and why it is not optional

Certificates expire, typically after one to three years. Without a timestamp, every signature made with that certificate becomes invalid on expiry — including signatures on software released years earlier and still in use.

A timestamp from a trusted timestamping authority records when the signing happened. Validators then check whether the certificate was valid at that moment rather than now, so the signature outlives the certificate. Omitting the timestamp is a mistake that surfaces long after release, when the certificate lapses and customers suddenly see untrusted-publisher warnings on software that has not changed.

Revocation interacts with this. If a signing key is compromised, the certificate is revoked with a date, and signatures timestamped before that date can remain trusted while later ones do not — which is only possible because the timestamp exists.

What a valid signature does not tell you

This is the part worth memorizing. A valid signature proves authenticity (it came from the holder of this key) and integrity (it has not changed since signing). It says nothing about whether the software is safe.

Signed malware is routine. Attackers obtain certificates through fraudulent registration, steal signing keys from developer machines and build systems, or compromise a legitimate vendor's pipeline and sign malicious code with the vendor's own key — the pattern described under supply chain attacks. In each case the signature is genuinely valid, and every trust check passes.

This is why application allowlisting based on publisher alone is weaker than it looks, and why signature validation belongs alongside behavioral detection rather than in place of it.

Protecting signing keys

The signing key is the whole system. Anyone holding it can publish software as you, to your customers, through channels they already trust.

Keep private keys in a hardware security module or a signing service so the key material cannot be copied, and never on a developer workstation or in a repository. Sign in a dedicated, controlled environment as part of the build pipeline rather than on whichever machine happens to have the certificate.

Require multiple approvals for a release signing operation, log every signing event, and monitor for signatures you did not authorize — certificate transparency-style monitoring is emerging for code signing and is worth adopting where available. Have a revocation plan written down, because deciding how to revoke while an incident is running costs days.

Rotate and re-sign on a schedule, and keep an inventory of which certificate signed which release, since revoking without knowing what it covers means either leaving malicious builds trusted or breaking legitimate ones.

Where it fits

Code signing answers "did this come from who it claims, unmodified." It does not answer "what is inside this," which is the question a software bill of materials answers, or "does it contain known vulnerabilities," which is composition analysis. A complete position uses all three: signed artifacts, known contents, and continuous checking of those contents against new advisories.

Exam angles

Know that code signing provides authenticity, integrity, and non-repudiation, and that it does not establish that the code is benign. Explain why timestamping allows signatures to remain valid past certificate expiry. Recognize signing key compromise and fraudulently obtained certificates as the primary attacks, and hardware-backed key storage with pipeline-based signing as the mitigation. When a scenario presents malware with a valid signature, the lesson is that signature validation is necessary and not sufficient.