Come convalidare i certificati di firma del codice di DigiCert e GoGetSSL

You have paid for a code signing certificate and nothing has arrived. The order sits at “pending validation”, the Certificate Authority has emailed you asking for something, and it is not obvious what would actually close the request. That is the normal state of a code signing order, because code signing is validated against your legal identity rather than against a domain you control, and identity checks run at the speed of public records and phone calls.

This guide walks through what DigiCert and GoGetSSL check, in the order they check it, and what makes each step stall. It covers Organization Validation, Extended Validation, and the individual route that GoGetSSL, Sectigo and Comodo offer to developers with no registered company.

What Code Signing Validation Actually Checks

A TLS certificate is validated against a domain name. A code signing certificate is not. There is no domain in it at all, and the CA/Browser Forum’s Code Signing Baseline Requirements say so directly: code signing certificates must not include a domain name. What goes in the subject is the name of the entity that will be shown as the software publisher, so the whole vetting process is about proving that entity is real and that you speak for it.

That has one consequence worth knowing before you start. Validation you have already passed for an SSL certificate does not carry over. DigiCert tracks code signing as its own validation type on the organization record, and the organization has to be validated specifically for it.

• CS, described by DigiCert as Code Signing Organization Validation, is the type required for a standard code signing certificate.
• EV CS, Code Signing Organization Extended Validation, is the type required for an EV code signing certificate.

An organization validated as CS is not automatically validated as EV CS. If you ordered EV after previously buying a standard certificate, expect a fresh round of checks rather than an instant issue.

Two things must finish, not one

This is the part most readers are missing when an order looks stuck for no reason. DigiCert’s documented flow has two independent tracks, and issuance waits for both:

1. Organization validation. The vetting team confirms your legal entity, its address and a phone number that belongs to it.
2. Verified contact approval. A person recorded on the account as a verified contact, and separately validated by DigiCert, has to approve the order. DigiCert sends an approval email to every selected verified contact after submission.

The verified contact is also typed. When the contact is added, the order form asks whether they may approve CS or EV CS requests, and a contact approved for one is not automatically able to approve the other. A common stall is an organization that passed vetting days ago, with the order still pending because the approval email went to a contact DigiCert has not validated, or to someone who has left the company.

DigiCert also contacts a verified phone number for the organization to confirm you have the authority to place the order. Its documentation says this call typically happens within 24 hours of submission. That call is not optional courtesy, it is how the CA satisfies the Baseline Requirements’ rule that the certificate requester’s authority be confirmed over a reliable method of communication.

The hardware decision is part of validation

Since June 1, 2023 the Baseline Requirements have obliged CAs to make sure the subscriber’s private key is generated, stored and used inside a hardware crypto module certified to at least FIPS 140-2 Level 2 or Common Criteria EAL 4+. That is why the order form asks how you want the key provisioned before anyone has looked at your paperwork, and why the answer can hold up issuance.

• DigiCert-provided hardware token. No CSR. DigiCert installs the certificate on the token and ships it. Nothing extra to prove, because the CA generated the key itself.
• Your own supported hardware token. No CSR. You pick the token model during the order. DigiCert’s supported list is narrow and currently covers SafeNet eToken 5110 variants, so check your device is on it before choosing this route.
• Your own HSM. A CSR is required, generated on the HSM before you submit the order. This route has an extra blocking step, covered below.
• DigiCert KeyLocker. No CSR, no shipped device. The key lives in DigiCert’s cloud HSM.

On the HSM route, DigiCert states that it sends an agreement email to the certificate requester confirming the private key protection requirement, and that it cannot issue the certificate until the requester replies. If your order is otherwise complete and nothing is moving, look for that email before you open a support ticket.

Two details catch people out on the HSM route. The key must be at least RSA 3072-bit or ECC P-256, and DigiCert asks that the CSR carry the older-style header and footer:

-----BEGIN NEW CERTIFICATE REQUEST-----
MIIEnDCCAoQCAQAwVzELMAkGA1UEBhMCVVMxDTALBgNVBAgMBFV0YWgxDTALBgNV
...
-----END NEW CERTIFICATE REQUEST-----

Most tooling emits BEGIN CERTIFICATE REQUEST without the word NEW. The base64 body is identical either way, so if the upload is rejected, edit the first and last lines rather than regenerating the key. If you are producing the request on a device rather than a server, the sibling guides walk through it: YubiKey 5 FIPS CSR generation and attestation and Luna Network Attached HSM CSR and attestation. Note that a YubiKey is not on DigiCert’s supported token list, so that route belongs to the CAs that do accept it rather than to a DigiCert token order.

