What are DV, OV, and EV certificates?

DV, OV, and EV certificates differ in what the certificate authority verified before issuing — and in nothing else. DV (domain validation) proves control of the domain, checked automatically via DNS or HTTP challenges. OV (organisation validation) adds a manual check that the requesting company exists, putting its name in the certificate subject. EV (extended validation) applies a stricter, audited version of that vetting under the CA/Browser Forum’s EV Guidelines. The cryptography — the keys, the ciphers, the encryption strength — is identical across all three.

The market history matters because much of the sales copy has outlived the facts. EV once bought visible browser treatment: the company name rendered in green next to the padlock. Browsers measured whether users noticed its absence, concluded they did not, and removed the indicator — Chrome and Firefox dropped it in 2019. Today a visitor sees exactly the same UI for a free DV certificate as for an EV certificate, and the company name in an OV or EV certificate is visible only to someone who opens the certificate details by hand.

What remains true: automation favours DV, and the ecosystem favours automation. DV issuance is the only kind that works unattended through ACME, which is why free CAs issue DV exclusively and why shortening certificate lifetimes push everything that can be DV toward DV. OV and EV persist where a policy demands a verified organisation identity in the certificate — some procurement rules, some financial-sector requirements, some legacy compliance checklists — and their manual vetting step is precisely what makes them awkward to renew on short cycles.

The decision rule is short. If no external policy names OV or EV, use DV and spend the savings on monitoring and automation. If a policy does, treat the manual validation step as an operational risk to schedule around, because it does not compress the way automated renewal does.