SSL Certificate Validation Levels: EV vs OV vs DV

Domain Validated (DV): The Baseline Everyone Uses

A DV certificate confirms exactly one thing: that whoever requested the certificate controls the domain it's issued for. The certificate authority verifies this automatically, usually within minutes, through one of a few standard methods — adding a specific DNS TXT record, uploading a designated file to the web server, or responding to an email sent to an address associated with the domain's registration. No information about the organization behind the domain is checked or verified at all.

This makes DV certificates fast, cheap (often free, through providers like Let's Encrypt), and fully automatable — which is exactly why they now account for the overwhelming majority of certificates issued across the web. The trade-off is that a DV certificate proves nothing about who is actually running the site beyond domain control, which is precisely enough for a bad actor to obtain one for a look-alike phishing domain just as easily as a legitimate site owner obtains one for their real domain.

Organization Validated (OV): A Meaningful Step Up

An OV certificate requires everything DV requires, plus actual verification that the requesting organization is a real, legally registered entity — the certificate authority checks business registration records, confirms the organization's legal name and address, and sometimes places a verification phone call to a number independently found through official business records, not one simply supplied by the applicant. This process typically takes one to a few business days rather than minutes.

The verified organization name becomes part of the certificate itself, visible to anyone who inspects the certificate details (though not prominently displayed in the browser address bar the way EV once was). OV certificates are common for business websites that want a documented, verifiable link between the certificate and a real legal entity, without the additional cost and process EV requires, and are frequently used for internal corporate systems and B2B platforms where organizational verification matters more than public-facing trust signaling.

Extended Validation (EV): The Most Rigorous Check

EV certificates require the most thorough vetting process of the three: verified legal existence and physical operating address of the organization, confirmed exclusive right to use the domain, verification that the individual requesting the certificate is actually authorized to act on the organization's behalf, and cross-checks against multiple independent government and business data sources. The process commonly takes several business days to a few weeks and costs significantly more than DV or OV.

Historically, EV certificates triggered a distinctive browser UI treatment — the organization's verified legal name displayed prominently in green next to the address bar. Major browsers removed this special visual treatment starting around 2019, after research found most users didn't notice or understand what the green bar actually indicated, and that its absence wasn't meaningfully deterring users from trusting fraudulent DV-secured sites either. EV certificates still exist and still undergo the same rigorous vetting, but the payoff today is mostly in the certificate's own metadata (visible if you actually inspect it) rather than any longer in a distinctive browser display most users would notice.

DV vs OV vs EV, Side by Side

Why the Chain of Trust Matters More Than the Validation Level

Regardless of whether a certificate is DV, OV, or EV, every certificate's actual trustworthiness in a browser depends on something separate from its validation level: whether it chains back correctly to a trusted root certificate authority already built into the browser or operating system. A certificate is signed by an intermediate certificate authority, which is itself signed by a root certificate authority, and the browser walks this chain link by link, verifying each signature, until it either reaches a root it already trusts or fails to find one — at which point the connection gets flagged as untrusted regardless of how rigorous the original validation process was.

This chain-of-trust mechanism is actually independent of DV/OV/EV entirely — a perfectly issued EV certificate with a broken or incomplete chain (a missing intermediate certificate, most commonly) fails validation in a browser exactly the same way an improperly configured DV certificate does. Getting the chain right is a server configuration responsibility separate from choosing a validation level, and it's one of the most common real-world causes of "this connection is not private" warnings on sites that otherwise have a perfectly valid certificate.

How Browsers Actually Verify the Chain

When a browser connects to a server, the server presents its own certificate along with any intermediate certificates needed to complete the chain (properly configured servers send these automatically; misconfigured ones sometimes send an incomplete chain, relying on the browser to already have the missing intermediate cached from a previous visit to a different site — which works inconsistently and fails for a meaningful share of visitors). The browser verifies each signature in sequence: the server's certificate was signed by the intermediate, the intermediate was signed by the root, and the root is one the browser or operating system already trusts as a starting point.

If any link in that chain is missing, expired, or improperly signed, the entire chain fails validation, even if the actual end-entity certificate itself is perfectly valid and unexpired. This is why a certificate can show a valid expiration date and still trigger a browser warning — the individual certificate being fine doesn't guarantee the chain connecting it back to a trusted root is complete.

How to Actually Tell What Validation Level a Site Is Using

Since browsers no longer display a distinct visual indicator for EV certificates, checking a site's actual validation level requires inspecting the certificate directly rather than glancing at the address bar. Clicking the padlock icon and viewing certificate details shows the Subject field — if it includes an organization name (labeled something like "O=" followed by a company name) alongside the domain, that's OV or EV; if it shows only the domain name with no organization field populated, that's DV. Distinguishing OV from EV specifically requires checking the certificate's policy identifier, a technical detail most casual users won't need but which any dedicated certificate inspection tool surfaces directly.

This inspection step matters more than it might seem, precisely because the validation level is no longer visible passively the way it briefly was during the EV green-bar era — anyone who wants to actually rely on validation level as a trust signal today has to go looking for it rather than having it presented automatically.

How a Certificate Authority Earns Browser Trust in the First Place

The root certificates that browsers and operating systems trust by default aren't chosen arbitrarily — each root program (run separately by Mozilla, Google, Apple, and Microsoft) requires a certificate authority to pass a rigorous, ongoing audit process before its root certificate gets included, covering everything from physical security of the CA's key-signing infrastructure to the specific validation procedures used for DV, OV, and EV issuance. This audit repeats annually, not just once at initial inclusion, and a CA found to have issued certificates improperly can be distrusted and removed — something that has happened to several previously trusted certificate authorities over the years following documented validation failures.

This root-program governance is what ultimately makes chain-of-trust validation meaningful at all: a browser trusting a root certificate isn't a blind default, but the result of that certificate authority having demonstrated, under ongoing audit, that its validation processes (DV, OV, or EV) are actually followed correctly and consistently, not just documented on paper.

Real Scenarios Involving Validation Level and Chain Trust

An e-commerce site handling customer payment data chooses OV or EV specifically so a verified organization identity is documented in the certificate metadata, even knowing most customers won't actively check for it, as part of a broader compliance and due-diligence posture rather than for a visible browser UI benefit that no longer exists.

A developer deploys a new server and gets a browser "not private" warning despite having just installed what they confirmed is a valid, unexpired certificate. The actual cause, found by checking the chain, turns out to be a missing intermediate certificate that the server never sent — a chain configuration problem, not a certificate validity problem, and a completely separate issue from whether the certificate itself was DV, OV, or EV.

A security team evaluating a newly registered look-alike domain impersonating their brand finds it's secured with a perfectly valid DV certificate, issued in minutes with zero organizational verification — a clear illustration of why DV validation alone says nothing about a site's legitimacy, regardless of how legitimate the padlock makes it look.

A small business owner considers upgrading from DV to OV after a customer asks why the certificate doesn't show the company name. Understanding that OV adds real organizational verification (rather than any longer providing a distinctive browser badge) helps them make that decision based on what OV actually does today, not on outdated assumptions about a green address bar.

Why Organizations Still Choose OV or EV Despite No Visible Browser Difference

Given that browsers no longer display any distinct visual treatment for OV or EV certificates, it's a fair question why organizations still pay more and wait longer for them. The reasons that hold up in practice usually aren't about end-user browser display at all: some industries and compliance frameworks specifically require or strongly recommend OV or EV as part of broader due-diligence requirements, independent of what a browser shows. Insurance and liability considerations sometimes factor in too, since a documented, third-party-verified organizational identity provides a paper trail that's useful if a dispute or incident ever needs to be investigated after the fact.

There's also a legitimate internal-trust use case: organizations issuing certificates for internal systems sometimes prefer OV specifically so that anyone manually inspecting a certificate (during an audit, an incident investigation, or routine infrastructure review) can immediately confirm which internal entity actually owns it, without needing to cross-reference a separate asset inventory.

Checking a Certificate's Actual Validation Level and Chain

The certificate's validation level and the completeness of its chain are both things you can verify directly rather than assuming from context. Our SSL Checker shows the certificate's Subject field (revealing whether an organization name is present, a strong indicator of OV or EV), the full issuer chain, and flags whether the chain resolves correctly back to a trusted root — the same fundamental check a browser performs on every connection, made visible and inspectable on demand.

FAQ