Code signing involves overlapping vocabularies from cryptography, PKI, Windows internals, and CA/B Forum policy. The same underlying concept sometimes carries different names depending on context: a ‘thumbprint’ and a ‘fingerprint’ are the same thing; a ‘cloud HSM’ and an ‘HSM signing service’ describe the same delivery model. This guide defines the terms precisely, explains why each one matters specifically for code signing, and notes where common usage or competitor guides get definitions wrong.
Terms are grouped thematically. Use the section headings to navigate to the area you need.
Certificate Anatomy and Structure
X.509: The ITU-T standard that defines the format of public key certificates. Every code signing certificate, TLS certificate, and CA certificate follows X.509 format. An X.509 certificate is a structured binary file (DER encoding) or its Base64 text representation (PEM encoding) containing the subject identity, the public key, the validity period, extensions like the EKU and SAN, and the issuing CA’s signature over all of it.
Subject: The identity the certificate asserts. In a code signing certificate, the Subject contains at minimum a Common Name (CN) and for OV/EV certificates also the Organization (O), Country (C), and for EV the Jurisdiction fields. The Organization field value is what appears in UAC dialogs as the publisher name. The Subject is set at certificate issuance based on information the CA validates.
Common Name (CN): A field within the Subject of an X.509 certificate containing a human-readable name for the certificate holder. For code signing certificates, this is typically the organization name or a descriptive name for the certificate. Important distinction: for TLS certificates, browsers stopped using the CN for hostname verification in 2017 (Chrome 58). Only the Subject Alternative Name is used for TLS hostname matching. For code signing, the CN appears in certificate details but the publisher identity displayed in UAC comes from the Organization field.
Subject Alternative Name (SAN): An X.509 extension that lists the names (domain names, IP addresses, email addresses) the certificate is valid for. For TLS certificates, the SAN is what browsers check for hostname verification. For code signing certificates, the SAN is not relevant to signing operations, but certificates generated without a SAN extension (common in older self-signed certificates) sometimes cause tool compatibility issues. The NET::ERR_CERT_COMMON_NAME_INVALID Chrome error is caused by a SAN mismatch or missing SAN, not a CN mismatch.
Extended Key Usage (EKU): An X.509 extension that defines what the certificate’s key pair is authorized to do. EKUs are identified by Object Identifiers (OIDs). The Code Signing EKU has OID 1.3.6.1.5.5.7.3.3. A certificate without this EKU will be rejected by signtool and other code signing tools. The serverAuthentication EKU (OID 1.3.6.1.5.5.7.3.1) is what TLS certificates use. These are separate EKUs and separate certificate types; a TLS certificate cannot sign code and a code signing certificate cannot authenticate a TLS server.
Key Usage: An X.509 extension that specifies the cryptographic operations the key pair can perform. For code signing certificates, the Key Usage includes digitalSignature. This is distinct from the EKU: Key Usage describes the cryptographic operation type; EKU describes the application context. A complete code signing certificate has both Key Usage: digitalSignature and Extended Key Usage: codeSigning.
Validity period: The time window during which a certificate is considered valid, bounded by NotBefore and NotAfter dates. Code signing certificates currently have a maximum validity of 460 days (effective March 2026, down from 39 months). A certificate used outside its validity period fails verification. Timestamped signatures remain valid after the certificate expires because the timestamp records that the signature was valid at signing time.
Serial number: A unique identifier assigned by the issuing CA to each certificate it issues. Serial numbers are used in Certificate Revocation Lists (CRLs) and OCSP responses to identify which certificates have been revoked. If a code signing private key is compromised, the CA revokes the certificate by adding its serial number to the CRL.
Thumbprint / Fingerprint: A cryptographic hash of the entire certificate (not the key, but the certificate as a whole). The SHA-1 thumbprint is the standard identifier for certificates in the Windows Certificate Store, and it is what signtool’s /sha1 flag uses to select a specific certificate. Despite the flag name ‘/sha1’, it refers to the SHA-1 fingerprint of the certificate, not the algorithm used to sign files. All modern code signing certificates use SHA-256 as their signature algorithm while still having a SHA-1 thumbprint for identification purposes.
Certificate chain / Chain of trust: The sequence of certificates from the end-entity certificate (your code signing certificate) up through one or more intermediate CA certificates to a trusted root CA certificate. Each certificate in the chain is signed by the one above it. Windows verifies this entire chain when checking a code signing signature. If any link is missing or untrusted, the verification fails. For code signing, Windows looks for the chain in the local certificate store and the certificate’s AIA (Authority Information Access) extension.
Root CA certificate: A certificate that is self-signed (issued by the CA to itself) and serves as the trust anchor for a certificate chain. Root CA certificates are pre-installed in the Windows Certificate Store (via Windows Update), the macOS Keychain, Mozilla’s NSS store (used by Firefox), and Google’s and Apple’s root programs. A code signing certificate chain must terminate at a root CA that is in the Windows trust store.
Intermediate CA certificate: A certificate issued by a root CA and used to issue end-entity certificates (like code signing certificates) rather than doing so directly from the root. Using intermediates allows root CAs to keep their keys offline (in physical vaults) and limit their direct exposure. When a code signing certificate is mis-issued or an intermediate is compromised, the intermediate can be revoked without touching the root.
Certificate Validation Levels
Domain Validation (DV): A certificate type where the CA verifies only that the applicant controls the domain name. DV validation is automated (ACME protocol) and instant. DV certificates are not available for code signing. Code signing requires organizational identity verification because the publisher name shown in UAC dialogs comes from verified organization information. Let’s Encrypt issues only DV certificates and cannot be used for code signing.
Organization Validation (OV): A certificate type where the CA verifies the organization’s legal existence, operational address, and phone number in qualified independent information sources (QIIS). OV code signing certificates display the verified organization name in UAC dialogs and Authenticode signature details. Since June 2023, OV certificate private keys must be stored on FIPS 140-2 Level 2+ hardware. OV certificates build SmartScreen reputation through download telemetry.
Extended Validation (EV): The highest standard validation tier, requiring the same as OV plus additional steps: verification that the certificate requester is an authorized agent of the organization (officer check), use of an approved legal opinion letter or direct CA validation, and a callback to a QIIS-verified phone number. EV certificates include additional Subject fields (jurisdictionCountry, jurisdictionState, businessCategory). As of August 2024, EV certificates no longer receive a SmartScreen reputation bypass; they build reputation through download telemetry identically to OV. EV remains required for kernel-mode driver signing and WHQL certification.
QIIS (Qualified Independent Information Sources): Third-party databases that Certificate Authorities use to verify organizational information during OV and EV validation. Examples include Dun and Bradstreet (D&B), national company registries, state business registration databases, and Yellow Pages-type business directories. The CA must be able to verify the organization’s name, address, and a working phone number in a QIIS. The phone number requirement is the most common source of validation delays: mobile numbers and VoIP numbers typically do not appear in QIIS databases.
Key Management and Storage
Private key: The secret half of an asymmetric key pair used to create digital signatures. The private key is mathematically paired with a public key. Only the holder of the private key can produce a valid signature that the corresponding public key can verify. For code signing, the private key is what must be protected; compromise of the private key means an attacker can sign software as the certificate holder. The June 2023 CA/B Forum requirement mandates hardware storage precisely because a private key existing as a copyable file can be silently stolen.
Public key: The non-secret half of an asymmetric key pair. The public key is embedded in the certificate and can be freely distributed. Anyone with the public key can verify that a signature was produced by the corresponding private key. The public key alone cannot produce signatures.
Non-exportable key: A private key marked at generation time so that it cannot be extracted from the storage medium in usable form. Hardware tokens and HSMs generate and store non-exportable keys by design. The CA/B Forum CSBR requires that code signing private keys be non-exportable. A key that is non-exportable can still be used to sign (the signing operation happens inside the hardware) but cannot be copied to a file.
FIPS 140-2 / FIPS 140-3: US government standards for cryptographic modules published by NIST. FIPS 140-2 has four levels; FIPS 140-3 (current standard for new validations) aligns with ISO/IEC 19790. The CA/B Forum Code Signing Baseline Requirements specify FIPS 140-2 Level 2 or equivalent as the minimum for code signing private key storage. Level 2 requires tamper-evident physical security. Level 3 (used by most commercial cloud HSMs) additionally requires active tamper response with key zeroization.
HSM (Hardware Security Module): A dedicated hardware device that generates, stores, and uses cryptographic keys inside a physically protected boundary. Cryptographic operations happen inside the HSM; the private key never exists in usable form outside it. Code signing HSMs appear in several form factors: USB tokens (shipped to publishers by CAs), PCIe cards (high-throughput enterprise deployments), network appliances (shared enterprise infrastructure), and cloud HSMs (provider-managed hardware accessible via API).
USB token (hardware token): A small USB device certified to FIPS 140-2 Level 2 or higher that stores code signing private keys and performs signing operations on-device. The private key is generated inside the token and cannot be exported. Tokens are shipped by CAs to certificate holders after validation. The SafeNet eToken 5110 (Thales) is the most common form factor. Since June 2023, all commercially issued OV and EV code signing certificates are delivered on hardware tokens or via cloud HSM.
Cloud HSM / Cloud signing service: An HSM-backed signing service where the hardware is operated by the provider (CA or cloud vendor) and the subscriber authenticates signing requests via API. The private key never leaves the provider’s HSM hardware. Examples include DigiCert KeyLocker, SSL.com eSigner, Sectigo cloud signing, and Microsoft Trusted Signing. Cloud HSMs are required for CI/CD pipeline signing because physical tokens cannot plug into cloud build runners.
TPM (Trusted Platform Module): A security chip integrated into most modern PC motherboards that stores cryptographic keys and performs platform integrity measurements. TPMs are used for BitLocker disk encryption, Windows Hello, and Secure Boot attestation. Despite sometimes achieving FIPS 140-2 Level 2 certification, TPMs are not accepted by CAs for code signing certificate delivery because CAs cannot verify that a key was generated on a specific subscriber’s TPM at issuance time.
PFX / PKCS#12: A binary file format that bundles a private key, certificate, and optionally the certificate chain, protected by a password. PFX (Personal Information Exchange) and .p12 are identical formats with different file extensions. Before June 2023, OV code signing certificates were delivered as PFX files. Since June 2023, commercially issued code signing certificates require hardware storage and are not delivered as PFX files. Self-signed and internal certificates may still use PFX format for development purposes.
CSR (Certificate Signing Request): A file generated by the certificate applicant containing the public key and identity information for the requested certificate, signed with the private key to prove possession. For hardware-delivered code signing certificates, the CA typically generates the key pair on the token or cloud HSM at issuance rather than processing a CSR from the subscriber.
Signing Mechanics and Formats
Authenticode: Microsoft’s code signing technology for Windows executables and scripts. Authenticode uses X.509 certificates to sign PE (Portable Executable) files and other Windows file formats. The signature is embedded in the file’s certificate table section. Windows verifies Authenticode signatures at load time for kernel drivers and at execution time for user-mode applications (UAC and SmartScreen).
Digest algorithm (/fd): The hash algorithm used to hash the file’s content before signing. Signtool’s /fd flag specifies this algorithm. SHA-256 (/fd sha256) is required for modern Authenticode signing. SHA-1 was deprecated by Microsoft for code signing due to the SHAttered collision attack (2017). Using /fd sha1 produces deprecated signatures that may be rejected by modern Windows versions.
Timestamp: An RFC 3161 timestamp embedded in a code signing signature that records the signing time in a cryptographically verifiable way. The timestamp is issued by a Timestamp Authority (TSA), an independent third party whose certificate is trusted separately from the code signing certificate. A timestamped signature remains valid after the code signing certificate expires because the timestamp proves the signature was created while the certificate was still valid. The /tr flag in signtool specifies the timestamp server URL. The /td flag specifies the digest algorithm for the timestamp.
Timestamp Authority (TSA): A trusted service that issues RFC 3161 timestamps. When signtool contacts the timestamp server, the TSA returns a signed token asserting ‘this data was submitted at this time.’ The TSA’s own certificate must be trusted for the timestamp to be valid. DigiCert, Sectigo, and SSL.com provide free public timestamp servers. The timestamp server URL is specified with /tr in signtool.
Dual signing: The practice of embedding two Authenticode signatures in a single file: a SHA-256 signature for modern Windows and a SHA-1 signature for backward compatibility with Windows XP and Vista. The SHA-256 signature is applied first; the SHA-1 signature is appended with signtool’s /as (append signature) flag. Dual signing is rarely needed for new software because Windows XP (2014) and Vista (2017) reached end of life, but legacy environments may still require it.
PE (Portable Executable): The binary format used for Windows executables (.exe), dynamic-link libraries (.dll), device drivers (.sys), and other binary files. Authenticode signatures are embedded in the PE format’s certificate table. The signtool utility signs PE files by hashing the file content (excluding certain header fields that change during signing), signing the hash, and embedding the signature.
Catalog file (.cat): A separate file containing Authenticode signatures for one or more files it references, rather than embedding the signature in each signed file. Windows uses catalog files for driver packages and Windows component signing. Catalog-signed files can be verified without modification to the original files.
Trust Infrastructure and Verification
Certificate Authority (CA): An organization trusted to issue digital certificates, responsible for verifying the identity of certificate applicants and binding that identity to a public key in a signed certificate. Public CAs trusted by browsers and operating systems include DigiCert, Sectigo, GlobalSign, SSL.com, and others. CAs operate under CA/B Forum requirements and are audited annually against standards like WebTrust for CAs.
Root program: A list of root CA certificates that a software platform (Windows, macOS, Firefox, Chrome) trusts by default. The Windows root program (maintained by Microsoft via Windows Update), Apple’s root program, Mozilla’s NSS root store, and Google’s Chrome Root Store each independently decide which CAs to trust. A CA whose root is removed from a root program loses the ability to issue certificates trusted by that platform.
Trust store / Root store: The collection of trusted root CA certificates on a device that TLS clients and code signing verification use as trust anchors. On Windows, the Certificate Store (accessible via certmgr.msc) contains root certificates updated through Windows Update. Chrome and Edge on Windows use this store. Firefox uses its own NSS-based store. macOS has the Keychain. Trust stores are also categorized by purpose: the Trusted Root Certification Authorities store, the Trusted Publishers store (for code signing), and TrustedPeople (for MSIX).
Revocation: The process of invalidating a certificate before its natural expiry date. CAs revoke certificates when the private key is compromised, when validation information was incorrect, or when the subscriber requests revocation. Revocation information is distributed via CRL (Certificate Revocation List) and OCSP (Online Certificate Status Protocol). Windows checks revocation when verifying code signing signatures.
CRL (Certificate Revocation List): A signed list published by a CA containing the serial numbers of certificates it has revoked. Windows periodically downloads CRLs from the distribution points listed in each certificate’s CRL Distribution Points extension. CRLs are batched updates and can be hours to days out of date. The URL for CRL distribution is embedded in the certificate.
OCSP (Online Certificate Status Protocol): A protocol for real-time certificate revocation checking. When a client encounters a certificate, it can query the CA’s OCSP responder with the certificate’s serial number and receive an immediate response (good, revoked, or unknown). OCSP is faster than waiting for CRL updates. The OCSP responder URL is embedded in the certificate’s Authority Information Access extension.
Windows Code Signing Terms
SmartScreen: Microsoft Defender SmartScreen, a reputation-based security system integrated into Windows and Edge. SmartScreen evaluates downloaded executables against telemetry from millions of Windows devices. Files with low or no download history trigger a warning before execution (‘Windows protected your PC’). Files with established positive reputation execute without SmartScreen warnings. Since August 2024, OV and EV certificates build SmartScreen reputation identically through download volume telemetry. The primary remaining SmartScreen-relevant distinction between OV and EV is for kernel driver signing.
UAC (User Account Control): The Windows system that prompts users before applications make changes requiring administrator privileges. When a signed installer runs, UAC displays a blue dialog showing the verified publisher name from the certificate’s Organization field. When an unsigned installer runs, UAC displays a yellow/orange dialog showing ‘Unknown Publisher.’ The publisher name in UAC comes from the certificate’s Subject, which was validated by the CA.
Trusted Publishers store: A Windows Certificate Store location that contains certificates explicitly trusted to sign code for execution under AllSigned execution policies. PowerShell’s AllSigned policy requires scripts to be signed with a certificate in both the Trusted Root and Trusted Publishers stores. This is different from general certificate trust: a certificate can be trusted by Windows (in Root) but not added to TrustedPublishers, in which case AllSigned will still prompt or refuse.
TrustedPeople store: A Windows Certificate Store location used specifically for MSIX package signing trust. For a locally signed MSIX to install without requiring a CA-issued certificate, the signing certificate must be in TrustedPeople (for installation trust), not just in Trusted Root or TrustedPublishers.
signtool.exe: The command-line tool included with the Windows SDK for signing PE files, MSI packages, and other Authenticode-compatible formats with code signing certificates. signtool is not part of Windows itself; it requires the Windows SDK to be installed. Key flags: /a (auto-select certificate), /sha1 (select by thumbprint), /f (use PFX file), /fd (file digest algorithm), /tr (timestamp server), /td (timestamp digest algorithm), /v (verbose), /as (append second signature for dual signing).
Standards, Governance, and Policy
CA/B Forum (CA/Browser Forum): A voluntary industry body of Certificate Authorities, browser vendors, and operating system vendors that sets baseline requirements for TLS and code signing certificates. The CA/B Forum publishes the Baseline Requirements and Code Signing Baseline Requirements (CSBRs). Membership includes DigiCert, Sectigo, GlobalSign, SSL.com, Mozilla, Microsoft, Google, Apple, and others. CA/B Forum ballots require a voting majority of participating CAs and browsers to pass. Key recent ballots affecting code signing: CSC-13 (June 2023 hardware requirement), CSC-31 (460-day maximum validity, March 2026).
CSBR (Code Signing Baseline Requirements): The CA/B Forum document defining minimum requirements for code signing certificate issuance, management, and revocation. The CSBRs specify validation requirements for OV and EV, hardware storage requirements (effective June 2023), maximum validity periods (460 days, effective March 2026), and technical requirements for the certificates themselves.
RFC 3161: The Internet Engineering Task Force (IETF) standard defining the Time-Stamp Protocol (TSP). RFC 3161 timestamps are what signtool requests from timestamp servers with the /tr flag. An RFC 3161 timestamp token contains a hash of the data being timestamped, the signing time, and the TSA’s digital signature over both. This cryptographic structure makes the timestamp unforgeable and verifiable without trusting the original signer.
This glossary reflects terminology as of May 2026. Terms whose definitions changed due to CA/B Forum policy are marked with their effective dates in the definition. Older sources and competitor articles may define EKU requirements, hardware storage requirements, and SmartScreen behavior differently if they were written before June 2023 or August 2024.
Gloria Bradford is a renowned expert in the field of encryption, widely recognized for her pioneering work in safeguarding digital information and communication. With a career spanning over two decades, she has played a pivotal role in shaping the landscape of cybersecurity and data protection.
Throughout her illustrious career, Gloria has occupied key roles in both private industry and government agencies. Her expertise has been instrumental in developing state-of-the-art encryption and code signing technologies that have fortified digital fortresses against the relentless tide of cyber threats.