DV, OV and EV certificates: what validation actually buys

The types of SSL certificate differ in what the authority checked before signing, and in what it may then write into the certificate. Encryption does not change with the type. The CA/Browser Forum's Baseline Requirements define four types and state that all of them give the same assurance about the domain name ^[1].

For a website, the question is whether anything outside the browser asks for a named organisation; browsers no longer show visitors the difference.

Types

Domain Validated (DV), Individual Validated (IV), Organization Validated (OV), Extended Validation (EV) ^[1]

Type marker

policy identifier 2.23.140.1.2.1 DV, 2.23.140.1.2.3 IV, 2.23.140.1.2.2 OV, 2.23.140.1.1 EV (§7.1.6.1) ^[1]

Wildcard names

in DV, IV and OV; in EV only for .onion names (EV Guidelines §7.1.2.1) ^[2]

Address bar

no EV badge since Chrome 77 and Firefox 70 ^[3][5]

The four types of SSL certificate

Every publicly trusted SSL certificate belongs to one of four types, and the type decides which subject fields the certificate may carry.

Subject fields and identifiers of each type: §7.1.2.7.2 to §7.1.2.7.5 ^[1]; the EV subject: EV Guidelines §7.1.4.2 ^[2].

What each check involves

• Domain validation asks one question: can the applicant show control of this name? Placing a file where the name serves it, or publishing a record in its DNS, answers it (§3.2.2.4). These are the checks behind automatically issued certificates. If a DV certificate carries a country, the authority verifies it from the IP address range, the ccTLD, the registrar's data or an organisation check (§3.2.2.3) ^[1].

• Individual validation is the fourth type of SSL certificate, for a person rather than an organisation. The authority checks the person's name against a government-issued photo ID, checks their address, and names that person in the certificate (§3.2.3, §7.1.2.7.3) ^[1].

• Organisation validation adds checks about the entity behind the request. The authority verifies its identity and address through a government agency, a reliable third-party database, a site visit or an attestation letter (§3.2.2.1) ^[1]. The organisation's name appears in the certificate.

What the EV Guidelines add

Extended validation is the one type with its own CA/Browser Forum document, the EV Guidelines, version 2.0.4. Before issuing an EV SSL certificate, the authority verifies:

1. 1. the applicant's legal existence and identity;

2. 2. its physical existence, at a business address that is not a mail drop or P.O. box;

3. 3. its operational existence, meaning business activity;

4. 4. its control of each domain name, by a method of the Baseline Requirements;

5. 5. a reliable means of communication with it;

6. 6. the name, title and authority of the people who sign and approve the request.

That is §3.2.2.1.1, with the address rule in §3.2.2.4.1. Four kinds of applicant qualify: private organisations, government entities, business entities and non-commercial entities (§4.1.1). The certificate then names the subject's full legal name, its business category, its jurisdiction of incorporation, its registration number and the address of its place of business (§7.1.4.2) ^[2].

What browsers show

Browsers used to mark extended validation certificates in the address bar, with the organisation's name beside the URL. Chrome moved that badge into Page Info, the panel behind the icon left of the address, in Chrome 77; Chrome's note records that Safari had made a similar change with iOS 12 and macOS 10.14 ^[3]. Firefox moved it into the identity popup behind the lock icon in Firefox 70 ^[5].

Chrome's security team gave its reason: in its own research and in earlier academic work, users did not appear to make secure choices, such as not entering a password or card details, when the EV badge was changed or removed ^[3].

Chrome's team then announced, for Chrome 117, that the lock icon itself would give way to a neutral "tune" icon, because people read the lock as a sign that a site is trustworthy ^[4].

The address bar now looks the same for DV, OV and EV certificates. The organisation details remain inside the certificate, one click away in Page Info or the identity popup, and in the subject fields shown further down this page.

Does validation level affect security?

Not the security of the connection. The Baseline Requirements say so directly: the types vary in subject information, yet all of them "provide the same level of assurance of the device identity", meaning the domain name or IP address (§7.1.2.7.1) ^[1]. The same section gives all four types a common profile with three exceptions: the subject name fields, how those fields are validated, and the contents of the certificatePolicies extension.

• Connection security is identical across all of them. A browser accepts a certificate of any type the same way, by following its certificate chain up to a trusted root.

• Identity assurance does differ. Organisation validation and extended validation put an organisation the authority verified into the certificate; domain validation puts none.

Where that assurance matters, a process reads it rather than a visitor: a compliance framework, a customer's procurement process, an internal policy, a contract that names a validation level. Those are real reasons to pick a type, and none of them is about encryption.

When each is worth it

• Domain validation for public websites, APIs, services on public names and anything issued automatically. It is the default and the right default.

• Organisation validation when something outside the browser requires it by name. Choosing it in the hope that visitors will notice is choosing it for a reason that stopped applying.

• Individual validation on the same terms, when the requirement is a named person rather than a company.

• Extended validation where a requirement names it specifically. Its extra checks are real; its extra visibility in the browser is gone.

Bridge SSL, the certificate layer of Bridge CDN, issues domain-validated certificates. Organisation and extended validation are not part of it, and a certificate you already hold cannot be uploaded ^[8]. If a requirement names OV or EV, the SSL certificate comes from an authority that offers that type and goes on a server you manage; the steps for nginx, Apache and IIS are under installing a certificate.

