How Is a Code Signing Certificate Issued?
A code signing certificate is issued after a Certificate Authority validates the applicant’s identity and eligibility, verifies the certificate request and signing-key requirements, and then issues a certificate containing the applicant’s verified identity and corresponding public key.
The certificate does not appear immediately after a CSR is submitted. Issuance is a sequence of identity, technical, and policy checks. The exact workflow varies by certificate profile and CA, but the underlying lifecycle follows the same broad pattern.
Choose
Select the appropriate certificate profile.
Identify
Prepare applicant and verification information.
Protect key
Generate and secure the signing key.
Request
Create and submit the certificate request.
Validate
The CA checks identity and requirements.
Issue
The CA signs and issues the certificate.
Provision
Associate it with the protected signing key.
Who Can Apply for a Code Signing Certificate?
Applicants can include organizations, individual developers where supported, software publishers, and enterprise development teams. Eligibility is determined by the certificate profile and the issuing CA’s policies.
- Organizations
- Individual developers
- Software publishers
- Enterprise development teams
- Other eligible entities under CA issuance policies
Applicant type changes the path
An organization applying for an organization-validated certificate does not necessarily follow the same identity checks as an individual applicant or an EV applicant. Certificate type and applicant type affect validation, documentation, key protection, and the overall issuance workflow.
Choose the Right Certificate Type
The issuance process begins before the application form: the applicant needs to know which certificate profile fits the intended publisher identity and use case.
Organization / OV Code Signing
Used where the publisher identity is tied to an eligible organization. Validation focuses on establishing the organization and its authorized contact.
EV Code Signing
Uses more extensive eligibility and validation requirements than a basic organization-validated workflow.
Individual Code Signing
Where offered, the applicant’s individual identity and eligibility are validated separately from an organization’s identity.
The profile can affect identity validation, documentation, key-protection requirements, and issuance workflow. The differences between OV and EV code signing certificates can help determine which validation path applies.
Certificate selection
Compare code signing certificate options
Review available certificate profiles side by side before deciding which validation path and key protection setup fits your organization.
Compare certificatesPrepare the Applicant Information
The CA needs enough information to establish who the applicant is and whether the applicant is eligible for the requested certificate. Depending on the profile, this can include legal and organizational records or individual identity information.
Information that may be required
- Legal name
- Organization details
- Address and jurisdiction
- Contact information
- Authorized representative or contact
- Government or business records
- Individual identity information, where applicable
The information entered into an application becomes meaningful for issuance only after the CA performs the applicable validation and establishes that the information satisfies its requirements. The code signing certificate validation process varies with the applicant and certificate profile.
Generate the Signing Key
The certificate is associated with a public key, while the corresponding private key is the credential used later to create code signatures. The private key should remain under the subscriber’s control according to the applicable protection requirements. A sound code signing key protection strategy defines how the key is generated, stored, and accessed.
Private key
Protected signing credential. It should not be handed to the CA simply to obtain a certificate.Public key
Derived from the key pair and included in the certificate request/certificate relationship.Certificate
Binds the verified publisher identity to the public key through the CA’s signature.The CA does not need the subscriber’s private signing key to issue the certificate. For stronger controls, teams can sign software without exposing the private key to build agents or other systems that do not need direct key access.
Protect the Private Key
Key protection is part of the issuance story, not an afterthought. Current code-signing requirements can require stronger controls around how the private key is generated, stored, accessed, and used.
Hardware-backed storage
- HSMs
- Approved cryptographic hardware
- Controlled key access
Attestation where required
- Key-generation evidence
- Hardware/protection evidence
- Applicable CA requirements
Remote and cloud approaches
- Cloud signing environments
- Remote signing services
- Reduced private-key exportability
Create the Certificate Request
The certificate request packages the information the CA needs to process the public-key side of the application. If you are preparing an application from scratch, the steps to get a code signing certificate provide the broader sequence. It can include the public key, subject/request information, cryptographic parameters, and CA-specific attributes.
Submitting a request asks the CA to issue a certificate. It does not mean the certificate has already been issued.
Applicant
Prepare signing environment
Key pair
Generate and protect
Request
Submit public-key request
Submit the Application to the CA
Once the application and request are submitted, the CA begins the issuance workflow. This is where the applicant’s supplied information moves into formal validation.
How Does the CA Verify the Applicant?
Validation should not be treated as one generic checklist. The evidence and depth of review depend on whether the certificate represents an organization, an individual, or an EV applicant. The issuing Certificate Authority applies the relevant validation rules.
Establish the organization
- Legal existence
- Organization identity
- Address
- Relevant domain/contact or organizational information where applicable
- Authorized representative/contact
Establish the person
Where an individual certificate is available, the CA performs identity verification appropriate to the individual applicant and the applicable certificate requirements.
More extensive review
EV follows more extensive eligibility and validation requirements. The exact evidence and workflow depend on the applicable requirements and CA policy.
What Does the CA Check Before Issuing?
Before issuing the certificate, the CA brings the identity side and technical side of the request together. The application has to satisfy the applicable certificate profile and policy requirements.
Who is applying?
- Applicant identity
- Organization or individual eligibility
- Authorized contact
What is being requested?
- Public key
- Requested certificate information
- Appropriate certificate profile
Can it be issued safely?
- Required key protection
- Attestation/evidence where applicable
- CA/Browser Forum requirements
- CA policy and practice requirements
Additional Verification and Human Review
Issuance is not always an automated transaction
Depending on the CA, certificate profile, and application, a human verification step can be part of the process. A submitted CSR alone may therefore be only the beginning of the review.
Possible review actions
- Verification calls
- Document requests
- Authorized-contact responses
- Clarification of inconsistent information
- Review of key-protection evidence
This is why issuance can take longer than simply generating a CSR and clicking Submit.
Certificate Issuance
When the applicable validation and policy checks are complete, the CA can approve the request and issue the certificate. The CA signs the certificate; it does not sign the subscriber’s software. The issued certificate becomes part of the code signing certificate chain that relying systems evaluate during verification.
Validation complete
Required checks pass.
CA approves
Request is authorized for issuance.
CA signs
CA applies its certificate signature.
Certificate issued
X.509 certificate is created.
Delivered
Certificate reaches the subscriber workflow.
What the certificate contains
- Subject/publisher identity
- Public key
- Issuer
- Validity period
- Serial number
Certificate extensions and policy
- Key usage / extended key usage
- CA signature
- Policy information
- Other X.509 extensions
How Is the Issued Certificate Delivered?
Delivery depends on how the signing key is managed. The certificate may be downloaded or installed, provisioned into a hardware-backed environment, or made available through a cloud or remote signing workflow.
- Certificate download
- Certificate installation
- Hardware-backed key environment
- Cloud signing environment
- Platform-specific certificate/key container
Install and Associate the Certificate With the Signing Key
The final setup step is to make the issued certificate available alongside its corresponding private key in the environment that will perform code signing.
Issued certificate
Public-key certificate from the CA.
Corresponding key
Protected private signing key.
Signing environment
Store, HSM, cloud signer, workstation, or build server.
Ready to sign
Code signing tool can use the credential.
Common environments include the Windows certificate store, an HSM, a cloud/remote signing service, a developer workstation, or a build server/CI/CD environment. Teams using hosted key infrastructure may also consider cloud code signing.
Ready to select a certificate
Explore available code signing certificates
Once you understand the issuance and key protection requirements, compare certificate options for your publisher type and signing environment.
Browse certificatesWhat Happens If the CA Rejects the Application?
Possible rejection reasons
- Identity cannot be sufficiently verified
- Applicant does not meet eligibility requirements
- Information does not match authoritative records
- Required contact cannot be verified
- Key-protection requirements are not satisfied
- Certificate request has a problem
- Policy requirements are not met
Rejected ≠ revoked
Rejection occurs during the issuance process, before a certificate is issued. Revocation is a later certificate-lifecycle event that changes the status of an already issued certificate.
They therefore require different investigations and different responses.
How Long Does Issuance Take?
There is no single universal issuance time. The duration depends on how quickly the applicant’s identity can be verified, whether manual review is required, and whether the required key-protection setup is already in place.
Faster when
- Identity information is easy to verify
- Applicant records are consistent
- Required contacts respond quickly
- Key requirements are already prepared
Slower when
- Manual validation is required
- Documentation needs clarification
- Contact verification is delayed
- Key attestation/protection needs additional work
Application
Request submitted
Validation
Identity and requirements checked
Approval
Issuance authorized
Issuance
Certificate delivered
What Happens After the Certificate Is Issued?
Issuance is the end of the certificate-issuance lifecycle, but it is the beginning of the publisher’s operational signing lifecycle.
Once the certificate is installed, verifying a code signature confirms that the signed artifact and certificate are being interpreted as expected. The broader code signing workflow explains how this fits into publisher trust.
What the CA Does—and Doesn't—Do
What the CA does
- Validate applicant identity
- Issue the certificate
- Bind verified identity to the public key
- Operate certificate-status infrastructure
- Maintain certificate lifecycle/status
What the CA doesn't do
- Sign your software
- Store your signing key by default
- Guarantee software is malware-free
- Guarantee your application is bug-free
- Replace your signing process
This distinction separates the responsibilities of the CA, the publisher, and the signing system.
Common Misconceptions About Certificate Issuance
Related Code Signing Resources
These pages cover adjacent questions without duplicating the issuance lifecycle explained here.
This page answers: “I need a code signing certificate. What happens between my application and receiving an issued certificate?”