SSL certificate types compared (DV vs OV vs EV, wildcards, multi-domain)

Not all SSL/TLS certificates are the same. The type of certificate you choose determines how it is validated, what identity information it contains, and which domains it covers. Choosing the wrong type for your use case wastes money; choosing no certificate (or letting one expire) breaks your site for every visitor.

This article compares certificate types across two dimensions: validation level (DV, OV, EV) and coverage scope (single-domain, wildcard, multi-domain SAN).

Validation level: DV, OV, EV

The validation level describes how thoroughly the Certificate Authority (CA) verified the requester's identity before issuing the certificate. Higher validation does not affect encryption strength — TLS encryption is the same regardless of certificate type — but it determines what identity information the certificate contains and how much the CA has verified about the organisation behind it.

	DV	OV	EV
Stands for	Domain Validation	Organisation Validation	Extended Validation
Validation effort	Automated domain control check only	Manual review of business registration documents	In-depth manual review — legal existence, operational existence, contact verification
What is verified	You control the domain	Organisation name, address, legal existence	Full organisation identity, jurisdiction of incorporation, authorised agents
Browser indicator	Padlock only	Padlock only (org details in cert, not in UI)	Padlock only (EV green bar was removed from major browsers in 2019)
Issue speed	Minutes to hours	1–3 business days	1–5 business days
Typical cost	Free (Let's Encrypt) to ~$100/year	$100–$400/year	$200–$700+/year
Ideal use	Blogs, internal tools, most web apps, APIs	Business websites, SaaS products, B2B applications	High-trust e-commerce, financial services, healthcare

Domain Validation (DV)

DV is the simplest and fastest certificate type. The CA only verifies that you control the domain — no organisation identity is checked. Verification happens automatically by one of three methods:

• Email validation — the CA sends a verification email to a standard address (admin@, webmaster@, hostmaster@, etc.) at the domain.
• DNS validation — you create a specific TXT or CNAME record that the CA looks up to confirm control.
• HTTP validation — you place a specific file at a well-known URL under the domain.

DV certificates are entirely appropriate for the vast majority of web properties. The padlock in the browser address bar looks identical to an EV certificate from the user's perspective. The encryption is the same. The only difference is what the certificate says about the organisation behind the site — which most users never check.

Organisation Validation (OV)

OV certificates require the CA to verify your organisation's legal existence, physical address, and that the person requesting the certificate is authorised to do so. This involves reviewing business registration documents (Companies House, state registries, etc.) and may include a phone call to a verified business number.

The verified organisation name is embedded in the certificate's Subject field. Browser UIs do not prominently display this information — users cannot see it without clicking into certificate details. OV certificates are useful for organisations that want the extra assurance in the certificate itself, particularly for B2B contexts where technical users may inspect certificates.

Extended Validation (EV)

EV certificates go furthest in verifying identity: the CA confirms the organisation's legal existence, operational existence, jurisdiction of incorporation, and authorises specific individuals to request certificates. The process is more rigorous than OV and typically takes several days.

Until 2019, EV certificates displayed the organisation name in a green bar next to the padlock in Chrome, Firefox, and Safari. All major browsers removed this indicator — EV certificates now show a padlock identical to DV. The security benefit of EV at the browser level is therefore effectively zero for end users.

EV certificates still have value in specific contexts: PCI-DSS compliance documentation, internal security policies that require EV, and some legacy enterprise software that checks for EV certificates. For most organisations, OV provides a reasonable middle ground between automated DV and the cost and overhead of EV.

Coverage: single-domain, wildcard, multi-domain (SAN)

The coverage scope determines which hostnames a certificate is valid for.

	Single-domain	Wildcard	Multi-domain (SAN)
What it covers	Exactly one hostname (and optionally www.)	One hostname level across all subdomains of a domain	Up to ~100 hostnames in a single certificate
Example	example.com, www.example.com	*.example.com (covers app.example.com, mail.example.com, etc.)	example.com, api.example.com, example.io, shop.example.net
Subdomain support	No	Yes — one level deep only	Yes — any combination
Multiple root domains	No	No	Yes
Certificate management	Simple — one cert per hostname	Moderate — one cert, many subdomains	Complex — many hostnames in one cert
Wildcard for sub-subdomains	No	No (*.example.com does not cover a.b.example.com)	Yes, with explicit SAN entries

Single-domain certificates

A single-domain certificate covers exactly one hostname. Most CAs include the bare domain and the www. variant automatically (e.g. example.com and www.example.com). Single-domain certificates are the simplest to manage and the default for Let's Encrypt.

Wildcard certificates

A wildcard certificate covers *.example.com — one level of subdomains. It covers app.example.com, api.example.com, and mail.example.com, but it does not cover example.com itself or a.b.example.com (two levels deep). Many CAs issue a wildcard alongside the bare domain in the same certificate.

Wildcards are useful when you have many subdomains that appear or disappear dynamically (e.g. customer-specific subdomains: customer1.example.com, customer2.example.com). The trade-off is that the private key is shared across all subdomains — a compromise of one subdomain's server compromises the certificate for all subdomains.

Wildcard DV certificates from Let's Encrypt require DNS validation (not HTTP validation) and can be automated with tools like certbot's DNS plugins.

Multi-domain (SAN) certificates

Subject Alternative Names (SAN) allow a single certificate to cover multiple hostnames, including entirely different root domains. A SAN certificate might cover example.com, example.io, api.example.com, and shop.example.net — all in one certificate.

SAN certificates are useful for organisations managing multiple domains or brands from the same infrastructure. The downside is operational complexity: adding or removing a hostname requires reissuing the entire certificate.

Free vs paid SSL

When free Let's Encrypt DV is the right choice:

• Blogs, personal sites, developer tools, internal applications
• Any web property where automated certificate management is possible
• APIs and services where users will not inspect certificate details
• The overwhelming majority of websites

Let's Encrypt issues 90-day DV certificates at no cost. The short validity encourages automation (certbot, cert-manager, Caddy, AWS Certificate Manager, etc.) which in practice means fewer expired certificates — not more.

When a paid certificate adds value:

• OV or EV for compliance documentation — some PCI-DSS, HIPAA, or enterprise procurement requirements specify OV or EV certificates. A paid CA provides the verification record.
• Longer validity for legacy systems — some embedded systems, IoT devices, or legacy enterprise software have difficulty with 90-day renewal cycles. Paid CAs offer 1-year certificates.
• Dedicated support and warranty — paid CAs offer SLAs and certificate warranties (a financial guarantee that rarely matters in practice but is required by some procurement processes).
• EV for internal policy requirements — if your security policy requires EV and you cannot change the policy, you need EV.

For most organisations running modern infrastructure with automated certificate management, the practical difference between free DV and paid OV/EV comes down to compliance documentation and organisational policy, not security or user-visible indicators.

What to monitor regardless of cert type

Certificate type does not affect what can go wrong operationally. Every certificate — DV, OV, EV, wildcard, or SAN — can expire, have a broken chain, or be misconfigured.

DomainCare's SSL check monitors your certificate regardless of type:

• Expiry warnings at 60, 30, 15, and 7 days remaining, giving you time to renew before visitors see browser errors.
• Chain validity — a missing or incorrect intermediate certificate causes TLS handshake failures for some clients even when the leaf certificate is valid.
• Hostname mismatch — the certificate does not cover the domain it is being served on.
• Deprecated protocols — TLS 1.0 and 1.1 are flagged as warnings; they are disabled by all major browsers.
• Weak cipher suites — RC4, DES, and other weak ciphers are flagged separately.

Automation reduces but does not eliminate certificate incidents. Let's Encrypt renewals fail when DNS is misconfigured; cert-manager has bugs; deployment pipelines can push stale certificates. Monitoring gives you the signal to act before visitors hit browser security errors.

---