Validation and coverage are separate choices

Coverage is the second axis: how many names one certificate serves. A single name, an explicit list of names described on SAN certificates, or one level of subdomains described on wildcard certificates. Every certificate has a position on both axes, so "a wildcard or an OV certificate?" is two questions with separate answers.

The axes cross in one place. An EV certificate cannot hold a wildcard name unless it is a .onion name (EV Guidelines §7.1.2.1) ^[2]. DV, IV and OV share the Baseline Requirements profile, which allows a wildcard name once the authority has run its wildcard checks (§3.2.2.6, §7.1.2.7.12) ^[1]. A wildcard certificate that names an organisation cannot be EV.

How to tell which type a certificate is

Read its policy identifier. The Baseline Requirements make each certificate type carry its own identifier in the certificatePolicies extension, exactly one of them per certificate (§7.1.2.7.2 to §7.1.2.7.5, §7.1.2.7.9) ^[1]. RFC 5280 defines that extension as a list of policy OIDs; in a server certificate they indicate the policy under which it was issued (§4.2.1.4) ^[6]. To read them from a live site's SSL certificate:

openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null \
  | openssl x509 -noout -subject -ext certificatePolicies

The output below comes from three lab certificates signed by our own test root, each with the subject fields and the policy identifier of one type, read with OpenSSL 3.0 ^[9]:

$ openssl x509 -in dv.pem -noout -subject -ext certificatePolicies
subject=
X509v3 Certificate Policies: 
    Policy: 2.23.140.1.2.1
$ openssl x509 -in ov.pem -noout -subject -ext certificatePolicies
subject=C = GB, L = London, O = Example Ltd
X509v3 Certificate Policies: 
    Policy: 2.23.140.1.2.2
$ openssl x509 -in ev.pem -noout -subject -ext certificatePolicies
subject=businessCategory = Private Organization, jurisdictionC = GB, serialNumber = 00000000, C = GB, L = London, O = Example Ltd
X509v3 Certificate Policies: 
    Policy: 2.23.140.1.1

Reading the output

An empty subject= with 2.23.140.1.2.1 under Certificate Policies is a DV certificate: it names no person or organisation. With an empty subject the Subject Alternative Name extension must be marked critical (§7.1.2.7.12), and openssl x509 -in dv.pem -noout -ext subjectAltName on the lab certificate prints X509v3 Subject Alternative Name: critical. An O = entry names the organisation; businessCategory, jurisdictionC and serialNumber belong to the subject of an extended validation certificate.

An authority may add identifiers of its own to its certificates, documented in its policy, next to the CA/Browser Forum one (§7.1.2.7.9) ^[1]. The CA/Browser Forum identifier is the one that names the type.

Why the industry moved to domain validation

The shift was not a lowering of standards.

Organisation checks run on documents, registries and people who sign, and that kept them out of automated issuance. Let's Encrypt states that it offers only DV certificates, and not OV or EV, primarily because it cannot automate issuance for those types ^[7]. Once encryption became the baseline for every site, paperwork per certificate could not follow it to every personal site, internal tool and short-lived environment. Automated domain validation removed that constraint, and a free certification authority works on exactly that model.

The trade was deliberate: less assurance about who is behind a site, in exchange for encryption on all of them. The assurance sat in a badge that, by Chrome's research, did not change what users did ^[3], and unencrypted connections were the more concrete harm.

What none of them verify

The levels invite an assumption they do not support.

The EV Guidelines spell it out for the strictest type. An extended validation certificate is not intended to assure that the subject is actively doing business, complies with the law, is trustworthy, honest or reputable, or that it is safe to do business with (§1.4.2). Certificates of the other types check less and promise no more. An organisation can be thoroughly verified and still run something you would not want to use.

Nor does any level protect against a certificate obtained by someone who took control of the domain improperly. Even under the EV Guidelines, the authority confirms control of each name at the time of issue (§3.2.2.7.1) ^[2], a statement about that moment and not a continuing guarantee.

FAQ

Sources

1. CA/Browser Forum, Baseline Requirements for the Issuance and Management of Publicly-Trusted TLS Server Certificates, version 2.3.1: §3.2.2.1, §3.2.2.3, §3.2.2.4, §3.2.2.6, §3.2.3, §7.1.2.7.1 to §7.1.2.7.5, §7.1.2.7.9, §7.1.2.7.12, §7.1.6.1.

2. CA/Browser Forum, Guidelines for the Issuance and Management of Extended Validation Certificates, version 2.0.4: §1.4.2, §3.2.2.1.1, §3.2.2.4.1, §3.2.2.7.1, §4.1.1, §7.1.2.1, §7.1.4.2.

3. Chromium, EV UI Moving to Page Info (docs/security/ev-to-page-info.md).

4. Chromium Blog, An Update on the Lock Icon.

5. Mozilla, Firefox 70.0 release notes: Improved privacy and security indicators.

6. IETF, RFC 5280, X.509 certificate and CRL profile: §4.2.1.4.

7. Let's Encrypt, FAQ: What services does Let's Encrypt offer?

8. Bridge SSL, home page (What it costs; What this deliberately does not do) and llms.txt (What is not included).

9. Our runs: OpenSSL 3.0.13 on Linux, three lab certificates issued by a local test root.

10. Google Search Central Blog, HTTPS as a ranking signal.