DV, OV, and EV are the three validation tiers a publicly trusted CA can issue. They differ in what the CA verifies about the applicant before signing, not in cryptography. This guide explains the rules, the issuance reality, and when each tier still makes sense.
Publicly trusted TLS certificates come in three validation classes — Domain Validation (DV), Organisation Validation (OV), and Extended Validation (EV) — defined by the CA/Browser Forum Baseline Requirements for the first two and the EV SSL Guidelines for the third. The classification is a property of the issuance process, not of the resulting cryptography: the public key, signature algorithm, and chain are the same across all three.
What differs is what the certificate authority confirms before it signs. DV proves that whoever asked for the certificate controls the domain. OV adds proof that a real, registered legal entity stands behind that domain. EV layers on a deeper vetting of that legal entity's existence, history, and authority to request the certificate. The Subject field reflects that depth — empty for DV, organisation-named for OV, organisation- and jurisdiction-named for EV.
Since 2019, the visible browser cue that once made EV worth its premium — the green address bar with the company name — has disappeared from Chrome and Firefox. What remains is organisational identity inside the certificate itself, useful for regulated workflows, eIDAS qualified contexts, and any verifier that reads the Subject. Read this guide alongside TLS/SSL certificates and certificate authorities to understand who issues these certificates and how the broader trust model works.
A certificate is, at the end of the day, an attestation. A certificate authority takes a request, verifies a set of facts, and signs a structured statement saying "this public key belongs to this subject, and here is what I checked before I said so". The validation level — DV, OV, or EV — is the shorthand for how deep that checking went. Two certificates from the same CA, on the same hardware, with the same elliptic curve and the same 47-day lifetime, can encode wildly different amounts of human review behind them. That difference is invisible to the TLS handshake, but it is the entire reason the three tiers exist.
For most of the public Web, DV is now the default. Let's Encrypt's free, automated issuance, the ACME protocol, and the move toward 47-day lifetimes have made any tier above DV operationally heavier. OV and EV still ship in volume, but the reasons to pick them have narrowed — and changed in nature. They now matter less for what browsers show users and more for what auditors, regulators, and machine consumers can read from the Subject of the certificate itself.
The Baseline Requirements are versioned and tightened on a regular cadence; the current series is v2.x. Anything stated here about specific section numbers should be cross-checked against the version in force when you read it, because the document evolves several times per year as the CA/Browser Forum adopts new ballots.
The CA confirms one thing: that the requester controls the domain on the certificate. Verification is performed through one of the methods listed in section 3.2.2.4 of the Baseline Requirements — most commonly an ACME challenge over HTTP, DNS, or TLS-ALPN. No human contact is required. Issuance takes seconds to minutes. Indicative price ranges from free (Let's Encrypt, ZeroSSL, Google Trust Services) to a few tens of euros per year for commercial CAs. The Subject contains only the Common Name; the Organisation field is empty.
The CA verifies domain control as above, then verifies that a real legal entity exists and that the certificate request was made on its behalf. Identity is confirmed through government registries and qualified independent information sources (D&B, official chambers of commerce, government databases), as required by BR §3.2.2.1 and §3.2.5. Issuance typically takes one to three business days. Indicative price ranges from roughly €60 to €250 per year. The Subject includes the verified Organisation name, locality, state, and country.
The CA performs domain control validation, plus the deeper vetting prescribed by the CA/Browser Forum EV SSL Guidelines: legal existence of the organisation for at least three years (or alternative proofs), physical address, operational existence, and explicit authorisation from a named signatory who confirms the request. Issuance commonly takes three to ten business days. Indicative price ranges from roughly €150 to €1,000 per year. The Subject includes Organisation, jurisdiction of incorporation, registration number, and business category.
The point of the cards above is not the bureaucracy — it is that the certificate, once issued, carries that bureaucracy as a verifiable claim. An auditor reading an EV certificate years later can ask "did the CA actually follow §11 of the EV Guidelines?", and Certificate Transparency logs let them answer that question without trusting the CA's word.
Pure technical proof of domain control. The CA picks one of the methods in BR §3.2.2.4 — agreed-upon change to a website, DNS CNAME or TXT record, e-mail to a constructed address such as `admin@example.com`, ACME HTTP-01, ACME DNS-01, ACME TLS-ALPN-01. Validation evidence must be retained, and a fresh validation is required for every new identifier (under shrinking reuse windows described in BR §3.2.2.4 / §4.2.1). There is no organisation field, no phone call, no signatory.
DV plus identity. The CA verifies that the requesting organisation exists in a government registry, matches the data in the Certificate Subject, and is reachable at the address it claims, using qualified independent information sources (QIIS, QGIS, QIGS) as defined in BR §3.2.2.1 and the supporting checks of §3.2.5. A human in the CA's validation team typically reviews the dossier and confirms the requestor's authority before signing.
OV plus depth and signatory authority. The CA verifies legal existence (typically with three years of operating history or alternative evidence under §11.2 of the EV Guidelines), physical existence, operational status, and explicit authorisation from a named officer of the company. Domain validation must also be performed by methods accepted under §11.7. The certificate carries the registration jurisdiction and number, allowing relying parties to look the entity up in the source registry.
| DV | OV | EV | |
|---|---|---|---|
| Verifies | Domain control only | Domain control + legal entity | Domain control + legal entity + signatory + 3-year existence |
| Issue time | Seconds to minutes | 1 to 3 business days | 3 to 10 business days |
| Indicative price | Free to ~€50 / year | ~€60 to €250 / year | ~€150 to €1,000 / year |
| Subject CN / O | CN present, O empty | CN + O, locality, state, country | CN + O + jurisdiction + registration number + business category |
| Wildcards | Yes | Yes | Not allowed by the EV Guidelines |
| Browser UI | Padlock only | Padlock only | Padlock only (green address bar removed from Chrome 77 and Firefox 70, 2019) |
| Max lifetime (CA/B roadmap target) | 47 days by March 2029 | 47 days by March 2029 | 47 days by March 2029 |
Each tier is encoded in the certificate as a Certificate Policy OID, defined by the CA/Browser Forum in section 7 of the Baseline Requirements. That OID is what programmatic verifiers read to assert "this certificate was issued under the DV / OV / EV policy", independent of any marketing claim on the CA's website.
A certificate that does not assert any of those CA/Browser Forum OIDs is, by Web PKI rules, not publicly trusted for TLS server authentication — at least not under the policies major browsers enforce. Reading the OID is a more reliable signal than reading the Subject, because the Subject can be empty (DV) or partially filled in non-standard ways.
# Fetch a server certificate and inspect its certificate policies
openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null \
| openssl x509 -noout -text \
| grep -A2 "Certificate Policies"
# CA/Browser Forum policy OIDs you will see in the output:
# 2.23.140.1.2.1 — Domain Validation (DV)
# 2.23.140.1.2.2 — Organisation Validation (OV)
# 2.23.140.1.2.3 — Individual Validation (IV, rare for TLS)
# 2.23.140.1.1 — Extended Validation (EV)
#
# The CA's own policy OID is usually present alongside the CA/B one,
# and is the OID actually anchored in the EV root program of each browser.A useful mental model: DV answers "is the right server on the other end of this connection?", OV adds "and which company runs that server?", EV adds "and we have a paper trail to back the company claim". Each layer is additive, each layer costs more to produce, and each layer protects against a different kind of attack.
Anything customer-facing, anything internal-but-public, anything fronted by a CDN, anything that needs to renew every 47 days without a human in the loop — DV is the right answer. The combination of free issuance, the ACME protocol in RFC 8555, and the operational reality of shorter certificate lifespans makes any tier above DV expensive in human time for benefits that browsers no longer surface to end users. For the open Web, DV is not a downgrade — it is the option the rest of the stack is built around.
OV still earns its keep wherever the certificate's Subject is consumed by something other than a browser tab — partner integrations that pin on the Organisation name, eIDAS-related workflows that read the certificate as evidence of corporate identity, audit-driven environments where the CA's vetting record is part of the controls. Banks, insurers, healthcare networks, and B2B SaaS platforms with regulated partners often standardise on OV for that reason. The trade-off is operational: every OV renewal has to clear an identity check, which makes full automation harder than DV.
EV is the right choice when the verifier needs not just "the domain owner controls the key" but "a specific, named legal entity, registered in a specific jurisdiction, formally requested this certificate". Code signing's EV variant (separate document, but the same logic) is the canonical example, and is required by Microsoft for kernel-mode driver signing and by most browsers' download reputation systems. For TLS itself, EV remains useful for eIDAS qualified website authentication certificates (QWACs), where the certificate carries information a regulator may rely on. EV certificates cannot include wildcards, so they require explicit enumeration of every covered FQDN.
As validity windows collapse toward 47 days by March 2029, and as the period during which a CA may reuse prior domain validation evidence shrinks toward 10 days (BR §3.2.2.4 / §4.2.1), the operational cost of OV and EV grows: each renewal cycle includes a fresh identity vetting unless the CA can rely on cached evidence within the allowed reuse window. DV — with its automatable, evidence-light proof of control — absorbs that pace easily. OV and EV need a CLM platform that can drive the validation workflow itself: requesting challenges, provisioning DNS records, attaching the validation artifacts to the right organisational record, and renewing on time. Without that, the cost of the tier multiplies with the renewal frequency.
Automated DCV across every tier and every CA — Evertrust orchestrates Domain Control Validation for DV, OV, and EV issuance against any public CA, with DNS-agnostic automation that retrieves challenges, provisions proof records, and tracks reuse windows as they shrink toward 10 days. Renewals that used to require manual ticketing become repeatable, audited workflows.
One inventory across DV, OV, and EV — Evertrust CLM keeps a single source of truth for every public TLS certificate in the environment, whatever tier it was issued at and whichever CA signed it. Validation level is a first-class attribute alongside expiry, owner, and deployment target, so audit questions like "show me every OV certificate expiring this quarter" are one query, not a spreadsheet exercise.
Private CAs with policy-aware tiers — Evertrust PKI lets you define internal validation tiers that mirror the public model where it matters and diverge where it should, with policy controls over which profiles, key types, validity periods, and Subject content each requester may obtain. The same governance model applies across public DV / OV / EV renewals and private issuance.