Code Signing Certificate Chain Explained
A code signing certificate normally sits below one or more CA certificates in a certificate chain. The chain provides the path used to connect the signing certificate to a trusted root.
The chain is separate from the digital signature itself. The signature protects the signed content, while the certificate hierarchy provides the issuer relationships and evidence needed to validate the signing certificate.
Certificate Chain at a Glance
The certificate chain connects the publisher's end-entity certificate to the CA hierarchy above it. The software signature then uses that certificate in the context of the signed application.
Root CA Certificate
The top-level certificate that acts as a trust anchor in a platform's trust environment.
Intermediate CA Certificate
The issuing layer between the root and the subscriber certificate.
Code Signing Certificate
The certificate associated with the publisher and the public key used to verify signatures.
Signed Software
The application or software object carrying the digital signature and certificate evidence.
What Is a Certificate Chain?
A certificate chain is an ordered set of certificates in which each certificate can be related to an issuer above it, ultimately forming a path toward a root certificate.
Multiple certificates are involved because public-key infrastructures separate the subscriber certificate from the higher-level CA hierarchy. The code signing certificate is an end-entity certificate: it represents the publisher and contains the public key associated with the signing identity.
Above it are one or more CA certificates. The issuer/subject relationship provides the structure that allows a platform to determine who issued a certificate and whether that issuer can itself be validated.
The chain describes certificate relationships; it is not the same object as the software's digital signature.
The Three Main Parts of a Code Signing Chain
Although a chain can contain more than three certificates, these three roles provide the clearest mental model for understanding most code signing hierarchies.
Root CA
A root certificate is the highest certificate in the hierarchy used as a trust anchor. Root certificates are commonly distributed through platform trust stores and are typically self-signed.
- Starting point of the hierarchy
- Self-signed certificate
- Recognized by the relevant trust environment
Intermediate CA
An intermediate certificate sits between the root and the end entity. It lets the CA operate an issuing hierarchy without using the root certificate directly for routine subscriber issuance.
- Signed by a higher CA
- Issues end-entity certificates
- Part of the CA's operational hierarchy
Code Signing Certificate
The code signing certificate is the end-entity credential associated with the publisher. It contains the public key corresponding to the private key used to create the software signature.
- Identifies the publisher
- Contains the signing public key
- Used in code signing validation
How the Chain Connects
Every certificate in the hierarchy has an issuer relationship. The issuer field points toward the authority expected to have issued the certificate, while the issuer's signature provides the cryptographic evidence used when validating that relationship.
Subject → Issuer → Signature is the key relationship to remember. The child certificate identifies its issuer, and the issuer's cryptographic signature is checked as part of certificate validation. The final certificate is then associated with the signed software through the code signing signature.
CA
Why Root and Intermediate Certificates Are Needed
A CA hierarchy separates trust anchors from routine certificate issuance. In a typical public PKI, subscriber certificates are issued beneath intermediate CAs rather than having every subscriber certificate issued directly by a root.
That separation supports operational security and compartmentalization. The root can remain more tightly protected while intermediate CAs perform the day-to-day work of issuing and managing subscriber certificates under the CA's policies.
It also explains why the publisher normally does not need to install or receive a private root CA key. The publisher's job is to protect its own signing private key and use the certificate issued to it; the CA's private keys remain part of the CA's controlled infrastructure.
What Does the Software Publisher Actually Receive?
The publisher works with its own signing credential and key material. The CA's private keys are never part of the publisher's signing setup.
Publisher receives or uses
- Code signing certificate
- Corresponding private key
- Relevant intermediate certificate(s), depending on the signing workflow
- Signing tools or infrastructure needed to create the signature
Publisher does not receive
- Root CA private key
- Intermediate CA private keys
- CA signing infrastructure
- Authority to issue certificates to other publishers
How a Platform Builds the Chain
When a platform validates a signed application, it may need to construct a path from the code signing certificate toward a trusted root.
The available evidence can come from certificates supplied with the signature, local certificate stores, platform trust stores and other chain-building information. The exact mechanism varies by platform and implementation.
What Gets Verified in a Certificate Chain?
Chain validation is about certificate relationships and certificate properties. It should not be confused with scanning the software for malware.
Issuer relationship
Does each certificate identify the expected issuer, allowing the hierarchy to be constructed?
Cryptographic signature
Did the issuing CA actually sign the child certificate, and can that signature be verified?
Validity
Are the certificates within their applicable validity periods under the rules being applied?
Key usage / purpose
Is the certificate appropriate for its intended use, including code signing where required?
Trust anchor
Does the path terminate at a root certificate accepted by the relevant platform trust environment?
Revocation / status
Are applicable certificate status checks satisfied for the validation context?
A Valid Chain vs a Trusted Chain
A certificate path can be structurally correct without being trusted by a particular platform. The difference comes down to the trust environment in which the chain is evaluated.
The certificates form a mathematically and structurally valid path. Issuer relationships, certificate signatures and applicable certificate properties can be checked successfully.
The valid path ultimately connects to a root certificate that the relevant platform recognizes as a trust anchor for the applicable purpose.
Key clarification: a certificate chain can be structurally valid without being trusted by a particular platform.
What Happens When the Chain Is Broken?
A missing or unacceptable certificate can prevent the platform from completing the path it needs for validation.
Result: the chain may not be completed, which can create a trust or verification problem depending on what the platform can obtain from other sources.
Why the Intermediate Certificate Matters
The intermediate is often the missing link when someone sees a code signing certificate but cannot construct the expected chain.
Without the intermediate
The publisher certificate points toward an issuer, but the required certificate may not be available to complete the path.
With the intermediate
The publisher certificate can be related to the issuing CA, which can then be related to the root trust anchor.
The practical requirement is not simply “include an intermediate because certificates need one.” The relevant intermediate must be the correct certificate for the issuing relationship and must be available to the platform through the applicable chain-building mechanisms.
Certificate Chain vs Digital Signature
The certificate chain and digital signature work together, but they solve different problems.
| Certificate Chain | Digital Signature |
|---|---|
| Establishes the certificate hierarchy. | Provides cryptographic evidence associated with the signed content. |
| Root → Intermediate → End Entity. | Created using the corresponding private key. |
| Used for certificate path validation. | Used to verify the signature against the signed data and public key. |
| Provides a path toward a trust anchor. | Helps detect changes to signed content or signature data. |
Signature side
The publisher's private key creates the digital signature over the relevant signed content.
Certificate side
The certificate and its chain provide the public-key and issuer context used when validating the signer.
Different Platforms, Different Chain Behavior
The certificate hierarchy is based on PKI relationships, but the way a platform discovers certificates, selects a path and evaluates trust can differ.
| Platform / Technology | Chain / Trust Context | What to remember |
|---|---|---|
| Windows / Authenticode | Windows certificate trust infrastructure | Chain construction and trust are evaluated within Windows' certificate ecosystem and applicable signature rules. |
| Java / JAR | Java keystore / trust configuration | Trust can depend on the Java runtime's configured certificate authorities and validation behavior. |
| macOS | Apple signing and trust ecosystem | Certificate and signature validation operates within Apple's platform-specific framework. |
| Other environments | Platform-specific validation | Do not assume that one operating system's chain behavior applies everywhere. |
How to Inspect a Code Signing Certificate Chain
When examining a signed application or certificate, start with the certificate fields and then follow the issuer relationships upward.
A useful inspection process is to identify the subject and issuer, locate the intermediate and root, review validity and signature information, and then check whether the platform reports the chain as valid and trusted.
Real-World Example
Consider a publisher distributing a signed desktop application. The certificate chain provides the identity and issuer path that accompanies the software signature during validation.
Company controls its signing setup.
Certificate identifies publisher and public key.
Certificate identifies the issuing CA relationship.
Hierarchy reaches the platform's trust anchor.
Available certificate evidence is assembled.
Platform evaluates the signature and chain.
The chain does not itself create the software signature. Instead, it supplies the certificate hierarchy that helps a platform interpret and validate the certificate associated with that signature.
Common Certificate Chain Mistakes
Most chain problems come from confusing the publisher certificate with the entire hierarchy or assuming that certificate behavior is identical across platforms.
The end-entity certificate is only one level of the hierarchy.
The platform may need the intermediate to complete the issuer path.
A certificate with the wrong issuer relationship does not substitute for the required certificate.
Trust stores and accepted trust anchors are platform-specific.
Dates are one validation input, not the complete trust decision.
The chain describes certificate relationships; the signature is cryptographic evidence over signed data.
Chain building and trust evaluation can differ between environments.
Related Fundamentals
These pages separate certificate structure, trust, verification and timestamping so each topic can be understood without repeating the same explanation.