Code Signing Certificates

This page provides background on code-signing certificates: what they are, which certificate types Signotaur accepts, the public-key algorithms and key sizes supported, and where certificates can live on the server.

For the administrative interface used to register and manage certificates, see Admin - Certificates.

About Code-Signing Certificates

A code-signing certificate is an X.509 certificate issued for the purpose of digitally signing executable files, installers, scripts, and other software artifacts. A valid signature allows Windows (and other platforms) to verify the publisher of a file and confirm that its contents have not been altered since it was signed. For Windows Authenticode in particular, this drives behaviour such as UAC prompts, SmartScreen reputation, driver loading, and enterprise application allow-listing.

Signotaur accepts code-signing certificates from any issuer, provided the certificate:

  • Has an Enhanced Key Usage (EKU) extension that includes Code Signing (1.3.6.1.5.5.7.3.3).
  • Has an accessible private key (either installed on the server, loaded via PKCS#11, or contained in an imported PFX).
  • Is within its validity period.

Key Algorithms and Sizes

The table below lists the public-key algorithms Signotaur recognises in code-signing certificates. Only RSA and ECDSA certificates are supported.

Algorithm Supported Key Sizes / Curves Notes
RSA 2048, 3072, 4096 Recommended for code signing. Required for dual signing (--sha1), ClickOnce/VSTO manifest signing, VSIX/OPC package signing, NuGet package signing, and RDP file signing. See minimum key size guidance below.
ECDSA NIST P-256, P-384, P-521 Signs and validates on Windows 8 and later. See recommendation below.
DSA — Not supported. DSA was withdrawn by NIST in FIPS 186-5 (2023) and is no longer validated by modern code-signing runtimes. Signotaur will reject a DSA certificate at registration time.
ECDH (Elliptic Curve Diffie-Hellman) — Not supported. ECDH is a key-agreement algorithm, not a signature algorithm. Signotaur will reject an ECDH certificate at registration time.

Supported file digest (hash) algorithms include SHA-256, SHA-384, and SHA-512. SHA-1 is supported only as a secondary algorithm via the --sha1 dual-signing option on the Sign command, which exists solely for legacy Windows compatibility.

Effective 1 June 2021, the CA/Browser Forum Baseline Requirements for Code Signing Certificates require RSA keys of 3072 bits or larger for publicly-trusted code signing certificates. Microsoft's Trusted Root Program Requirements align with the same 3072-bit minimum. No public CA will issue a code signing certificate with a 2048-bit RSA key today.

Signotaur still accepts 2048-bit RSA certificates at registration, which remains useful for:

  • Internal or self-signed certificates used for in-house signing.
  • Existing 2048-bit certificates issued before the 2021 requirement change that are still within their validity period.

When purchasing or renewing a code signing certificate, choose RSA 3072 or larger. 3072 is the recommended choice — it meets the CA/Browser Forum minimum and provides the NIST-equivalent 128-bit security level (matching AES-128) without the extra overhead of 4096. 4096 is also fine if your policy requires it. For general (non-code-signing) RSA use such as TLS, 2048 remains acceptable per NIST SP 800-57 through approximately 2030.

Where Certificates Can Live

Signotaur supports three sources for code-signing certificates, each accessible via its own tab in the Add New Certificate dialog:

  • Hardware: Loaded from a server hardware token or HSM via PKCS#11, a cryptographic token interface standard. The private key never leaves the token. If you're choosing which token or HSM to buy, see Hardware Token & HSM Selection.
  • File: Uploaded PFX (Personal Information Exchange) files containing a certificate and its private key. The private key is encrypted at rest on the server.
  • Store: Certificates stored in the Windows Certificate Store on the server machine.

RSA Is Recommended Over ECC/ECDSA

When choosing a new code-signing certificate, we recommend RSA 3072-bit or larger rather than ECC/ECDSA. ECDSA code-signing certificates will sign and validate on Windows 8 and later for the normal UAC / WinVerifyTrust case, but Microsoft's Trusted Root Program Requirements (section 3.B) list ECC/ECDSA as "Not Supported" for code signing, and in practice RSA offers broader compatibility:

  • Legacy Windows compatibility. Windows versions before Windows 8 have no ECDSA Authenticode support, so ECDSA signatures are not validated on Windows XP, Vista, or Windows 7 RTM regardless of hash algorithm. RSA signatures can still reach those systems if needed.
  • Dual signing support. The --sha1 dual-signing option on the Sign command requires an RSA certificate. Attempting to dual-sign with an ECDSA certificate will produce an E_INVALIDARG error when the secondary signature is appended.
  • ClickOnce, VSIX, NuGet, and RDP signing. ClickOnce/VSTO manifest signing, VSIX/OPC package signing, NuGet package signing, and RDP file signing all require an RSA certificate. ECDSA certificates cannot be used with these signers — VSIX explicitly (Microsoft's VSIXInstaller.exe rejects ECDSA signatures), and RDP by practical compatibility (mstsc has no documented or validated ECDSA support).
  • Tooling compatibility. Some antivirus engines, Windows SmartScreen reputation, and older signature parsers handle RSA signatures more consistently than ECDSA ones.

If you already have an ECDSA certificate, it remains perfectly usable for standard SHA-256 signing on modern Windows. The recommendation above applies when purchasing or renewing a certificate.

References and Standards

This page cites several external bodies and documents. Brief descriptions are below for readers unfamiliar with the terms.

  • CA/Browser Forum — An industry consortium of certificate authorities (CAs), browser vendors, and other PKI stakeholders. It publishes the Baseline Requirements, the minimum technical and operational standards that publicly-trusted CAs must follow. The Baseline Requirements for Code Signing Certificates set the rules (including minimum key sizes) for any code signing certificate that chains to a root in a major OS or browser trust store.
  • Microsoft Trusted Root Program — Microsoft's program governing which root CA certificates are shipped with and trusted by Windows. Its Program Requirements dictate what algorithms, key sizes, and EKUs are acceptable for certificates that must validate under Windows, and code signing certificates are verified against these rules by SmartScreen, Authenticode, and related components.
  • NIST SP 800-57 — NIST Special Publication 800-57 Part 1 — Recommendation for Key Management. A US National Institute of Standards and Technology document that defines cryptographic key strength equivalences (e.g. RSA 2048 ≈ 112-bit security; RSA 3072 ≈ 128-bit security) and recommends timelines for deprecating weaker keys. It is the reference most commonly used by US federal agencies and commercial PKI guidance for "how long is this key size good for".
  • X.509 — The ITU-T standard that defines the certificate format used by virtually all TLS, S/MIME, and code signing certificates. When this page refers to an "X.509 certificate" it simply means a certificate in that standard format.
  • Enhanced Key Usage (EKU) — An X.509 certificate extension that restricts the purposes for which the certificate may be used. Code Signing (OID 1.3.6.1.5.5.7.3.3) is the EKU that marks a certificate as valid for signing software.
  • Authenticode — Microsoft's code signing technology for Windows executables, installers, DLLs, and drivers. It is implemented by the WinVerifyTrust Windows API and drives UAC prompts, SmartScreen warnings, and driver-loading decisions.
  • PKCS#11 — A cryptographic token interface standard (originally by RSA Laboratories, now maintained by OASIS). It is the API used to communicate with hardware security modules and USB tokens such as YubiKey and SafeNet so that private keys never leave the device.
  • PFX (Personal Information Exchange) — The file format (also called PKCS#12) used to bundle a certificate together with its private key in a single, password-protected file, typically with a .pfx or .p12 extension.