Code Signing Certificates: How They Work and Why They Matter

Code signing certificates sit at the intersection of software distribution integrity and organizational accountability. They function as cryptographic credentials that bind a software publisher's verified identity to an executable, script, or package — allowing operating systems, enterprise security tools, and end-users to confirm that distributed code has not been tampered with after publication. This page describes the structure, issuance process, operational scenarios, and classification boundaries of code signing certificates within the broader public key infrastructure ecosystem.

Definition and scope

A code signing certificate is an X.509 digital credential issued by a trusted Certificate Authority (CA) that enables a software publisher to digitally sign code artifacts using asymmetric cryptography. The certificate contains the publisher's verified identity, the CA's digital signature over that identity, a validity period, and the public key corresponding to the publisher's private signing key.

The scope of code signing spans executable binaries (.exe, .dll, .msi), device drivers, firmware images, mobile application packages (.apk, .ipa), PowerShell and other scripts, kernel modules, and software update manifests. The CA/Browser Forum — the industry standards body whose baseline requirements govern publicly trusted certificates — maintains the Code Signing Baseline Requirements that specify minimum validation, key protection, and revocation standards for publicly trusted code signing CAs.

Code signing certificates are distinct from TLS/SSL certificates, which authenticate servers and encrypt transport-layer sessions. Code signing certificates authenticate the origin and integrity of static artifacts — not live network sessions. They are also distinct from document signing certificates and S/MIME email certificates, which operate under different CA/Browser Forum baseline requirements and trust chains.

How it works

The code signing process follows a defined cryptographic sequence anchored in asymmetric encryption:

  1. Key pair generation. The publisher generates a public-private key pair. The CA/Browser Forum Code Signing Baseline Requirements (Section 6.2.7) mandate that private keys for publicly trusted certificates be generated and stored in hardware security modules (HSMs) or equivalent hardware-backed storage — not in software alone. Hardware Security Modules meeting FIPS 140-2 Level 2 or higher satisfy this requirement (NIST FIPS 140-2).
  2. Certificate issuance and validation. The publisher submits a Certificate Signing Request (CSR) containing the public key and organizational information. The CA validates the applicant's legal identity — through business registration records, government databases, and direct verification — before issuing the certificate.
  3. Signing the artifact. The publisher's signing tool (e.g., Microsoft SignTool, jarsigner, Apple codesign) computes a cryptographic hash of the code artifact using an algorithm such as SHA-256 and encrypts that hash with the publisher's private key, producing a digital signature. The signature, the certificate, and certificate chain are embedded into or attached to the artifact.
  4. Timestamping. A trusted timestamping authority (RFC 3161) records the signing time independently. This allows signatures to remain valid after the signing certificate expires, provided the signature was created during the certificate's validity window.
  5. Verification at execution. The operating system or security tool retrieves the embedded signature, decrypts it using the publisher's public key from the certificate, recomputes the artifact's hash, and compares the two values. A match confirms integrity. The certificate chain is then validated against the system's trust store to confirm the CA is trusted.

Operating system trust stores — including the Microsoft Trusted Root Program and Apple Root Certificate Program — control which CAs are trusted by default on their respective platforms. Publishers whose certificates chain to a root not in these stores will trigger platform-level warnings or execution blocks.

Common scenarios

Enterprise software distribution. Organizations distributing internal tools or commercial software sign installers and update packages to satisfy Windows SmartScreen and macOS Gatekeeper policies. Unsigned or low-reputation executables on Windows trigger SmartScreen blocks or warnings, impacting deployment at scale.

Kernel-mode driver signing. Microsoft requires that all 64-bit Windows kernel-mode drivers submitted after 2016 be signed through the Windows Hardware Dev Center portal, using Extended Validation (EV) code signing certificates. Unsigned kernel drivers are blocked by default under Secure Boot and Kernel Mode Code Signing enforcement.

Mobile application publishing. Apple's iOS ecosystem requires all apps to be signed with a Developer ID or Distribution certificate issued through Apple's own CA hierarchy before submission to the App Store or enterprise distribution. Google Play requires APK signing using Android's APK Signing Scheme.

Open-source software and package ecosystems. Package registries such as PyPI, npm, and Maven Central have adopted or are adopting Sigstore, a Linux Foundation project providing keyless signing infrastructure, as a complement to traditional CA-issued certificates. Sigstore issues short-lived certificates tied to OpenID Connect identity tokens rather than long-term hardware-stored keys.

Script and macro signing. PowerShell's execution policies (Restricted, AllSigned, RemoteSigned) enforce code signing requirements for scripts. Configuring AllSigned policy requires all scripts to carry a valid signature from a trusted publisher — a common enterprise hardening control documented in NIST SP 800-70.

Decision boundaries

Organization Validation (OV) vs. Extended Validation (EV). OV code signing certificates require the CA to verify the publisher's legal existence but not physical presence or strict identity verification beyond standard business records. EV certificates require stricter vetting — including verification of authorized certificate requestors and physical address confirmation — and immediately qualify for higher reputation scores in platforms like Windows SmartScreen, bypassing the reputation-building period that OV certificates require. EV certificates also mandate HSM-based key storage by baseline requirement; OV certificates formerly permitted software storage, though the CA/Browser Forum has progressively tightened this for OV as well.

Certificate lifetime and revocation. Code signing certificates are issued with maximum validity periods constrained by CA/Browser Forum requirements — as of 2023, the maximum is 39 months. When a private key is compromised, the issuing CA revokes the certificate via OCSP or CRL. Properly timestamped signatures retain validity post-revocation if the timestamp predates revocation; signatures without timestamps become unverifiable immediately upon revocation.

Private vs. publicly trusted CAs. Enterprise environments may operate private CAs whose root certificates are distributed via Group Policy or MDM. Code signed under private CA hierarchies is trusted only within environments that explicitly trust the root — not by the general public. Public software publishers require certificates from publicly trusted CAs embedded in platform trust stores.

The integrity of code signing depends entirely on private key protection. Compromised signing keys — as demonstrated in supply chain incidents documented by CISA — enable adversaries to distribute malware bearing legitimate publisher signatures, bypassing signature-based controls entirely. Key protection practices intersect directly with encryption key management and cryptographic key lifecycle disciplines.

References

Explore This Site

Regulations & Safety Regulatory References