Apprendre
SSL Certificate Types: DV, OV, EV, Wildcard and SAN
Two independent axes get confused constantly: how thoroughly the authority checked who you are, and how many hostnames the certificate covers. They have nothing to do with each other.
Lancez un audit DomainLens frais et utilisez le rapport comme liste de priorités.
Two separate questions
Validation level answers "how much did the authority verify about the applicant". Coverage answers "which hostnames does this certificate secure". You choose one from each, and the encryption is identical in every combination.
| Validation | What is checked | Issued in |
|---|---|---|
| DV — Domain Validated | Control of the domain only | Minutes, automated |
| OV — Organisation Validated | Domain plus a real registered organisation | Days |
| EV — Extended Validation | Extensive legal and operational checks | Days to weeks |
EV no longer does what it was sold for
EV certificates were bought for the green address bar showing the company name. Chrome removed that treatment in 2019 and Firefox followed. Today an EV certificate looks identical to a free DV one in every mainstream browser: a plain padlock.
The encryption was always identical. What EV bought was a visual signal, and that signal no longer exists — so for most sites the case for EV has quietly disappeared. It survives where a compliance requirement names it.
Wildcard versus SAN
A wildcard covers exactly one level: *.example.com secures blog.example.com but not deep.blog.example.com, and it does not secure example.com itself. That last point surprises people regularly — the apex needs its own entry, which is why wildcards are almost always issued alongside a SAN for the bare domain.
A SAN certificate lists hostnames explicitly, so adding one means reissuing. That is fine for a stable set and painful for a platform creating subdomains on demand.
| Type | Covers | Good for |
|---|---|---|
| Single | One hostname | A site with no subdomains |
| Wildcard | *.example.com — one level only | Many subdomains, unknown in advance |
| SAN / multi-domain | A named list of hostnames | A few known hosts, possibly different domains |
| Wildcard plus SAN | The apex and everything below it | The common real-world case |
Choosing without overthinking it
A wildcard concentrates risk: one private key covering every subdomain means a single compromise exposes all of them. Where the subdomain set is small and known, separate certificates are the safer choice. For issuing them see certbot and Let's Encrypt .
- A normal site with a handful of hostnames — DV with a SAN list, issued free and automatically.
- A platform generating customer subdomains — DV wildcard, which needs DNS validation.
- A regulated environment whose policy names OV or EV — buy what the policy requires.
- An e-commerce site — DV is sufficient; EV no longer displays anything a customer can see.
- Internal services behind a proxy — a private CA or a provider origin certificate, not a public one.
How DomainLens contributes
DomainLens reports the issuer and validity of the certificate a host presents, which is how you confirm the certificate in use is the one you think you bought. Check any host with the SSL checker , and see SSL certificate expired for the failure mode that matters most.
- Is EV worth paying for?
- For most sites, no. Browsers removed the visual distinction in 2019, so an EV certificate now looks identical to a free DV one. It remains relevant only where a compliance requirement names it.
- Does a wildcard cover the root domain?
- No. *.example.com does not secure example.com itself, which is why wildcards are normally issued together with a SAN entry for the bare domain.
- Does the certificate type affect SEO?
- No. Google checks that the connection is secure and nothing about who issued the certificate or how thoroughly the applicant was vetted.
- Wildcard or SAN?
- Wildcard when subdomains are created dynamically and you cannot enumerate them. SAN when the list is short and stable, since it avoids one key covering everything.