Key attestation, where the device counter-signs the request to prove the key was generated non-exportably, is one of the methods the Baseline Requirements allow a CA to use to satisfy the hardware rule. Whether a given CA asks you for it depends on the CA and the device, so produce the attestation when you generate the key and keep it, rather than trying to recreate it later.

Organization Validation (OV / CS)

Standard code signing validation has four requirements in the Baseline Requirements, and CAs turn them into the steps below. Nothing here needs a domain, a website, or a live server.

1. Organization authentication

The CA has to confirm that your legal entity exists and is active, and that the name on the order matches the name on the record exactly. “Exactly” is meant literally, including the corporate identifier. If you registered as Acme Software Ltd and ordered as Acme Software, that mismatch alone will bounce the order back to you.

The fastest path is the one you never see. DigiCert looks your entity up in the online register of the government agency in the jurisdiction where you were incorporated, or in a third-party database it treats as a reliable data source. If your details are current there, this step closes without you doing anything.

When nothing usable is published, the CA accepts documents instead: Articles of Incorporation, a Chartered License, or a DBA statement issued by your local government. Send them back through the validation email thread the CA opened with you, so they attach to the right order. DigiCert’s general support address is [email protected] and its support page lists current contact routes.

If you trade under a name that is not your registered name, the CA has to verify your right to use it separately, through the government agency that manages trade names, a reliable data source, or an attestation letter with documentary support. Get the fictitious-name filing current before you order rather than after.

What stalls it

• Registration documents that are expired, or that show a name the company has since changed.
• A trading name on the order that is not registered anywhere.
• Entities registered through an offshore or third-party agency, where the public record shows the agent rather than the business.

2. Address verification

The CA confirms that the address on the order is the entity’s address of existence or operation. The same sources apply: the government register, a reliable third-party database, a site visit, or an attestation letter. Directories such as GLEIF, Dun and Bradstreet and established business listings are the usual second source when the register is silent on address.

There is one useful shortcut here. The Baseline Requirements let a CA verify the address, though not the identity, from a utility bill, a bank statement, a credit card statement or a government-issued tax document. So if your registration paperwork proves the company exists but does not show where it is, a recent utility bill addressed to the company usually closes the gap.

What stalls it

• Registers that publish company status but not street address.
• Third-party directories carrying an address you moved out of years ago. Correcting the listing is usually faster than arguing about it.
• A registered-agent address that is not somewhere the business operates.

3. Phone number verification

Steps 3 and 4 are two halves of a single requirement. The Baseline Requirements say the CA must confirm the certificate requester’s authority and the authenticity of the request over a reliable method of communication, and CAs implement that as a phone call. Step 3 is establishing a number the CA is willing to trust; step 4 is using it.

The number cannot simply be the one you typed into the order form, because that proves nothing. It has to come from an independent source: a listing in a business directory the CA accepts, Dun and Bradstreet being the one CAs name most often, or the government record if that record carries a phone number. Many registers do not publish phone numbers at all, which is why a directory listing is the usual route.

If you know you have no listing anywhere, create one before you order. A listing that shows your verified business name, including the corporate identifier, alongside the same address and a working number, removes the single most common cause of a multi-day delay.

What stalls it

• No listing in any directory the CA accepts.
• A listed number that is wrong, disconnected, or belongs to a previous occupant of the address.
• A listing under a slightly different company name, which the CA cannot match to the order.

4. The verification call

Once a number is established, DigiCert calls it to confirm that you or your authorized representative really placed the order. Its documentation says the call typically comes within 24 hours of submission. Treat that window as the thing to plan around: make sure somebody who knows about the order can be reached on that specific number, and that your name is in the company directory and on the voicemail greeting, so the agent can confirm they reached the right person.

If nobody answers, the CA normally leaves a voicemail with a code and instructions for calling back. Returning that call promptly is the fastest way to close the step. Do not wait for a second attempt.

What stalls it

• The verified number reaches a switchboard or an automated menu with no extension recorded on the order.
• Time zones. The CA calls during its own working hours, not yours.
• The person who answers has never heard of the order and declines to confirm anything.

5. If your company is under three years old, expect an ID check

This one is not on most guides and it surprises a lot of new companies. The Baseline Requirements add a fourth obligation for standard code signing: if the entity’s date of formation is less than three years before the date of the certificate request, the CA must also verify the identity of the certificate requester personally, using the same method the rules define for individual applicants.

