SSL Certificate Types Explained: DV, OV, EV, Wildcard and SAN

Certificate vendors sell a confusing menu: domain validated, organization validated, extended validation, wildcard, multi-domain, "multi-year" plans. Most of it comes down to two independent questions. How much identity checking did the certificate authority (CA) do? And which hostnames does the certificate cover? This guide separates the two, explains what visitors actually see, and clears up the lifetime rules, which have changed a lot and are still changing.

Two axes: validation level and name coverage

Validation level describes what the CA verified before issuing:

• DV (Domain Validated): you control the domain. Proven by an automated check, such as a file served over HTTP or a DNS TXT record.
• OV (Organization Validated): DV plus a check that a real legal organization exists and is tied to the request. Details of the organization go into the certificate subject.
• EV (Extended Validation): OV with a stricter, more manual vetting process defined by the CA/Browser Forum's EV guidelines.

Name coverage describes which hostnames the certificate is valid for:

• Single name (www.example.com)
• Multiple names via the Subject Alternative Name (SAN) list
• Wildcard (*.example.com)

Any validation level can be combined with any coverage type, though some combinations are not offered by every CA. For example, EV wildcards are not allowed by the EV guidelines.

DV, OV and EV: what changes for the visitor

Encryption strength is identical across all three. A DV certificate and an EV certificate use the same TLS protocol, key sizes and ciphers. The difference is purely about identity information inside the certificate.

Years ago browsers displayed a green bar with the company name for EV. Major browsers have since removed that treatment, so a visitor sees nearly the same interface for all three. The identity details are still there if someone opens the certificate viewer, and some enterprises, banks and procurement policies still require OV or EV for their own reasons. For a typical blog, SaaS app or online shop, DV is the correct choice, and it is what Let's Encrypt and most hosting platforms issue.

Wildcard certificates

A wildcard covers one label of subdomain: *.example.com matches shop.example.com and api.example.com, but not example.com itself and not a.b.example.com. Most wildcard certificates therefore list both *.example.com and example.com as SAN entries.

Advantages: one certificate for many current and future subdomains, and no need to reissue when you add staging.example.com.

Trade-offs worth weighing:

• Blast radius. The private key now protects every subdomain. If it leaks from any server, an attacker can impersonate any name under the domain. Copying one wildcard key to many hosts multiplies that risk.
• Validation method. Wildcards require DNS-based validation for domain control (for example _acme-challenge TXT records), which means your automation needs DNS API access. See Let's Encrypt renewal failures for how that goes wrong.
• Hidden names. Certificates are logged in public Certificate Transparency logs. Individual hostnames in a SAN list are visible there, which can reveal internal naming. A wildcard hides the specific subdomains, which is a mild privacy benefit.
• It does not cover everything. Two-level names such as a.b.example.com need their own wildcard or SAN entry.

SAN (multi-domain) certificates

Every modern certificate is technically a SAN certificate. Browsers ignore the old Common Name field and look only at the SAN list, which can contain DNS names, IP addresses in special cases, and more. A multi-domain certificate puts several unrelated names in one certificate, such as example.com, www.example.com and example.org.

This is convenient for a single server hosting a few sites, and it simplifies renewal to one operation. The downside is coupling: if you add or remove one name you reissue the whole certificate, and all names share one expiry and one private key. Large SAN lists also make the certificate bigger, which has a tiny effect on handshake size.

Check what your certificate really covers with:

echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null \
  | openssl x509 -noout -ext subjectAltName -dates -issuer

The SSL checker shows the same SAN list, issuer and expiry in the browser.

Certificate lifetimes: what is true now

The "multi-year certificate" is a relic. Maximum lifetimes for publicly trusted TLS certificates were reduced step by step by the CA/Browser Forum, which sets the baseline rules that browsers enforce:

