SSL Certificate Types: DV vs OV vs EV, Certificate Chains, and Preventing Expiry Outages

SSL certificates are not all the same — and the differences matter more than the padlock

The padlock in your browser's address bar confirms the connection is encrypted. It doesn't confirm anything about who you're connected to or whether the website is trustworthy. A phishing site can have a padlock. A legitimate enterprise site can have either the same padlock or a certificate with substantially more validation behind it.

Understanding certificate types, what they actually verify, how the certificate chain works, and how to avoid expiry-related outages turns SSL from "thing the IT team handles" into something you can evaluate and manage properly.

The three certificate validation levels

Domain Validation (DV)

DV certificates confirm that the certificate applicant controls the domain. That's it. The CA verifies control by asking the applicant to:

• Add a specific DNS TXT record
• Place a specific file at a specific URL
• Respond to a challenge email sent to the domain's WHOIS contacts

What DV proves: you can add DNS records or files to the domain. Nothing about who you are, where you're located, or whether the site is legitimate.

Who issues them: all CAs, including Let's Encrypt (free, automated), ZeroSSL, Sectigo.

Who uses them: the vast majority of websites. DV is appropriate for most purposes — it encrypts the connection, which is the primary security goal.

Typical cost: $0–$100/year. Let's Encrypt DV certificates are free and industry-standard.

Organisation Validation (OV)

OV certificates include verified organisation information — the CA confirms the legal existence of the organisation and verifies business records before issuing.

What OV proves: the organisation applying for the certificate is a real, verified legal entity. The certificate includes organisation name, country, and verified details.

Visible where: in the certificate details (not in the browser UI's address bar by default — you'd see it by clicking "Certificate" in the security panel).

Who uses them: businesses that want to include verified organisation identity in the certificate. More expensive and slower to issue than DV.

Typical cost: $100–$500/year.

Extended Validation (EV)

EV involves the most rigorous identity verification — business registration, physical address, legal entity, operational existence, and authorised requester identity are all verified.

What EV proved: historically, EV triggered a green address bar in browsers with the organisation name prominently displayed. This was removed by Chrome in 2019 and Firefox in 2020 — both decided the UI change wasn't improving security because most users didn't notice or understand it.

Current state: EV certificates still exist and still contain verified organisation data, but the prominent browser UI treatment is gone. The certificates appear identically to DV in most browsers.

Practical value today: debated. Some security-conscious organisations still use them for the verified identity in certificate inspection, but the consumer-visible distinction is largely gone.

Single domain, wildcard, and SAN certificates

Single domain: covers exactly one domain — example.com. Does not cover www.example.com unless explicitly included.

Wildcard: covers a domain and all its direct subdomains — *.example.com covers www.example.com, api.example.com, mail.example.com, but not sub.sub.example.com or example.com itself.

SAN (Subject Alternative Names) / Multi-domain: lists multiple specific domains on one certificate — example.com, example.co.uk, otherbrand.com. A SAN certificate for a handful of domains is often more cost-effective than multiple single-domain certificates.

Let's Encrypt issues SAN certificates with up to 100 domains per certificate, all at no cost.

The certificate chain

SSL certificates don't exist in isolation. They form a chain of trust:

Root CA (in browser's trusted store)
  └─ Intermediate CA (issued by Root CA)
       └─ Your certificate (issued by Intermediate CA)

Browsers trust a set of root CAs pre-installed in the operating system or browser. Root CAs don't sign server certificates directly — they sign intermediate CAs, which sign server certificates. This protects root CA private keys (kept offline) and enables CA hierarchy management.

What goes wrong with chains:

Missing intermediate certificate: your server must send the intermediate certificate alongside the server certificate. If the intermediate is missing from the server's configuration, some clients (particularly older ones without cached intermediates) fail to verify the chain and show a certificate error — even though the certificate itself is valid.

Expired intermediate: intermediates have their own expiry dates. If a CA's intermediate expires, all certificates signed by it fail validation until reconfigured.

Wrong chain order: certificates in the chain should be ordered from server certificate → intermediate → (root, which may be omitted). Wrong order causes some SSL implementations to fail.

Certificate Transparency Logs

Since 2015, all publicly trusted CAs are required to log every certificate they issue to Certificate Transparency (CT) logs — public, append-only records of all certificates. This enables:

Monitoring for misissued certificates: if an attacker convinces a CA to issue a certificate for your domain, it appears in CT logs. Services like crt.sh, Google's CT Log Monitor, and various commercial services let you monitor for any certificate issued for your domain.

Discovery of shadow IT certificates: organisations often find unmanaged certificates for their domains — issued by developers for test environments and forgotten — via CT log monitoring.

Security research: CT logs provide a historical record of all certificates ever issued for a domain, useful for investigating past infrastructure and finding historical patterns.

Check CT logs for your domain at crt.sh — you may find certificates you didn't know existed.

Preventing expiry-related outages

SSL certificate expiry is one of the most preventable causes of website and API outages. High-profile expiry incidents have taken down major services.

Let's Encrypt and ACME automation is the modern solution for most use cases. The ACME protocol automates certificate issuance and renewal — certificates are automatically renewed every 60 days (before the 90-day expiry). Tools: Certbot, Caddy (built-in), traefik (built-in), AWS Certificate Manager (for AWS resources), Cloudflare (for sites proxied through Cloudflare).

For non-ACME environments:

• Set calendar reminders at 60 and 30 days before expiry
• Use monitoring services that alert on upcoming expiry (many SSL checkers offer email alerts)
• Track all certificates in a certificate inventory spreadsheet or dedicated certificate management tool

How to use the SSL Checker on sadiqbd.com

1. Enter the domain
2. Check — the tool establishes an SSL connection and inspects:
   • Certificate validity (valid dates, not expired)
   • Certificate subject (what domain it covers)
   • SAN entries (additional domains covered)
   • Issuer and CA chain
   • Chain completeness (intermediate certificates present)
   • Days until expiry — with a clear warning zone

Run this for any domain before and after certificate changes, and periodically as a monitoring check.

Frequently Asked Questions

Is Let's Encrypt as secure as paid certificates? For encryption: identical. Let's Encrypt uses 2048-bit RSA or ECDSA keys, the same algorithms as paid DV certificates from commercial CAs. The encryption strength doesn't differ. The only difference is the DV-only validation (no OV or EV options) and 90-day validity (vs. up to 2 years for paid certs).

Why is a 90-day Let's Encrypt cert better than a 2-year paid cert? From a security standpoint, shorter certificate lifetimes limit the window of exposure if a private key is compromised. Automation makes 90-day certificates essentially zero-maintenance. The industry is moving toward shorter validity periods — Apple's browser trust restrictions already cap certificate validity at 398 days.

What does "certificate chain incomplete" mean? Your server isn't sending the intermediate CA certificate alongside your server certificate. Clients that haven't cached the intermediate (common in some environments, particularly mobile apps and server-to-server API calls) will fail certificate validation. Fix by adding the intermediate certificate to your server's certificate bundle.

Is the SSL Checker free? Yes — completely free, no sign-up required.

Certificate management is one of those areas where a small amount of proactive attention prevents significant outages. The checker gives you visibility into validity, chain completeness, and expiry timeline in one place.

Try the SSL Checker free at sadiqbd.com — verify certificate validity, expiry dates, and chain completeness for any domain instantly.