In practice that means a copy of a current government-issued photo ID that clearly shows your face, plus confirmation of your address. It is a rule about the age of the company, not about the size of the order, so a brand-new startup buying a standard certificate will meet it while a decades-old firm will not. Have the ID ready rather than treating the request as a mistake.

6. Approval and issuance

When the organization checks are done, the order still needs the verified contact to click approve in the email DigiCert sent at submission. After that, final review is internal and normally needs nothing from you. You then get instructions for collecting the certificate, and what happens next depends on the provisioning method: a shipped token arrives with the certificate already installed, while the other three routes have you download the certificate and install it yourself.

Extended Validation (EV CS)

EV code signing is validated against the EV sections of the Code Signing Baseline Requirements, which absorbed the CA/Browser Forum’s separate EV Code Signing Guidelines in 2024, rather than against the lighter organization rules. Those sections add checks rather than replacing them, so everything in the OV section still applies. Below are the parts that are genuinely different.

Operational existence

This is the check that has no OV equivalent, and the one that most often decides how long an EV order takes. The CA has to establish that the entity is actually operating, not merely registered. The rules give four acceptable routes, and the three-year figure people quote is only the first of them:

• Three years of existence, shown by the incorporation or registration record.
• A current listing in a qualified information or tax information source, which in practice usually means a business credit report such as a DUNS report.
• An active demand deposit account at a regulated financial institution, confirmed by the bank. This is the route for companies under three years old, and it is why CAs ask for a bank confirmation letter.
• A verified professional letter from a lawyer or a chartered or professional accountant confirming the account exists.

So a young company is not blocked from EV. It just cannot use the cheapest route. Decide early which of the other three you will use, because the bank letter and the professional letter both depend on somebody else’s turnaround time and both usually cost money.

A professional letter is often the most efficient option overall, because a single letter from a qualified lawyer or accountant can satisfy legal existence, physical address and operational existence together. If your entity is barely visible in public records, ask for that letter first rather than working through the checks one at a time.

Address and phone under EV rules

The substance is the same as OV but the tolerance is lower. The physical address must be a real place of business in the jurisdiction, and P.O. boxes are not accepted. The phone listing must show the verified business name including the corporate identifier, together with the same physical address, in a directory the CA accepts.

If the verified number is not your direct line, tell the CA in advance. It can dial an extension, follow an automated menu, or accept a transfer once the call has been placed to the verified number. What it cannot do is call a different number you supply afterwards, because that would defeat the point of verifying the first one.

Roles: who signs and who approves

EV formalises the people involved. The rules define separate roles for the Certificate Requester who submits the order, the Contract Signer who signs the subscriber agreement, and the Certificate Approver who approves the request. One person can hold more than one role, but the CA has to verify the name, title and authority of each.

This is the same idea DigiCert implements as the verified contact on the account, tagged EV CS. Getting that contact validated before or alongside the order, rather than after everything else is done, is the single most effective thing you can do to shorten an EV timeline.

Approval of the request

Older guides, including the previous version of this one, describe a separate EV Approver Form that arrives by email and has to be signed and returned. That is one permitted method, not the only one, and it is not how DigiCert’s current portal flow works.

The Baseline Requirements allow the CA to confirm approval in three ways: by contacting the certificate approver over a verified channel and taking oral or written confirmation, by notifying them that a request is waiting on a secure access-controlled website and recording their login and approval there, or by verifying their signature on the request. DigiCert uses the second: it sends an approval email to the selected verified contacts and records the approval in the account.

Practically, this means you are looking for an approval email and a button, not a PDF to print and sign. If your CA does send a form, sign it, but do not sit waiting for one that is not coming. Separately, you accept the Certificate Services Agreement at submission time, before validation begins.

Individual Validation for developers without a company

Both the previous version of this page and much of the wider internet describe Individual Validation as a GoGetSSL exclusive. It is not. The Code Signing Baseline Requirements define an Individual Applicant as a natural person whose legal name goes in the certificate subject, and several brands issue on that basis. In SSL Dragon’s own catalogue, Business or Individual Validation is offered on the GoGetSSL, Sectigo and Comodo standard code signing products.

Two boundaries do apply. There is no individual route at Extended Validation, since EV is defined around a registered organization. And DigiCert’s CertCentral code signing flow is built around a validated organization record and a verified contact, so an individual developer ordering without a company is buying one of the other brands. Sectigo-branded orders follow a slightly different workflow, covered in how to validate Sectigo and Comodo code signing certificates.