• Before 2015, certificates could be valid for five years or more.
• From 2018, the limit was 825 days (about 27 months).
• From September 1, 2020, the limit dropped to 398 days (about 13 months), and browsers began rejecting certificates issued later with longer validity.
• Under the Forum's 2025 ballot (SC-081v3), the maximum shrinks further in stages: 200 days for certificates issued from March 15, 2026, 100 days from March 15, 2027, and 47 days from March 15, 2029. Domain-control validation results can be reused for shorter periods as well, so CAs will re-check control of your domain more often.

Since today is October 2026, the 200-day limit is already in force for newly issued certificates. Always check the CA/Browser Forum's current Baseline Requirements and your CA's announcements for the authoritative text, because these schedules are the kind of thing that gets amended.

What about "3-year" and "2-year" plans being sold?

Vendors still sell multi-year plans, and the way they work is that you pay once but the CA issues a series of shorter certificates under that subscription. You must reissue and install a new certificate before each one expires, either manually or via an automated client. A multi-year plan therefore never meant a certificate that works for years, and as lifetimes fall, the plan is mostly a billing convenience. If a plan promises "one install for three years", check how the vendor expects renewal to be delivered.

Why shorter is better

Short lifetimes limit how long a stolen key or a mis-issued certificate remains useful, because revocation checking in browsers is unreliable. They also force operators to automate, which removes the "forgot to renew" outage class. The cost lands on anyone still renewing by hand: with 100-day and then 47-day certificates, manual processes will fail sooner or later.

Choosing the right certificate

1. Public website or API, one or a few names: free automated DV via ACME. See how to renew an SSL certificate and automate it.
2. Many subdomains you cannot list ahead of time: wildcard DV, with the key kept on as few hosts as possible, or one certificate per service if you can automate.
3. Contractual or regulatory requirement for a verified organization: OV or EV, from a CA that supports automation if possible.
4. Internal services: a private CA is a better fit than a public certificate, as long as you can distribute the root to your clients.
5. Cloud load balancers and CDNs: use the provider's managed certificate. It renews itself and you never touch the key.

Mistakes to avoid

• Buying EV for the green bar. It no longer exists in major browsers.
• Installing only the leaf certificate. Always serve the full chain; the SSL chain debugger catches this.
• Using one wildcard key on dozens of servers and shared hosting accounts.
• Forgetting the bare domain on a wildcard purchase.
• Tracking expiry in a spreadsheet. Use monitoring, such as the SSL expiry alerts in the uptime monitor, and domain expiry watch for the domain itself.

अगले कदम

• Inspect what you serve today with the SSL checker and note the issuer, SANs and expiry.
• Audit a list of hostnames at once with the bulk SSL checker.
• Confirm supported protocol versions with the TLS version checker.
• Read SSL/TLS certificate errors explained to know what each failure looks like.
• Plan for shorter lifetimes by fixing renewal now: Let's Encrypt renewal failures.

सामान्य प्रश्न

Is a paid certificate more secure than a free one?

No. Encryption is the same. Paid products may add warranty, support, OV or EV identity vetting, or convenience features, but the cryptographic protection of a DV certificate is equal.

Does a wildcard certificate cover the root domain?

Not automatically. *.example.com does not match example.com. Request both names in the same certificate, which most CAs allow.

Can I still buy a certificate that lasts a year?

Not from a publicly trusted CA under current rules. The maximum is now 200 days for newly issued certificates, and it will keep falling. A "one-year" product is really a subscription that issues shorter certificates.

Do DV certificates work for e-commerce checkout?

Yes. The padlock and encryption are the same. Payment compliance standards concern how you handle card data, not which validation level your certificate has.

यह पेज सामान्य जानकारी है, जिसे हमारी संपादकीय टीम ने लिखा है और दस्तावेज़ीकरण बदलने पर अपडेट किया जाता है। सर्वर और प्रदाता अलग-अलग होते हैं, इसलिए बदलाव पहले सुरक्षित तरीके से जाँचें। देखें: संपादकीय नीति और अस्वीकरण.