DV vs OV vs EV describes how much a certificate authority verified before issuing a TLS certificate. Domain validation proves control of the names; organization validation adds the legal identity of the company; extended validation adds a stricter identity check under separate guidelines. The cryptography is identical, browsers display all three the same way, and since 2019 the differences matter mainly to people and systems that read certificate details.
At a glance
| DV | OV | EV | |
|---|---|---|---|
| What the CA verifies | Control of each domain name | Domain control plus the organization's legal existence, name and address | OV checks plus registration number, jurisdiction, operational existence and the requester's authority |
| Rules | Baseline Requirements §3.2.2.4 | Baseline Requirements §3.2.2.1–§3.2.2.3 | CA/Browser Forum EV Guidelines |
| Policy OID | 2.23.140.1.2.1 | 2.23.140.1.2.2 | 2.23.140.1.1 |
| Subject fields | Usually only CN; names live in SANs | O, L, ST, C | Plus businessCategory, jurisdictionC, serialNumber (registration number) |
| Issuance time | Seconds to minutes (ACME) | Typically hours to days for first vetting | Typically days |
| Automation | Full (ACME) | Partial: identity vetted once, then reused | Partial |
| Validation data reuse (from 15 March 2026) | Domain control: 200 days, falling to 10 days in March 2029 | Organization identity: 398 days | Set by the EV Guidelines |
| Maximum certificate lifetime | 200 days now, 100 from March 2027, 47 from March 2029 | Same | Same |
| Browser address bar | Padlock | Padlock | Padlock (EV indicator removed: Safari 12 in 2018, Chrome 77 and Firefox 70 in 2019) |
What each level proves
Domain validation proves that whoever requested the certificate controlled the domain at that moment: by serving a token over HTTP (http-01), publishing a DNS TXT record (dns-01), answering a TLS-ALPN challenge, or through one of the other methods listed in Baseline Requirements §3.2.2.4. Since 2025 CAs must corroborate these checks from several network perspectives, so hijacking DNS or BGP routing toward a single vantage point is no longer enough to obtain a certificate. A DV certificate says nothing about who operates the site; a phishing domain gets one as easily as a bank.
Organization validation adds the applicant's verified legal name, locality and country to the certificate subject, after checks against official registries and verified contact details. Extended validation applies a stricter, prescriptive process covering registration numbers, jurisdiction of incorporation, operational existence and verification of the person approving the request, recorded in dedicated subject attributes.
What none of them proves: that the site is safe, that the organization is honest, or that the person you are talking to is who they claim to be.
How to tell which one a site uses
The policy OID in the Certificate Policies extension states the validation level; the subject shows what was verified. This script, run on 20 October 2026 with OpenSSL 3.6.5, reads both from three live sites.
for host in letsencrypt.org www.microsoft.com www.paypal.com; do
echo "== $host"
openssl s_client -connect "$host:443" -servername "$host" </dev/null 2>/dev/null \
| openssl x509 -noout -subject -ext certificatePolicies
done
== letsencrypt.org
subject=CN=letsencrypt.org
X509v3 Certificate Policies:
Policy: 2.23.140.1.2.1
== www.microsoft.com
subject=C=US, ST=WA, L=Redmond, O=Microsoft Corporation, CN=www.microsoft.com
X509v3 Certificate Policies:
Policy: 1.3.6.1.4.1.311.76.509.1.1
CPS: http://www.microsoft.com/pkiops/Docs/Repository.htm
Policy: 2.23.140.1.2.2
== www.paypal.com
subject=jurisdictionC=US, jurisdictionST=Delaware, businessCategory=Private Organization, serialNumber=3014267, C=US, ST=California, L=San Jose, O=PayPal, Inc., CN=www.paypal.com
X509v3 Certificate Policies:
Policy: 2.16.840.1.114412.2.1
Policy: 2.23.140.1.1
CPS: http://www.digicert.com/CPS
The first is DV (only a name), the second OV (organization and address), the third EV (jurisdiction of incorporation, business category and registration number). The extra OIDs are each CA's own policy identifiers. The certificate decoder shows the same fields for a pasted PEM.
What browsers show
Browsers once displayed EV certificates with a green bar and the company name. Studies found that users rarely noticed the indicator or its absence and did not change their behavior because of it, and researchers showed that legally distinct companies could obtain EV certificates for names confusingly similar to well-known brands. Safari 12 removed the name from the address bar in 2018; Chrome 77 (September 2019) and Firefox 70 (October 2019) moved EV details into the page-information panel. Today all three levels show the same padlock, and the organization appears only when a user opens the certificate details.
Operational differences
Lifetimes and validation reuse are shrinking for everyone. Under ballot SC-081v3, certificates issued from 15 March 2026 may be valid for at most 200 days, dropping to 100 days in March 2027 and 47 days in March 2029; domain validation can be reused for 200 days now and only 10 days from March 2029, while organization identity information may be reused for 398 days. Every public certificate therefore needs automated renewal, and OV and EV add a periodic identity re-vetting step on top of the same automation.
ACME itself validates only domain control. Some commercial CAs accept ACME orders for OV and EV certificates from accounts bound to a pre-vetted organization through External Account Binding (RFC 8555 §7.3.4), which lets companies automate renewals after an initial manual identity check. Certificate Transparency logs every publicly trusted TLS certificate, so the organization details in OV and EV certificates become public as soon as they are issued.
When to choose which
- Public websites and APIs: DV, automated with ACME. Spend the saved effort on HSTS, CAA records and CT monitoring.
- Contracts, regulators or partners that require an identified certificate subject (some payment, banking and government integrations): OV, or EV where it is specified.
- Client systems that match the organization name in a certificate: OV, but prefer pinning keys or using a private CA for such integrations.
- Internal services and mTLS: none of the three; use a private CA.
- Code signing: a separate product with its own validation rules and hardware-protected keys (required since June 2023), not TLS OV or EV.
- Brand protection: CAA records, CT monitoring and domain portfolio management address the risks EV was meant to address more directly.
Migration notes
- Moving from EV or OV to DV usually needs no change on the server beyond the certificate: request a DV certificate for the same names (with a new key, ideally ECDSA P-256), deploy it with the full chain and let the old one expire.
- Check dependencies on subject fields: client allowlists, monitoring rules or partner integrations that match
O=will break with DV. - Automate first: manual renewal is already a risk at 200 days and will not keep up at 47 days, whatever the validation level.
- Set CAA records so only your chosen CAs can issue, and bind them to your ACME account with
accounturi(RFC 8657); the CAA record generator builds them. - Watch CT: a Certificate Transparency monitor lists certificates issued for your names, so unexpected issuance at any level is visible (Certificate Transparency for developers).