Code Signing Certificates

A code signing certificate is an X.509 certificate specifically issued for signing software. It contains the Extended Key Usage extension codeSigning (OID 1.3.6.1.5.5.7.3.3), which restricts it to signing code — it cannot be used for TLS server authentication or other purposes. The certificate binds the publisher’s identity (organization name, verified by the CA) to a public key. The corresponding private key signs software artifacts, and anyone with the certificate can verify those signatures.

Why it matters

• Platform requirements — Windows kernel-mode drivers require EV code signing certificates. macOS requires Developer ID certificates from Apple. Android requires APK signing. Without the right certificate type, your software can’t run on these platforms.
• SmartScreen reputation — on Windows, EV code signing certificates get immediate reputation (no “Unknown Publisher” warning). Standard certificates must build reputation over time through download volume.
• Hardware key mandate — since June 2023 (CA/Browser Forum requirement), all code signing certificate private keys must be stored on hardware tokens or HSMs. Software-based keys are no longer allowed for new certificates.
• Identity verification — CAs verify the publisher’s organization identity before issuing code signing certificates. This creates accountability — if malware is signed, the publisher is identifiable and the certificate is revocable.
• Revocation impact — revoking a code signing certificate invalidates all software signed with it (unless timestamped). This makes revocation a serious decision with broad impact.

How it works

Certificate types:

• Standard (OV) Code Signing — organization validated. CA verifies the organization exists and the requester is authorized. Private key on hardware token (since 2023). SmartScreen reputation builds over time.
• Extended Validation (EV) Code Signing — stricter identity verification (physical address, legal existence, authorized signer). Private key always on hardware (HSM or token). Immediate SmartScreen reputation. Required for Windows kernel-mode drivers.

Issuance process:

1. Generate key pair on hardware token (YubiKey, SafeNet token) or HSM
2. Create CSR from the hardware-stored key
3. Submit to CA with organization documentation (business registration, government ID, phone verification)
4. CA validates identity (1-5 business days for OV, 1-2 weeks for EV)
5. Certificate issued and downloaded (private key remains on hardware)
6. Configure signing tools to use the hardware token

Key storage requirements (post-June 2023):

• FIPS 140-2 Level 2 or higher (hardware crypto module)
• Common Criteria EAL 4+ (smart card or token)
• Cloud-based HSM (AWS CloudHSM, Azure Dedicated HSM, Google Cloud HSM)
• CA-provided token (many CAs ship pre-configured SafeNet/YubiKey tokens)

In real systems

Signing with hardware token (SafeNet/YubiKey):

# Windows signtool with hardware token
signtool sign /fd SHA256 /tr http://timestamp.digicert.com /td SHA256 ^
  /sha1 "THUMBPRINT_OF_CERT_ON_TOKEN" MyApp.exe
# Token PIN prompt appears — requires physical presence

# With YubiKey (PIV slot)
signtool sign /fd SHA256 /tr http://timestamp.digicert.com /td SHA256 ^
  /csp "Microsoft Smart Card Key Storage Provider" ^
  /kc "PIV_SLOT_9c" MyApp.exe

Cloud HSM signing (AWS CloudHSM + signtool):

# Certificate references key in CloudHSM via KSP
# Key never leaves the HSM — signing happens remotely
signtool sign /fd SHA256 /tr http://timestamp.digicert.com /td SHA256 ^
  /csp "Cavium Key Storage Provider" ^
  /kc "label=code-signing-key" MyApp.exe

Checking a code signing certificate:

# View certificate details
openssl x509 -in codesign.pem -noout -text | grep -A2 "Extended Key Usage"
# X509v3 Extended Key Usage:
#   Code Signing

# Verify certificate chain
openssl verify -CAfile ca-chain.pem codesign.pem

Certificate lifecycle:

Typical code signing certificate:
- Validity: 1-3 years
- Key algorithm: RSA 3072+ or ECDSA P-256
- Must be timestamped at signing (RFC 3161)
- Revocation: CRL + OCSP
- Renewal: new key pair required (can't reuse old key on new cert)

Where it breaks

Hardware token lost or damaged — the code signing private key is on a USB token. The token is lost, stolen, or physically damaged. The key cannot be recovered (that’s the security feature). All future signing requires a new certificate. Previously signed software remains valid (if timestamped), but new releases can’t be signed until a replacement certificate is issued (1-5 days for OV, 1-2 weeks for EV). Keep a backup token or use an HSM with key backup capability.

Certificate revoked, timestamps missing — a code signing certificate is revoked (key compromise suspected). All software signed with that certificate without timestamps is now flagged as untrusted — even software signed years ago that was perfectly legitimate. With timestamps, the signature remains valid because it proves signing occurred before revocation. One missing timestamp can invalidate years of software releases.

EV certificate on shared build server — the EV code signing token is plugged into a shared CI/CD server for automated signing. Multiple developers have access to the server. The token’s PIN is stored in a CI variable. This defeats the purpose of EV (which assumes controlled access to the signing key). An insider or compromised CI pipeline can sign anything. EV signing should require explicit approval workflows, not automated access.

Operational insight

The June 2023 hardware key mandate fundamentally changed code signing operations. Before, developers could sign locally with a software-based PFX file — simple but insecure. Now, every signing operation requires hardware interaction (token PIN, HSM API call). This breaks naive CI/CD pipelines that assumed the signing key was just a file. The migration path: move signing keys to cloud HSMs (AWS CloudHSM, Azure Key Vault HSM, Google Cloud HSM) accessible via API, and configure CI/CD to call the HSM for signing operations. This maintains automation while satisfying the hardware requirement. Local developer signing (for testing) should use a separate, non-production certificate.

Related topics

• What is Code Signing
• Code Signing in CI/CD Pipelines
• What are Hardware Security Modules
• What is PKCS
• Digital Signatures