On this page
01 What code signing is
Code signing is a digital signature applied to an artifact: a firmware image, an OS package, a container image, a script or a bundle of configuration files. The publisher hashes the artifact, typically with SHA-256, and signs that hash with a private key. The signature travels with the artifact, embedded or detached. Anyone holding the publisher's public key can recompute the hash, check the signature, and know two things: the key holder signed these bytes, and the bytes have not changed since.
The public key is usually wrapped in an X.509 certificate, which binds the key to a name and is itself signed by a certificate authority. Verification has two halves: the mathematics of the signature, and the chain from the signing certificate to a root the verifier already trusts. This page in the network-layer chain of custody lane covers both halves.
02 Certificate chains, timestamps and revocation
A code signing certificate lives one to three years; the artifact it signed may run for a decade. RFC 3161, the Time-Stamp Protocol, bridges the gap. At signing time the publisher sends a hash of the signature to a Time Stamping Authority, which returns a signed token stating the hash existed at a given time. A verifier then accepts the signature if the certificate was valid at that moment. RFC 3161 requires a trustworthy time source and a unique serial in each token, which is what makes the token usable as evidence.
Revocation is the reverse case: the certificate is within its dates but the key has leaked. A verifier checks a CRL or OCSP responder for the signing certificate and every intermediate. A revocation dated before the timestamp invalidates the signature; one dated after usually does not, so date the revocation from the moment the key was lost.
03 What code signing proves and what it does not
A valid signature proves that the holder of a particular private key signed these exact bytes, and that the bytes are unchanged since. With a trusted chain it further proves a certificate authority vouched for the name on the certificate. It does not say the code is free of bugs, that the build system was clean, or that the signer was authorised, only that the key was available to whoever signed.
Vendor firmware has shipped signed and still carried serious bugs; the archive of Foundry-era security advisories and fixes shows the pattern, since every affected release was a legitimately published image. Signing tells you whose image you are loading and that no one altered it. Whether to load it is a question for the advisory list and a test bench.
04 Where code signing shows up in a network operator's life
Secure boot on switches and routers comes first. NIST SP 800-193, the Platform Firmware Resiliency Guidelines, covers protection, detection and recovery for platform firmware; its protection model has the platform verify a signature on each firmware component before executing it, from a hardware root of trust. Boot ROM checks bootloader, bootloader checks OS image, and a wrongly signed image is refused. On a core router that carries the whole site, this stops a modified image loading from a USB stick or a rogue TFTP server.
Signed OS packages come second: distribution repositories sign their package indexes, commonly with OpenPGP as defined in RFC 4880, and the package manager refuses anything the index omits. Container images come third: the registry stores a signature beside the image digest, and host policy refuses an image without one. Automation artifacts, the playbooks that push changes to devices, come fourth and are the ones most often left unsigned.
The newest idea is to sign the configuration itself: the diff and the resulting configuration, packaged and signed by the engineer who approved it, so that months later the question of who approved this line has a cryptographic answer. When a language model drafted the change, the signature still belongs to the person who approved it; the tool is a metadata field, not the signing identity. The verification steps for AI-drafted router configs cover the review that precedes the signature.
05 Comparing checksums and signing methods
| Method | What it proves | Survives cert expiry | Names the signer |
|---|---|---|---|
| SHA-256 checksum | Bytes match a digest; only as good as the channel it came over | Not applicable | No |
| OpenPGP detached signature (RFC 4880) | Holder of a named key signed these bytes | Yes, if the key is kept | Key ID and user ID |
| X.509 code signing with RFC 3161 timestamp | Holder of a CA-vouched certificate signed these bytes at a stated time | Yes, with the timestamp | Certificate subject |
| Transparency-log signing (Sigstore style) | An identity-bound short-lived certificate signed these bytes; the event is logged publicly | Yes, the log entry outlives the cert | An email or CI job identity |
06 The supply-chain view: SBOM, transparency logs and SLSA
Code signing answers who published this; supply-chain frameworks answer how it was built. A software bill of materials is a signed inventory of an artifact's components. Sigstore's documentation describes a model in which a signer obtains a short-lived certificate from a certificate authority (Fulcio) tied to an identity such as an email address or a CI job, signs, and records the event in a permanent transparency log (Rekor). The signer discards the key; verifiers rely on the log entry and the identity.
SLSA, the Supply-chain Levels for Software Artifacts specification, grades build provenance: level 1 means provenance exists, level 2 means a hosted build platform signed it, level 3 means the platform is hardened against tampering during the build. Build provenance is a separate claim from the code signature; check it separately.
07 Worked example: a signed firmware image and a signed config bundle
A team is upgrading two distribution switches. The vendor's portal offers switch-os-9.4.2.bin, a SHA-256 value on the page, and a detached CMS signature switch-os-9.4.2.bin.p7s. Step one is a hash comparison. Step two is signature verification against the vendor's signing root, whose fingerprint was recorded at the last upgrade from the vendor's security page, not the download portal. Step three is a load on a lab unit with secure boot enabled.
$ sha256sum switch-os-9.4.2.bin
3f1c9a...e77b switch-os-9.4.2.bin
$ openssl cms -verify -binary -inform DER -in switch-os-9.4.2.bin.p7s \
-content switch-os-9.4.2.bin -CAfile vendor-root.pem -out /dev/null
CMS Verification successful
$ openssl ts -verify -data switch-os-9.4.2.bin.p7s -in switch-os-9.4.2.tsr -CAfile tsa-root.pem
Verification: OK
$ cosign verify-blob --bundle change-4471.bundle \
--certificate-identity approver@example.net \
--certificate-oidc-issuer https://sso.example.net change-4471.tar
Verified OKThe config bundle change-4471.tar holds the new configuration for both switches, a diff against the archived running configuration, and metadata naming ticket 4471, the drafting tool and the reviewers. The approver signed it with a short-lived certificate bound to their directory identity; the verifier names the expected identity and issuer, so a bundle signed by anyone else fails. Both transcripts and the bundle's digest go into the change record; keeping that digest honest on the way to the archive falls to the integrity checks on bytes in flight.
08 Pitfalls: expired certificates, shared keys and wrong roots
- Expired certificate, no timestamp. A signature without an RFC 3161 token stops verifying when the certificate expires, so old firmware suddenly looks untrusted. Timestamp everything you sign; expect a timestamp on everything you consume.
- The signing key lives on a shared box. A key on a jump host that many people can reach proves only that someone with access to that box signed. Keep signing keys in hardware or in an audited signing service.
- Trusting the wrong root. Verifying against the whole system trust store accepts any public code signing certificate, including one bought under a look-alike name. Verify against the one root you obtained out of band.
- Checking the hash from the same page as the file. Whoever replaced the file replaced the digest beside it. A digest is a transport check; a signature is a provenance check.
Signing is the strongest of the file checks in this lane; the plain digest comparison that catches a corrupted or swapped image is the minimum, and the accounting and configuration archive that records who applied a change is where a signed bundle's approver identity is finally checked against what happened on the device.
09 Questions
What does code signing actually prove?
That the holder of a specific private key signed a specific hash, so the artifact is byte-for-byte what was signed. With a trusted chain it also proves a certificate authority vouched for the name on the certificate. It proves nothing about whether the code is correct or safe.
Why do signatures need a timestamp?
Code signing certificates expire within a few years but the artifacts they sign run far longer. An RFC 3161 timestamp token proves the signature existed while the certificate was valid, so a verifier can accept it after expiry. Without the token the signature fails on that date.
Is a SHA-256 checksum enough?
Only for detecting accidental corruption. A checksum beside the file proves the download matches the page, and an attacker who can change the file can change the page. A signature ties the hash to a key the attacker does not hold. Use both, for different purposes.
How does secure boot relate to code signing?
Secure boot is code signing enforced by the platform at power-on. NIST SP 800-193 describes the model: a hardware root of trust verifies the signature on the bootloader, which verifies the OS image, and an unsigned or wrongly signed component is refused before it runs.
Who signs a configuration that an AI tool drafted?
The person who reviewed and approved it. The signature is a statement of responsibility, and a tool cannot carry responsibility. Record the drafting tool in the bundle metadata so the history is honest, but bind the signature to the approver so later questions have someone to ask.
Code signing makes one precise claim: this key holder signed these bytes and they have not changed since. Verify the chain, insist on timestamps, keep keys off shared machines, and extend the same discipline from vendor firmware to the configuration bundles your team approves.