What is SSL Certificate Validation? SSL Validation Levels Explained
Definition
SSL certificate validation, in the pre-issuance sense, is the process undergone by a Certificate Authority to verify certain details about a certificate applicant before issuing the certificate. There are three common levels of validation, with increasing levels of scrutiny. These are Domain Validation, Organization Validation and Extended Validation.
For years, the mental model for a “high trust” certificate was the green address bar with a company name sitting next to the padlock. Then it quietly disappeared. Chrome removed the Extended Validation name indicator in version 77, Firefox dropped it in version 70, and Safari had already stopped showing it earlier. The visible reward for buying the most expensive certificate on the menu vanished from the one place users could see it.
That raises an obvious question. If the badge is gone, what did the higher validation level actually buy you? The answer has nothing to do with cryptography and everything to do with what a certificate authority checked before it signed.
Validation level is a procedural axis, not a cryptographic one
Here is the part most explainers hide under the carpet: every publicly trusted TLS certificate delivers the same family of cryptographic schemes and the same security levels in the cryptographic sense. What actually varies is the validation process the CA performs. The key types are the same. The chain math is the same. The TLS handshake is byte-for-byte identical whether the certificate is DV, OV, or EV.
What changes across the tiers is the evidence the certificate authority (CA) collected before it agreed to sign. Validation level is a property that sits alongside everything else about a certificate, orthogonal to the cryptographic protocols. Think of it as a procedural distinction: how much identity vetting happened at issuance, not how strong the lock is afterward. Once you hold that framing, the rest of the picture falls into place quickly.
If you want the mechanics of how the handshake and the subsequent encryption actually work, check out our page on the SSL/TLS protocol.
The three tiers, by what the CA checks
The cleanest way to understand DV, OV, and EV is to read each one as a pair: the claim the certificate makes, and how the CA verified that claim before signing.
Domain validated (DV)
The claim: whoever requested this certificate controls the domain name.
How it is verified: the CA confirms control of the name, typically through a lightweight automated check such as a DNS record, a file placed on the server, or an email to an address at the domain. As such, DV is the most basic and fastest validation type, typically issued within minutes. No organization details are verified or displayed. DV is well suited to personal sites, internal tools, and any endpoint where you need cryptographic assurances for the client without a public identity claim. Learn more about Domain Validation.
Organization validated (OV)
The claim: control of the domain, plus a real, verified legal entity standing behind it.
How it is verified: the CA does everything it does for DV and then confirms the organization’s legal existence. OV issuance involves the CA checking the organization’s identity against government records and asking for supporting documentation. The verified organization details are written into the certificate itself. OV is the common recommendation for commercial websites and any application that collects user data. Learn more about Organization Validation in our detailed guide.
Extended validation (EV)
The claim: everything OV asserts, held to a stricter, standardized bar.
How it is verified: EV is the most rigorous tier. The CA runs an in-depth review of the organization, confirming its legal, physical, and operational existence, and the request has to be initiated by the organization itself. EV is governed by the CA/Browser Forum (CABF) EV Guidelines, first established in 2007, which standardize the checks: confirming the incorporating agency, verifying a physical address and phone number, confirming the requester is authorized to act for the organization, and requiring two people to sign off on issuance. It is more paperwork and more scrutiny, aimed squarely at proving the entity is who it says it is. Dive deeper into Extended Validation by reading our dedicated page.
Notice what stayed constant across all three. The cryptography itself did not get stronger as you moved up. Only the identity evidence did.
Where the validation level shows up in the certificate
If the browser no longer paints the difference for you, you can still read it directly from the certificate. The identity evidence does not disappear when the address bar goes quiet. It lives in the certificate fields.
For OV and EV, the verified organization data sits in the subject Distinguished Name. EV adds structured fields such as businessCategory, jurisdictionOfIncorporation, and a registration number carried in serialNumber. The tier itself is signaled by a policy identifier (an OID) in the certificatePolicies extension.
One subtlety is worth stating plainly: a certificate does not announce “I am EV” in plain language. EV recognition is a mapping that the relying party ships, pairing a specific root and policy OID with EV status. The certificate carries the OID; the software decides what that OID means. That design is exactly why the indicator was removable in the first place, a point we will come back to.
You can inspect all of this yourself and find out what exact tier the certificate is at. Pointing OpenSSL at an online host prints the subject fields and the policy identifiers:
openssl s_client -connect keyfactor.com:443 -servername keyfactor.com </dev/null 2>/dev/null | openssl x509 -noout -subject -text
Look at the Subject line for organization fields, and scan the Certificate Policies section for the OID that identifies the tier. In this example, Subject: CN=Keyfactor.com indicates that the organization’s Common Name (CN) is http://Keyfactor.com . The policy OID, located in line X509v3 Certificate Policies: Policy: 2.23.140.1.2.1, indicates that this certificate was validated at DV tier. How do we know that? We know that from the table below, which contains the OID corresponding to each tier.
| OID | Tier |
|---|---|
| 2.23.140.1.1 | EV |
| 2.23.140.1.2.1 | DV |
| 2.23.140.1.2.2 | OV |
For a full reference on how these pieces fit together, see the fields that make up a certificate, which walks through the subject DN, extensions, and encoding in detail.
Why the indicator went away
The EV name indicator was not removed on a whim. Usability research on the browser security UI found that the special EV treatment produced no measurable change in user behavior. Google’s Chrome Security UX team, whose findings are documented publicly in the Chromium project, concluded that the EV indicator was not conveying its intended meaning to users, and Mozilla reached a parallel conclusion before removing it in Firefox. People did not notice its presence, and they did not notice its absence. A signal that no one reacts to is not doing the job it was designed to do.
There was a second problem. The indicator was spoofable. Because it displayed an organization name, an attacker could register a confusingly similar but legitimate legal entity, obtain a valid EV certificate for it, and present a plausible-looking name in the exact spot users were told to trust. This was not hypothetical: in 2017, security researcher Ian Carroll obtained a valid EV certificate for a legally registered company he named “Stripe, Inc.” to demonstrate exactly this weakness. Placed right after the OID discussion, the reason becomes clear: because EV status was just an OID the browser chose to interpret, the browser could also simply choose to stop interpreting it in the address bar. And that is what happened.
What a validation level still buys you
Strip away the badge and there is still a short, honest list of things a higher tier provides:
- Machine-readable identity.
The verified organization data is present for anything that parses certificates: security tooling, inventory systems, fraud checks, and internal policy engines. The address bar was never the only consumer of that data. - A marginally higher misissuance bar.
More vetting at issuance means it is somewhat harder for a bad actor to obtain a certificate that falsely asserts an organization’s identity. - Contractual or regulatory fit.
Some agreements and compliance regimes name a specific tier. If a requirement says OV or EV, the tier is the deliverable, full stop.
The clearest historical example lived outside server TLS entirely. In EV code signing, the tier used to be load-bearing. Microsoft SmartScreen reputation, which governs the warnings users see when they run downloaded software, once accrued faster for binaries signed with EV credentials, so the extra vetting mapped to a concrete outcome: fewer scary prompts for end users. That advantage is now gone. Under changes to the Microsoft Trusted Root Program Requirements, Microsoft stopped recognizing EV code-signing certificates in early 2024 and removed the EV code-signing identifiers from its trusted roots later that year, so EV and OV code-signing certificates now build reputation the same way. It is a useful illustration of how quickly a tier’s real-world payoff can change. Keep the accounting honest and short. Beyond a few items like these, the tier does not do much more than DV does.
What converged: certificate lifetimes
If you last evaluated validation levels several years ago, one more differentiator has quietly closed. Certificate lifetimes are collapsing across the board. The industry is on a path toward a 47-day maximum lifetime, part of a broader shift toward certificate management agility as a core PKI discipline. Crucially, the shorter lifetimes apply uniformly across DV, OV, and EV. Validation level no longer earns a certificate a longer life. Lifetime is simply not a lever the tier controls anymore.
How to pick a validation level in practice
Because the tiers share the underlying cryptography and now share lifetimes, choosing one is less a security-posture decision than a requirements question. Ask three things:
- Does issuance need to automate?
High-volume, short-lived certificates favor DV, which issues in minutes and slots cleanly into automated workflows. Heavier identity vetting is harder to fully automate. - Does anything downstream consume the identity fields?
If tooling, partners, or internal policy read the verified organization data out of the certificate, OV or EV earns its place. If nothing reads it, you are paying for data no one uses. - Does a compliance regime or contract name a tier?
If a requirement specifies OV or EV, that answer overrides the rest.
Answer those and the level tends to select itself. Match the certificate to your site’s purpose, risk profile, and trust needs, and reframing that around concrete requirements keeps the decision grounded rather than aspirational.
How Keyfactor helps you manage validation levels at scale
The throughline of this piece is that identity data lives in the certificate regardless of what the browser shows, and that some tiers carry real compliance weight. Both facts turn into operational work the moment you have more than a handful of certificates, and most teams run dozens or hundreds across their environments.
That is where certificate lifecycle management earns its keep. Discovery and inventory surface every certificate you actually have, along with which tier and which identity fields each one carries, so you are not guessing. Automated discovery builds an accurate record of your certificates so you can head off costly, disruptive outages, closing the visibility gap that grows as certificate counts climb. Lifecycle automation then handles issuance and renewal across DV, OV, and EV, which matters more than ever now that lifetimes are shrinking toward 47 days and manual tracking has become a liability. Finally, policy enforcement makes sure the right tier is used where a regime or contract names one, so a compliance requirement does not quietly become an audit finding.
The point is not more features. It is knowing what you have, keeping it current, and proving the right validation level is in the right place.
Keyfactor gives security teams visibility
and control over the identities
and cryptography that secure every
digital interaction, so your business
keeps running—uninterrupted.
Got SSL/TLS certificate validation questions? We’ve got answers.
All three use the same cryptography and chain validation. They differ only in what the certificate authority verifies before signing: DV confirms control of the domain, OV adds a verified legal entity, and EV adds incorporating-agency, address, phone, requester authorization, and two-person issuance checks.
Yes. Chrome removed the EV name indicator in version 77 and Firefox in version 70, with Safari having dropped it earlier. The identity information still lives inside the certificate; browsers simply stopped surfacing it in the address bar.
No. It is a procedural distinction. Key types, chain math, and the TLS handshake are identical across tiers. What varies is the evidence the CA collected, so a higher tier means more identity vetting, not stronger cryptography.
Inspect the certificate with a tool like OpenSSL and look at the subject DN fields and the policy OID in certificatePolicies. EV recognition comes from a root-to-OID mapping the relying party ships, not from anything self-describing in the certificate.
It can. The identity data is available to anything that parses certificates, the misissuance bar is marginally higher, and some contracts or regulations mandate a specific tier. EV code signing was historically the strongest case, when Microsoft SmartScreen reputation favored EV-signed software, though Microsoft phased out that distinct treatment beginning in 2024.
No. Wildcard, single-domain, and multi-domain (SAN) describe scope, or how many names a certificate covers. Scope is chosen independently of validation level (DV, OV, or EV).
Not anymore. With maximum lifetimes converging uniformly toward 47 days, lifetime is no longer a differentiator between DV, OV, and EV.
Treat it as a requirements question: does your issuance need to automate, does anything downstream consume the certificate’s identity fields, and does a compliance regime name a tier? Answer those and the level follows.