Code signing certificates and TLS/SSL certificates are both X.509 certificates issued by Certificate Authorities using the same public key infrastructure. They share the same format, the same underlying cryptography, and often the same issuing CAs. Despite this common foundation, they serve fundamentally different purposes and have meaningfully different technical configurations, validation requirements, key storage obligations, and validity periods.
Understanding the differences matters when you are deciding what to buy, configuring your security infrastructure, or troubleshooting why a certificate is not working for a specific purpose. Using an SSL certificate where a code signing certificate is required, or vice versa, does not work because the certificates are configured differently at the technical level.
What They Share: The X.509 Foundation
Both certificate types are X.509 v3 digital certificates. They contain a public key, the subject’s identity information, validity period, issuer information, and extensions that describe the certificate’s permitted uses. Both are issued by CAs that chain to trusted root certificates in major trust stores. Both use RSA or ECDSA key pairs. Both can be inspected with the same tools (certutil, OpenSSL, certificate viewers).
The same CAs issue both types. DigiCert, Sectigo, SSL.com, GlobalSign, and other major CAs offer both TLS/SSL certificates and code signing certificates. The issuance process, the CA’s infrastructure, and the certificate format are the same. What differs is the specific configuration of each certificate, driven by its intended purpose.
The Defining Difference: Extended Key Usage
The most fundamental technical difference between TLS/SSL certificates and code signing certificates is in the Extended Key Usage (EKU) extension. EKU specifies what cryptographic operations the certificate’s key pair is authorized to perform. It is the field that makes a certificate suitable for one purpose and unsuitable for another.
TLS/SSL server certificates contain the serverAuthentication OID (1.3.6.1.5.5.7.3.1) in their EKU extension. When a TLS client connects to a server, it checks that the server’s certificate has the serverAuthentication EKU before accepting it as a valid server certificate.
Code signing certificates contain the codeSigning OID (1.3.6.1.5.5.7.3.3) in their EKU extension. When Windows, macOS, or other platforms verify an Authenticode or similar signature, they check that the signing certificate has the codeSigning EKU. A certificate without this EKU cannot produce a valid code signature.
These EKUs are exclusive in normal use: a standard TLS certificate cannot sign code, and a standard code signing certificate cannot serve as a TLS server certificate. You need separate certificates for each purpose, even from the same CA.
The EKU restriction is why copy-pasting a certificate from one use to another does not work. A developer who tries to use their website’s SSL certificate to sign their application will find that signtool or other signing tools reject the certificate because it lacks the codeSigning EKU. Conversely, a web server configured with a code signing certificate will fail TLS handshakes because the certificate lacks the serverAuthentication EKU.
What Each Certificate Protects
The purpose difference follows from the EKU difference and explains why the certificates have different configurations.
A TLS/SSL certificate authenticates a server to a connecting client and enables encrypted communication. When your browser connects to https://yoursite.com, the server presents its TLS certificate. Your browser verifies the certificate is from a trusted CA, that the domain name matches, and that the serverAuthentication EKU is present. This establishes that you are connected to the authentic server and enables TLS encryption for the session. The certificate protects the channel: data in transit between client and server.
A code signing certificate authenticates a software publisher to an operating system and its users. When a user downloads and runs Setup.exe, Windows checks the Authenticode signature on the file. Windows verifies the signing certificate chains to a trusted root, that the codeSigning EKU is present, and optionally that the certificate is from a CA trusted for code signing by Microsoft’s program. This establishes that the file was produced by a verified publisher and has not been modified since signing. The certificate protects the artifact: the software file itself, regardless of how it was obtained or what channel delivered it.
Side-by-Side Comparison
| Property | TLS/SSL Certificate | Code Signing Certificate |
| Primary purpose | Authenticate server identity; enable encrypted communication | Authenticate software publisher; verify file integrity |
| What it protects | The communication channel (data in transit) | The software artifact (the file itself) |
| Extended Key Usage (EKU) | serverAuthentication (1.3.6.1.5.5.7.3.1) | codeSigning (1.3.6.1.5.5.7.3.3) |
| Validation levels available | DV, OV, EV | OV equivalent and EV only; DV is not available |
| Key identity field | Subject Alternative Name (SAN) with DNS names | Subject Organization Name and related organizational fields |
| Private key storage requirement | No mandatory hardware requirement (recommended but optional) | FIPS 140-2 Level 2 hardware required (since June 2023 for all) |
| Maximum validity period (2026) | 200 days (reduced from 398 days in March 2026) | 460 days (reduced from 39 months in March 2026) |
| Timestamp mechanism | OCSP stapling for revocation checking; no content timestamp | RFC 3161 timestamp protects signature validity after certificate expiry |
| Primary governance body | CA/B Forum TLS Baseline Requirements; browser root programs | CA/B Forum Code Signing Certificate Requirements; Microsoft Trusted Root Program |
| Trust enforced by | Browsers (Chrome, Firefox, Safari) and OS TLS stacks | Windows Authenticode, macOS Gatekeeper, app store policies |
| Revocation checking | OCSP, CRL, CRLSets, CRLite | OCSP, CRL (less automated; client-dependent) |
| What happens at expiry | HTTPS connections fail with certificate error | Signatures on timestamped files remain valid; new signing fails |
Validation Levels: Why DV Doesn’t Exist for Code Signing
TLS/SSL certificates are available at three validation levels: DV (Domain Validated), OV (Organization Validated), and EV (Extended Validated). Let’s Encrypt, ZeroSSL, and other free CAs issue DV certificates that confirm only domain control, with no identity verification of the organization or individual behind the domain. DV certificates are widely used for websites.
Code signing certificates do not have a DV level. The minimum validation for a code signing certificate is equivalent to OV: the CA verifies the organization’s legal existence, operational address, and phone number before issuing. This is a CA/B Forum requirement, not a market choice. The reason: code signing is about establishing publisher identity. A certificate that only verifies domain control says nothing about who the publisher is. The publisher name shown in the UAC dialog and the Authenticode signature comes from the verified organizational identity in the certificate.
Individual developers without a registered organization can obtain Individual Validation (IV) code signing certificates, where the CA verifies the individual’s identity. This is the code signing equivalent of DV in terms of price and simplicity, but it still involves identity verification.
Private Key Storage: Why Code Signing Is Stricter
TLS/SSL private keys are typically stored on the web server that presents the certificate. In high-security deployments, hardware security modules (HSMs) are used, but there is no industry-wide mandatory hardware requirement for TLS private keys. A TLS private key can be stored as a .pem file on a server.
Code signing private keys are required by the CA/B Forum to be stored on FIPS 140-2 Level 2 compliant hardware. This requirement has applied to EV code signing certificates since the standard was established, and was extended to all code signing certificates in June 2023. The hardware requirement means code signing private keys must be on USB hardware tokens or in cloud HSMs, not exportable as files.
The stricter key storage requirement for code signing reflects the different threat model. A compromised TLS private key enables an attacker to impersonate the specific server: damaging but limited in scope. A compromised code signing private key enables an attacker to sign malware as the legitimate publisher and potentially distribute it to every user who installs that publisher’s software: a much broader attack surface.
Validity Periods: Diverging Timelines
Both TLS/SSL and code signing certificate validity periods have been reduced by the CA/B Forum, but have followed different timelines and reached different current maximums.
TLS/SSL certificates were reduced from 825 days to 398 days in September 2020, and most recently to 200 days in March 2026 per CA/B Forum Ballot SC-081. Further reductions are scheduled: 100 days by March 2027 and 47 days by March 2029. The TLS certificate lifecycle is moving toward very short validity periods.
Code signing certificates were reduced from 39 months (approximately 3 years) to 460 days (approximately 15 months) in March 2026 per CA/B Forum Ballot CSC-31. The code signing reduction curve lags TLS by several years. Current code signing certificate validity at 460 days is roughly comparable to where TLS was in 2020.
The divergence exists partly because code signing certificates interact with long-lived software artifacts differently than TLS certificates interact with connections. A TLS certificate that expires means the website stops serving HTTPS. A code signing certificate that expires means new binaries cannot be signed, but previously signed and timestamped binaries remain verifiable. The shorter TLS validity period creates less operational disruption than the same period would for code signing.
The Timestamp Difference: Why Code Signing Has a Separate Mechanism
TLS/SSL certificates and code signing certificates handle the post-expiry question differently.
For TLS certificates: when a certificate expires, the TLS connection fails. The certificate must be renewed for HTTPS to continue working. OCSP stapling provides current revocation status during the certificate’s validity period, but there is no mechanism to preserve a TLS certificate’s authority after expiry. This is acceptable because TLS protects live connections; there is no concept of a TLS connection made six months ago that needs to remain trusted today.
For code signing certificates: software artifacts persist. A setup installer signed in 2020 may be installed by a user in 2026. If the signing certificate expires, should the 2020 installer lose its verified publisher status? The answer is no, if the signature included a timestamp. The RFC 3161 timestamp mechanism is specific to code signing (and related document signing contexts): it records the time of signing cryptographically, allowing verification systems to confirm the certificate was valid at signing time. Timestamped signatures remain valid after certificate expiry; un-timestamped signatures do not.
TLS certificates have no equivalent mechanism because they do not need one. Code signing timestamps exist because software artifacts outlive the certificates used to sign them.
Frequently Asked Questions
Can I use my website’s SSL certificate to sign my software?
No. A standard TLS/SSL certificate contains the serverAuthentication Extended Key Usage OID. Code signing tools like signtool.exe check for the codeSigning EKU and reject certificates that lack it. You need a separate certificate specifically issued for code signing. Both certificates can be purchased from the same CA but are distinct products with different configurations.
Can I use my code signing certificate for my website?
No. A standard code signing certificate contains the codeSigning EKU, not serverAuthentication. TLS clients check for serverAuthentication and will reject a code signing certificate as a server certificate. Your web server’s TLS handshake will fail. You need separate SSL/TLS certificates for website HTTPS.
Why does code signing require hardware storage but SSL doesn’t?
The CA/B Forum requires hardware storage for code signing private keys because a compromised code signing key enables broad attacks: an attacker can sign malware as the legitimate publisher and potentially affect every user who installs that publisher’s software. TLS private key compromise is more limited in scope (enabling impersonation of a specific server). The higher consequence of code signing key compromise justifies stricter storage requirements.
Why are code signing certificates more expensive than SSL certificates?
Code signing certificates require at minimum OV (organizational) identity verification, which involves manual review by the CA’s validation team. DV SSL certificates, which require only automated domain control verification, can be issued instantly for free (Let’s Encrypt) or at low cost. Code signing has no DV equivalent, so all code signing certificates carry the overhead of organizational identity verification. Additionally, EV code signing certificates require more extensive validation. Hardware token delivery also adds to the cost compared to SSL certificates delivered as downloadable files.
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.