On GoGetSSL’s own product pages the brand’s code signing certificates are listed under business and extended validation labels, while its comparison notes say the certificates can be issued to individuals as well as business entities. That inconsistency is worth knowing before you order: if you are buying as an individual, confirm the validation route with the seller rather than relying on the product label.

What the rules require

Individual validation has two parts, and they are separate obligations. The first proves who you are. The CA must obtain a legible copy of at least one currently valid government-issued photo ID that clearly shows your face, such as a passport, driver’s license, military ID or national ID, and inspect it for signs of alteration. It must also confirm your address, using that photo ID, a qualified information or government source, or an activation code physically mailed to you.

The second part proves that the person holding the ID is the person who placed the order. The rules give the CA four options here, and this is where the video call comes from:

• A photo of you holding the same ID, clear enough to read both your name and the issuing authority.
• An in-person or webcam check, where a CA employee or contractor sees you, reviews the ID and confirms you are the person on it. This is the route most CAs use.
• An executed Declaration of Identity carrying a biometric identifier such as a fingerprint or handwritten signature, witnessed by a notary, lawyer, accountant or other authorized verifier. The CA then confirms the document directly with that verifier.
• A certificate request digitally signed with a personal certificate issued at an accepted assurance level, such as a qualified certificate under ETSI TS 101 862 or an Adobe AATL signing certificate.

Notice what this means for the notarized-document question. A notary is one accepted route, through the Declaration of Identity, but it is not required. If a CA offers you a webcam appointment, that satisfies the same rule without any paperwork, and it is normally much faster. These requirements are unchanged in the current version of the Code Signing Baseline Requirements, so guidance written a couple of years ago is still accurate on this point.

Beyond the rules, individual CAs ask for their own supporting documents. A common pattern is a passport on its own, or two documents if you have no passport: one photo ID such as a driver’s license or national ID, plus a second document carrying your name, such as a recent utility bill. Individual orders still finish with a phone verification and a confirmation call, exactly as organization orders do.

How long it takes, and what to do when it stalls

SSL Dragon lists code signing certificates as issuing in one to seven business days, and the range is wide for a reason: everything above either resolves from a database in seconds or waits on a third party. An entity that is well documented in a public register, with a matching directory listing and a validated verified contact already on the account, can clear in a day. An entity that needs a bank letter is measured in weeks, and none of that time is spent by the CA.

DigiCert publishes one number worth planning around: the authority confirmation call typically comes within 24 hours of submission. That is the checkpoint you control.

Shorten it before you order

• Pre-validate the organization. DigiCert lets you submit organizations for validation ahead of any order, so later requests issue almost immediately. If you expect to buy again, this converts the whole wait into a one-time cost.
• Add and validate the verified contact first. In CertCentral the contact is attached to the organization record, and DigiCert has to validate them before they can approve anything. Nothing issues without it, and it validates independently of the organization.
• Check your public record before you pay. Look up your own entity in the government register and in a business directory. Company name, corporate identifier, street address and phone number should agree across all of them and match the order exactly.
• Choose the provisioning method deliberately. If you already own certified hardware, read what code signing certificate delivery method to choose before ordering, because switching afterwards means reissuing.

When it is already stuck

Work through the blocking points in this order, because they fail independently and only the last one is genuinely out of your hands:

1. Check whether a verified contact has actually approved the order, and whether that contact is validated for the right type, CS or EV CS.
2. On an HSM order, check for the private key protection agreement email. Issuance is blocked until the requester replies to it.
3. Search spam and quarantine for anything from the CA. Validation email is the highest-value message in the process and the one most likely to be filtered.
4. Confirm somebody is reachable on the verified phone number during the CA’s business hours, and that a returned voicemail has been called back.
5. Only then ask what documentation is outstanding, and send it back on the existing validation thread so it attaches to the order.

Validity has changed, so plan the renewal

No public code signing certificate can carry multi-year validity any more. DigiCert states that as of February 24, 2026 the maximum validity for public code signing and EV code signing certificates is 459 days, and that it no longer issues two or three-year certificates. Two and three-year purchase terms are still sold, but the certificate inside the term is reissued during it rather than spanning it. Older guidance describing one, two or three-year certificates, including the previous version of this page, is out of date.

The practical effect is that you will repeat this process more often. Two habits reduce the pain: timestamp everything you sign, so signatures stay valid after the certificate expires, and keep the organization pre-validated so the next order does not start from zero.

Frequently Asked Questions

For the steps that come after issuance, see how to set up an EV code signing certificate and how to sign an EXE file. The full set is in the code signing tutorials.