Check if a certificate has code signing capabilities
Results
Subject
Issuer
Key Algorithm
Validity
years
About Code Signing Certificates
A code signing certificate is a digital certificate used by software developers to sign executables, scripts, and installers to verify the software's authenticity and integrity. Our Code Signing Certificate Checker analyzes a certificate's Extended Key Usage (EKU) extension to determine if it has the code signing purpose set, which is essential for distributing trusted software on Windows, macOS, and other platforms.
How to Use
Enter the domain name of the server hosting the certificate to check.
Click Check to fetch and analyze the certificate's EKU extension.
Review whether code signing is supported based on the EKU analysis.
Examine additional certificate details like subject, issuer, and key algorithm.
Use Cases
Software Distribution: Verify that your signing certificate has the correct EKU before distributing signed software.
Vendor Verification: Check third-party certificates to confirm their code signing capabilities.
Certificate Inventory: Audit certificates in your organization to identify which support code signing.
CI/CD Integration: Validate code signing certificates before automated build and release pipelines.
Frequently Asked Questions
The EKU extension specifies the intended purposes of a certificate. Common values include Server Authentication, Client Authentication, and Code Signing. A certificate must have the Code Signing EKU (1.3.6.1.5.5.7.3.3) to be valid for signing software.
Generally no. TLS (server) certificates and code signing certificates serve different purposes and have different EKU extensions. A standard TLS certificate cannot be used to sign code, and vice versa. Some cross-certificates exist but are rare and not recommended for security reasons.
Code signing assures users that software has not been tampered with and comes from a verified publisher. Operating systems like Windows, macOS, and mobile platforms require valid code signatures to run applications without security warnings. It also helps maintain the integrity of software supply chains.
Because extended key usage is specific. A certificate issued for server authentication is not valid for code signing, and platforms enforce that — Windows will refuse an Authenticode signature from a certificate without the code-signing usage, and macOS behaves the same way. The two certificate types come from the same authorities and the same CSR process, so requesting one for each purpose is routine rather than a special arrangement.
It lets the signature outlive the certificate. Without a timestamp, an Authenticode signature becomes invalid the day its certificate expires, and software already shipped to users stops verifying — a problem that gets worse with every year the software is in use. A trusted timestamp countersign proves the signature existed while the certificate was valid, so expiry stops mattering for binaries already released.
As long as your authority allows and as your platform requires, typically three years. The logic is inverted from TLS: a long lifetime is desirable because re-signing and redistributing old releases is impractical, and revocation of a compromised key is handled by revocation of the certificate plus platform trust lists rather than by short lifetimes. Restrict the private key carefully instead — that is the actual control worth investing in.
Treat it as the most sensitive credential you hold, because it can sign anything that appears to come from you. Hardware-backed storage or an HSM is the meaningful control, with the key non-exportable. Beyond storage, restrict what can use it: signing should go through a build system that requires approval rather than a workstation where any process can call the signing tool, and access should be logged and reviewed.
Not remotely. It means the signature is genuine and the software has not been altered since signing — a property called integrity, and an important one. It says nothing about whether the code is benign, well written or free of vulnerabilities. Malware is routinely signed, because the attacker holds a valid certificate too. Signing proves origin and integrity, never quality.
What the Checker Inspects
Code signing certificates differ from TLS ones in what they promise and how they are validated, so they need their own checks. This page examines the certificate against the properties that matter for signed code.
1Confirm the extended key usage is code signing. A certificate issued for TLS is not valid for signing code, and a certificate without the code-signing usage cannot be used by an installer or package manager. Reusing the wrong certificate is the usual cause of a rejected signature.
2Read the validity dates, which for code signing are often long — three years or more — because revocation is impractical for software already in the wild. A long lifetime is normal here and not by itself a concern.
3Report subject, issuer and serial so the certificate can be identified and matched against your build system's records. Timestamping deserves attention separately: a signature countersigned by a trusted timestamp authority stays valid after the certificate expires, which is what makes long-lived code signing workable.
Inspecting the certificate tells you what it is, not whether a given binary was signed with it. Confirming an actual signature means verifying the artefact itself against the certificate and its chain.
Tips & Best Practices
•Use code signing certificates to establish trust with users
•Timestamp signed code to ensure validity after certificate expiry
•Protect private keys with hardware security modules (HSMs)
•Monitor code signing certificate usage for unauthorized signing
Technical Details
Certificate: Code signing certificate validation and analysis Signature: Digital signature verification and validation Timestamp: Timestamp server support and validation Output: Code signing status with trust and validity information
