What Is a Code Signing Certificate?

The public key is meant to be shared through the certificate; the private key is not. This asymmetric relationship lets a verifier use certificate information without gaining access to the secret material used to create signatures, while private-key compromise can allow unauthorized signing and requires a separate security response.

For a publisher, this separation is operationally important. Losing control of the private key is a different security event from having a certificate expire, because the private key is the credential that can be used to produce new signatures.

Obtaining a certificate involves more than downloading a document: the certificate issuance process starts with an application, followed by the CA's validation of information required by the applicable certificate profile and its policies. The CA then issues and signs the certificate so relying systems can validate its issuer relationship.

The CA/Browser Forum's current Code Signing Baseline Requirements define requirements for the issuance and management of publicly trusted code signing certificates, including certificate profiles and subscriber identity information; these rules form part of the broader standards governing publicly trusted code signing.

The certificate is one part of the signing package, not the component that performs the signing operation. In a typical release workflow, a publisher uses a protected private key to sign software with a code signing certificate; the certificate then supplies identity and public-key information that helps a verifier understand whose key is involved and how it relates to a trusted issuer.

In practical terms, the signing operation produces a signature over the software or the data defined by the platform's signing format. The certificate is then included with, embedded in, or otherwise made available to the signed artifact so that verification can retrieve the certificate and evaluate the signature.

The certificate's conceptual role remains the same across platforms, even though signing formats differ: Microsoft Authenticode handles Windows signing, Java code signing applies to JAR files, and macOS code signing follows Apple's signing model.

A code signing certificate helps establish who is associated with the public key used for a signature and provides certificate information that can be evaluated during verification. When the signature is valid and the certificate chain is trusted, a verifier has evidence connecting the signed artifact to the certificate's subject and the corresponding signing key.

The certificate also contributes to an integrity check. If signed content has been changed in a way that causes signature verification to fail, the verifier can detect that the content no longer matches what was signed. This makes code signing useful for distributed software, installers, libraries, scripts and other supported artifacts.

Those assurances have boundaries. A certificate does not inspect source code for vulnerabilities, prove that an application is free of malware, or guarantee that every platform will consider the publisher trustworthy. Security reputation, application behavior and vulnerability management are separate questions.

The certificate is an identity-bearing credential issued by a Certificate Authority. It contains the public key and certificate metadata needed to describe the subject, issuer, validity and permitted use.

The digital signature is the cryptographic result produced with the corresponding private key during the signing operation. During verification, these pieces meet: the verifier can obtain the certificate, inspect its trust chain, retrieve the public key and use that key to check the signature against the signed content.

A code signing certificate is used in the context of software or other signed artifacts. Its identity information and public key are evaluated alongside a digital signature to provide evidence about the publisher and signed content.

An SSL/TLS certificate is used to authenticate a server endpoint and support a protected TLS connection between clients and servers. It is not a substitute for a code signing certificate, and a certificate intended for one purpose should not be described as interchangeable with a certificate intended for the other.

The publisher certificate identifies the subject and carries the public key used in the signing context. An issuing CA certificate establishes the next link in the hierarchy, while a trusted root provides the trust anchor used by the relying system.

During verification, the platform can inspect the certificate's issuer path, along with the signature, validity and applicable policy; the structure of the certificate chain helps establish whether the publisher certificate leads to a trusted root. The exact chain-building and presentation behavior depends on the platform and signing format.

For current publicly trusted code signing certificates, the CA/Browser Forum requirements limit certificates issued on or after March 1, 2026 to a maximum validity period of 460 days. Certificate validity, signing time and timestamping are separate concepts and should not be collapsed into one rule.

A certificate can be valid for a defined period while an application is signed at a particular point within that period. For software that needs to remain verifiable over time, timestamping adds evidence about when the signing event occurred, and release teams can include this step when they timestamp signed software before distribution.

How a platform evaluates an older signature depends on certificate status, timestamp information, signature format, trust rules and platform behavior.

Expiration occurs when the certificate reaches its stated notAfter date. Revocation means the issuing authority has withdrawn the certificate's trust before the normal end of its validity, typically because a defined revocation circumstance has occurred.

A publisher should not assume that an expired certificate automatically makes every historical signature invalid, nor that a valid signature overrides every revocation or trust problem. The distinction is important because certificate expiration marks the end of the stated validity period, while certificate revocation withdraws trust before that point; timestamping, status information and platform policy also influence how a signed artifact is evaluated.

For new releases, the practical response to expiration is usually to obtain and deploy a replacement certificate before signing. If a private key is compromised or a certificate is revoked for a security reason, the response is more serious because the trust problem can affect signatures created with the compromised key.

The certificate remains conceptually the same whether signing happens on a developer workstation, through a hardware security module or through a remote signing service. What changes is where the private key is generated, stored and used.

In a local setup, the signing tool can access the protected private key directly. In contrast, cloud code signing and other remote signing models keep the key inside a controlled signing environment and expose an authorized signing operation to the build system; hardware-protected environments may also move the key operation into a token or HSM.

For publicly trusted code signing, current CA/Browser Forum requirements also place specific controls on subscriber private-key protection and signing services. The key-management environment should therefore be treated as a security boundary rather than simply a storage preference.

The certificate can be shared as part of the verification context; the private key must remain secret; and the digital signature is the cryptographic result created from that private key.

A successful signature check is also not a general security verdict. It can provide evidence about the signing identity and whether signed content still matches the signature, but it cannot replace malware analysis, secure development practices, vulnerability management or software reputation systems.