What Is a Code Signing Certificate?
A code signing certificate is a digital certificate a software publisher uses to digitally sign executables, installers, scripts, drivers, browser extensions and other software files before distributing them. The signature attached to the file lets anyone running it, and the operating system itself, check two specific things: who published the file, and whether it has been altered since the moment it was signed.
That is also the limit of what code signing proves. A valid signature confirms publisher identity and file integrity — it does not certify that the software is free of bugs, well written, or otherwise "safe" to run. A publisher can sign harmful code with a legitimately issued certificate; the signature only tells you who is responsible for the file and that nobody tampered with it afterward, which is still useful for accountability and for catching corruption or tampering in transit.
Code signing sits alongside other specialized certificate types in a certificate authority's catalog. Where an SSL/TLS certificate secures a connection between a browser and a server, and an S/MIME certificate signs and encrypts email, a code signing certificate protects software distribution instead.
How Code Signing and Verification Work
Signing software revolves around the publisher's private key, and walking through the mechanics helps explain what the certificate actually confirms:
- Hashing. The signing tool calculates a cryptographic hash — a fixed-length fingerprint — of the file being signed. Changing even one byte of the file produces a completely different hash.
- Signing. That hash is encrypted with the certificate's private key, producing a digital signature. The signature, the public certificate and the issuing chain are attached to, or embedded in, the file.
- Verification. When the file runs, or is inspected, the verifying system recalculates the hash, decrypts the signature with the certificate's public key, and compares the two. It also checks that the certificate chains up to a trusted root certificate authority. If the hash matches and the chain is trusted, both the integrity check and the identity check pass.
- Timestamping. A trusted timestamping service records the exact time of signing as part of the signature. This matters because certificates expire, but a properly timestamped signature keeps verifying as genuinely signed during the certificate's validity period even after the certificate itself has since expired — without timestamping, every signed file would stop verifying the day its signing certificate expired.
None of these steps depend on scanning the file's actual behavior; they only confirm who signed it and that it has not changed since.
OV vs EV Code Signing: How Much Vetting Differs
Publicly trusted code signing certificates come in two vetting levels, similar in spirit to the difference between OV and EV SSL certificates:
| Type | Organization vetting | Typical fit |
|---|---|---|
| OV code signing | Confirms the organization's legal existence and that it controls the certificate request | Independent developers and companies signing general-purpose software |
| EV code signing | A more thorough review of the organization, comparable to how EV vetting works for SSL | Vendors who want the deepest available identity assurance behind a signature, such as driver or kernel-level software |
In both cases, the certificate authority verifies that a real, legally registered organization requested the certificate before issuing it — individual, unvetted signing certificates are not something publicly trusted CAs issue for this purpose. The practical difference between OV and EV is the depth of that organization vetting, not what the resulting signature technically proves.
The Hardware Key Requirement Since June 2023
Since 1 June 2023, CA/Browser Forum rules require the private keys behind publicly trusted OV and EV code signing certificates to be generated and stored on hardware — a certified USB token, a hardware security module (HSM), or a certificate authority's cloud-based signing service — rather than as a plain key file on a developer's laptop or build server.
In practice, this changes how signing fits into a build pipeline. A private key sitting in a folder that a CI job could simply reference at build time is no longer how publicly trusted code signing certificates work. Teams need to plan around one of a few patterns instead: plugging a physical token into a dedicated signing machine, running signing through an on-premises HSM, or integrating a cloud signing service that keeps the key inside the provider's secured hardware and exposes signing through an API or client tool the pipeline calls at release time. Whichever pattern you choose, it is worth deciding on it early, since retrofitting hardware-backed signing into an existing release process usually takes more work than designing for it from the start.
Tools Commonly Used to Sign Software
The tool you use to sign a file depends on the platform. Windows executables and installers are commonly signed with Microsoft's SignTool utility; Java archives are signed with jarsigner; and other ecosystems — macOS applications, mobile app packages, browser extensions — each have their own platform-specific signing tools and workflows, usually built into that platform's SDK or developer toolchain.
The exact commands and options vary by tool version and platform, so treat any specific signing command as something to verify against current documentation for your platform and certificate authority rather than a fixed recipe. What stays constant across all of them is the underlying process described above: hash the file, sign the hash with the certificate's private key, attach a trusted timestamp, and let the operating system or runtime verify the result before running the code.
Who Needs a Code Signing Certificate
Code signing certificates are relevant to anyone distributing executable software outside of a fully managed app store flow, including:
- Independent software vendors and companies shipping desktop applications, installers or updaters.
- Developers distributing drivers, kernel-mode components or system utilities, where operating systems place particular weight on publisher identity.
- Teams building browser extensions or add-ons that are signed separately from a store's own review.
- Publishers of scripts, macros or packages where recipients need a way to confirm the file came from a known, verifiable source.
If your web presence already uses one of the several types of SSL certificates, code signing is the equivalent protection for the files you distribute rather than the connections your site serves.
How to Get a Code Signing Certificate
Getting an OV or EV code signing certificate starts with organization validation: the certificate authority verifies your business is a legitimate, legally registered organization before issuing the certificate to it, based on documents such as business registration records and other proof of legal existence. This is the same kind of vetting used for OV and EV SSL certificates, just applied to a certificate meant for signing software instead of securing a website.
The general purchase steps — choosing a product, submitting your organization's documents, completing validation, and receiving the issued certificate — follow the same overall pattern described in our guide to buying an SSL certificate, even though the certificate type and its intended use differ. SSLCipher's product catalog includes code signing certificates alongside its SSL/TLS lineup.
Choosing a Code Signing Certificate
A code signing certificate answers a narrow but important question for anyone who runs your software: is this really the file the publisher released, unchanged since it was signed. It does not vouch for code quality or safety, it depends on OV or EV organization vetting that goes deeper the more assurance you want to offer, and since June 2023 it also requires planning for hardware-backed private key storage in your release process.
If you already buy SSL certificates for your infrastructure, adding code signing is usually a matter of choosing the right product for your organization's vetting level and build pipeline. Check SSLCipher's pricing page for current code signing products and prices.
Frequently asked questions
01Does a code signing certificate mean the software is safe?
No. It confirms the identity of the publisher and that the file has not been altered since it was signed. It does not scan the software for bugs or malicious behavior, and a bad actor can sign harmful code with a validly issued certificate, so it is an accountability and integrity check rather than a statement about software safety.
02Do I need a hardware token to sign code?
Since 1 June 2023, CA/Browser Forum rules require the private keys of publicly trusted OV and EV code signing certificates to be stored on certified hardware, such as a physical token, a hardware security module, or a certificate authority's cloud signing service, rather than as a plain file. Most build pipelines need to plan around one of these options instead of referencing a key file directly.
03What's the difference between OV and EV code signing?
Both confirm that a real, legally registered organization requested the certificate, but EV code signing applies a deeper level of organization vetting than OV, similar to how EV SSL vetting goes further than OV SSL vetting. The choice affects how much identity assurance sits behind your signature, not what the signature technically proves.
04What tools are used to sign software?
The tool depends on the platform: Windows files are commonly signed with Microsoft's SignTool, Java archives with jarsigner, and other platforms such as macOS, mobile and browser extensions have their own platform-specific signing tools. Check your platform's current documentation for exact steps, since tool versions and options change over time.