Code Signing Certificate (Software signing certificate)

A code signing certificate binds a software publisher's identity to a key pair and carries the codeSigning extended key usage (OID 1.3.6.1.5.5.7.3.3). The publisher signs executables, installers, drivers, scripts or packages with the private key; the operating system or runtime verifies the signature against trusted roots before running or installing the code. Publicly trusted code signing certificates for Windows Authenticode are issued under the CA/Browser Forum's Code Signing Baseline Requirements, a separate rulebook from the TLS Baseline Requirements, while macOS and iOS rely on certificates issued by Apple to registered developers.

Why it matters

A valid signature tells users and security tools who published the file and that it has not been modified since signing; unsigned installers are more likely to trigger operating system warnings. Because stolen signing keys have been used to sign malware, current requirements oblige CAs to ensure that subscriber keys are generated and stored in hardware, such as a token, an HSM or a cloud signing service, rather than in an exportable file. Signing with a trusted timestamp (RFC 3161) lets the signature remain valid after the certificate expires.

Example

signtool sign /fd SHA256 /tr http://timestamp.example.com /td SHA256 /a setup.exe
signtool verify /pa /v setup.exe

Common misconceptions

• My TLS certificate can sign code. TLS certificates lack the codeSigning EKU, and browser root programs now require TLS hierarchies to be dedicated to server authentication.
• Signed software is safe. A signature identifies the publisher and proves integrity; it says nothing about whether the code is benign.
• Signatures break when the certificate expires. Not if a timestamp was applied at signing time; untimestamped signatures do fail after expiry.