Code signing

Code signing certificates verify the identity of the software publisher and confirm that code has not been altered after signing. Without them, operating systems like Windows and macOS display security warnings that stop most users from proceeding with installation. This guide covers how code signing works, certificate types, compliance requirements, and practical selection criteria for Canadian developers and organizations.

What a Code Signing Certificate Actually Does

A code signing certificate binds a cryptographic signature to an executable, script, or software package. When a user downloads and runs the file, the operating system checks the signature against a trusted Certificate Authority (CA) chain.

The signature confirms two things:

• The code came from the identified publisher
• The code has not been modified since it was signed

If either check fails, Windows SmartScreen, macOS Gatekeeper, or mobile app stores will block execution or display a high-friction warning. Studies by Google and Microsoft consistently show that roughly 70–80% of users abandon installation when they see an "Unknown Publisher" warning.

How the Signing Process Works

The technical flow involves asymmetric cryptography and a trusted third party:

The private key must never leave the signing environment. This is why hardware security modules (HSMs) and secure tokens are now required for most certificate types.

OV vs. EV Code Signing: Key Differences

There are two main validation levels. The right choice depends on your distribution channel and target audience.

Organization Validation (OV)

• CA verifies legal business existence via public records or direct contact
• Certificate displays publisher name in software properties
• Validation typically takes 1–3 business days
• Windows SmartScreen reputation builds over time based on download volume
• Suitable for internal tools, developer utilities, and software with an existing user base

Extended Validation (EV)

• CA performs enhanced identity verification: legal, physical, and operational checks
• Private key must be stored on FIPS 140-2 Level 2 or higher HSM or hardware token
• Immediate SmartScreen reputation — no "warm-up" period required
• Required by Microsoft for kernel-mode drivers on Windows 10 and later
• Required for signing drivers submitted to the Windows Hardware Dev Center portal
• Validation takes 3–7 business days, sometimes longer for new organizations

Platforms and File Types Supported

Code signing certificates issued by publicly trusted CAs work across a wide range of formats:

• Windows: .exe, .dll, .msi, .cab, .sys, .ps1 (PowerShell), .appx, .msix
• macOS: Applications, .pkg installers, kernel extensions (requires Apple notarization in addition)
• Java: .jar files using jarsigner
• Adobe: PDF documents with document signing certificates (separate product)
• Linux: RPM and DEB packages (via GPG, though some enterprise pipelines accept X.509)
• Mobile: Android APKs use separate Google Play signing; iOS requires Apple Developer certificates

Important: Code signing certificates from public CAs do not replace Apple Developer Program certificates. macOS signing and notarization require both a valid Apple Developer ID and Gatekeeper notarization through Apple's service.

Compliance and Regulatory Context in Canada

Canadian organizations operating in fintech, healthcare, or critical infrastructure face specific requirements around software integrity.

PIPEDA and Bill C-27 (Digital Charter Implementation Act): Software that processes personal data must implement reasonable security measures. Using signed, verified code in production environments is considered a baseline control.

PCI DSS v4.0: Requirement 6.3 mandates that all system components are protected from known vulnerabilities. Deploying unsigned or unverified software in a cardholder data environment is a clear gap during audits.

OSFI B-13 Guideline: The Office of the Superintendent of Financial Institutions technology and cyber risk guideline, effective since 2023, requires federally regulated financial institutions to maintain integrity controls over software deployed in production. Code signing directly supports this control objective.

Export controls (ITAR/EAR): If your software is subject to U.S. export control regulations and you're signing for distribution, your signing infrastructure must not expose the private key to jurisdictions outside the authorized scope.

Private Key Storage: Why It Matters More Than the Certificate Itself

The certificate is only as secure as the private key. Compromise of the private key allows an attacker to sign malware under your identity — a technique seen in supply chain attacks like those affecting SolarWinds and 3CX.

Recommended storage options by risk level:

Since June 2023, the CA/Browser Forum Baseline Requirements mandate that all private keys for code signing certificates be stored on hardware meeting FIPS 140-2 Level 2 or equivalent. CAs now ship EV certificates on pre-configured hardware tokens or require proof of compliant HSM use.

Integrating Code Signing into CI/CD Pipelines

Manual signing before release is error-prone and creates bottlenecks. Most mature DevOps teams integrate signing directly into their build pipelines.

Typical integration points:

• GitHub Actions / GitLab CI: Use signing action steps that pull credentials from secrets management (e.g., HashiCorp Vault, AWS Secrets Manager) and invoke signtool.exe or osslsigncode
• Azure DevOps: Native support for code signing tasks via the marketplace; private keys stored in Azure Key Vault
• Jenkins: Signing step in post-build phase using signtool or jarsigner with credentials stored in Jenkins credential store (not recommended for EV — token must be physically accessible)

Key rule: Never embed the PFX file or password directly in a pipeline configuration file or repository. Rotate signing certificates if any exposure is suspected.

Timestamping: Why You Must Always Use It

Timestamping is separate from signing, but it is not optional in practice.

When you sign code without a timestamp, the signature is only valid while the signing certificate is valid. The moment the certificate expires — typically in 1–3 years — all previously signed binaries show as having an expired or invalid signature.

When you include an RFC 3161 timestamp from a trusted Timestamping Authority (TSA), the timestamp proves the code was signed while the certificate was valid. The signature remains trustworthy after certificate expiry.

Every major CA operates a free TSA endpoint. Always pass the -t or -tr flag in your signing command:

signtool sign /fd SHA256 /tr http://timestamp.example-ca.com /td SHA256 /f cert.pfx yourapp.exe

Skipping this step is one of the most common code signing mistakes and causes significant operational problems when certificates expire.

Certificate Lifespan and Renewal Planning

As of June 2023, the maximum validity period for code signing certificates is 3 years. For organizations running long-term software products, this creates a renewal cycle that needs to be tracked.

Practical renewal checklist:

• Set calendar reminders 90, 60, and 30 days before expiry
• Keep signed installers from older versions timestamped and archived — they remain valid even after expiry
• Do not re-sign old binaries with a new certificate unless you have a specific reason (re-signing changes the signature and can break verification chains)
• For EV certificates on hardware tokens, factor in CA delivery time — tokens arrive by mail, which adds 5–10 business days

Choosing a CA for a Canadian Organization

CAs recognized by the CA/Browser Forum are cross-platform trusted by default. For Canadian organizations, consider:

• Jurisdiction: Some CAs offer Canadian legal entity verification more efficiently because they have established processes with NUANS, provincial registrars, and CRA databases
• Support timezone: If you need urgent reissuance, a CA with support coverage in EST/PST matters
• Integration: If you already use a CA for TLS certificates, bundling code signing can simplify management and may reduce cost
• Audit logs: For regulated organizations, CAs that provide detailed signing logs and key usage reports support compliance reporting under OSFI B-13 and PCI DSS

Price alone is a poor selection criterion. A certificate that creates friction during validation or lacks responsive revocation handling creates more operational cost than it saves in licensing fees.