SSL/TLS certificates split along two axes: how many domains they cover (single, wildcard, or multi-domain) and how thoroughly the issuer checks who you are (DV, OV, or EV). A personal blog needs a cheap single-domain DV certificate. A business with dozens of subdomains wants a wildcard. A company running checkout pages or handling client data should look at OV or EV. Encryption strength doesn’t change between any of these; only the vetting does.
TL;DR:
- Wildcard certificates cannot carry EV validation under current industry rules, limiting their use for high-assurance security needs.
- Using multiple single-domain certificates increases administration but isolates risk if one gets compromised or misconfigured.
- DV certificates are suitable for internal, low-risk sites and can be issued instantly at no cost, while OV and EV are advisable for payment or client data handling.
- Automated renewal via ACME and Let’s Encrypt is essential for avoiding downtime, especially with DV certificates, which are easier to manage this way.
- Proper installation requires including the complete chain and managing private keys securely, with load balancers often centralizing certificate management for better security.
Table of Contents
- SSL certificate types by domain coverage
- Understanding DV, OV, and EV validation levels
- Other certificate types you’ll come across
- How to choose the right certificate for your site
- Installing and managing certificates without breaking your site
- A practitioner’s view on certificate choices for small business
- Sources
- FAQ
SSL certificate types by domain coverage
Every certificate has to specify exactly which hostnames it protects, and that’s where the four main coverage types come in.
A single-domain certificate secures exactly one hostname, such as www.example.com. It won’t cover blog.example.com or example.com without the “www” unless that variant is added separately. This is the cheapest, simplest option, and it suits a standalone site with no subdomains to worry about.
A wildcard certificate covers a base domain and every first-level subdomain under it. A certificate issued for *.example.com protects shop.example.com, mail.example.com, and blog.example.com in one go. The catch is that it stops at one level. It won’t cover dev.shop.example.com, because that’s a second-level subdomain sitting one rung further down, and wildcard certificates can’t carry EV validation under current industry rules.
A multi-domain certificate, often called a SAN certificate (Subject Alternative Name), lists several distinct hostnames on a single certificate, regardless of whether they share a root domain. A business running example.com.au, examplebrand.co, and example-support.com under one company can secure all three with a single SAN certificate rather than juggling three separate ones. Cloudflare’s breakdown of certificate types is a useful reference for how these categories differ in practice.
Some providers combine the two: a multi-domain wildcard, which lists several base domains and applies wildcards to each one. It’s powerful, but it’s also the most expensive and fiddly option to manage, and a mistake in one entry can mean reissuing the whole certificate.
There’s a real trade-off buried in all of this:
- One certificate covering many hosts means one renewal date, one point of failure, and one leaked private key that compromises everything it protects.
- Several single-domain certificates cost more admin time but isolate risk. If one gets compromised or misconfigured, the others are unaffected.
Understanding DV, OV, and EV validation levels
Certificate Authorities issue three validation levels, and the difference is entirely about identity checking, not the strength of the encryption itself.
Domain Validation (DV) only confirms you control the domain, usually via a DNS record or an email to an address at that domain. It’s automated, often issued in minutes, and it’s the cheapest tier. DV suits blogs, internal tools, staging environments, and any site where visitors don’t need proof of who’s actually running it.
Organization Validation (OV) adds a manual check of your registered business details against public records. The issued certificate carries your organisation’s name in its metadata, which some browsers and security tools can display. OV fits a standard business website where you want some verified identity behind the padlock without paying for full EV vetting.
Extended Validation (EV) goes furthest, requiring the CA to verify legal existence, physical address, and operational status through a documented human review process. It takes longer to issue and costs more, but it remains the most rigorous form of third-party identity verification available for a public certificate.
A few things worth pinning down clearly:
- DV, OV, and EV all use the same TLS encryption underneath; a DV certificate on a modern cipher suite is just as cryptographically strong as an EV one.
- Modern browsers no longer show the green address-bar company name that EV certificates used to trigger, which reduced the visible payoff of paying for EV.
- Security experts still frame the choice around risk: DV for low-risk or internal sites, OV or EV for anything handling payments or personal data.
Fast fact: Because browser UI no longer distinguishes EV visually, its value today sits almost entirely in the paper trail it creates, not in what a visitor sees on screen.
Other certificate types you’ll come across
Not every certificate you hear about secures a website, and mixing these up causes genuine confusion.
- Code signing certificates verify that a piece of software came from a named publisher and hasn’t been tampered with since release. Developers distributing installers or drivers need one.
- Client certificates and mutual TLS authenticate a device or user to a server, rather than the other way around. These show up mostly in enterprise access control, VPNs, and machine-to-machine systems.
- S/MIME certificates sign and encrypt individual emails, proving the sender’s identity and protecting message content in transit.
- Self-signed certificates are generated without a public CA and aren’t trusted by browsers by default, which makes them fine for local development but a liability on anything public-facing.
One quick terminology note: “SSL” is technically the older protocol that TLS replaced years ago, but the industry still says “SSL certificate” to mean a modern TLS certificate. Nobody’s actually issuing SSL 3.0 certificates anymore.
How to choose the right certificate for your site
Work through these questions before you buy anything:
- How many hostnames do you actually need to cover? One domain, several subdomains under one root, or several unrelated domains entirely?
- Do your visitors need proof of business identity, or is domain control enough? A checkout page has different stakes than a company blog.
- What’s your budget and how fast do you need issuance? DV certificates can be free and instant through automated issuance; OV and EV cost more and take longer.
- Can you automate renewals? If yes, lean towards DV issued through ACME. If you’re stuck doing it manually, factor that overhead in.
- Do you have the operational capacity to manage this yourself, or would a managed lifecycle service reduce your risk of an expired certificate taking your site offline?
As a rough map: personal sites and internal tools want DV single-domain. Sites with many subdomains under one root want wildcard. Businesses running several distinct domains want SAN. Anything processing payments or sensitive client data justifies OV or, in higher-stakes cases, EV.
Pro Tip: A mixed approach often beats an all-or-nothing choice. Run automated DV certificates across your everyday pages and reserve a separately managed OV or EV certificate for the transactional domain where identity actually matters to the person paying you.
Red flags to avoid: self-signed certificates on a public site, betting your entire domain portfolio on one wildcard when isolating risk matters, and skipping renewal monitoring because “it’s automated” doesn’t mean “it’s unattended.”
Installing and managing certificates without breaking your site
A working installation needs three pieces: the certificate itself, the intermediate chain linking it back to a trusted root, and the private key. Missing the intermediate chain is the single most common cause of “certificate not trusted” errors, even when the certificate itself is perfectly valid.
Renewal is where most outages actually happen, not issuance. Automating renewal through ACME and Let’s Encrypt removes the human forgetfulness factor for DV certificates, though EV renewals still typically require a manual re-verification step because of the identity checks involved.
For sites running behind a load balancer or across multiple servers, you generally have two options: distribute the same certificate and private key to every server, or terminate TLS at the load balancer or CDN edge and let it handle certificate management centrally. The second approach is usually cleaner. Fewer copies of your private key floating around means less exposure if one server gets compromised.
- Keep private keys off shared drives and rotate them on a schedule, not just when something breaks.
- Adding a new subdomain to a wildcard doesn’t need reissuance, but adding a new hostname to a SAN certificate does, and it’s worth testing compatibility across browsers and API clients afterwards.
Pro Tip: Set a calendar reminder well before any manually renewed certificate expires. Automated systems fail silently more often than you’d expect, usually because a DNS record changed or an API key expired.
A practitioner’s view on certificate choices for small business
Most small businesses overthink the validation level and underthink the operations behind it. Some providers work across cybersecurity, managed IT, and cloud deployments, and the pattern that causes real problems isn’t picking DV instead of EV. It’s an expired certificate nobody noticed because renewal wasn’t automated, or a wildcard covering more infrastructure than anyone intended to expose in one blast radius.
For most small business sites, an automated DV or OV certificate covers day-to-day needs fine. Where it gets genuinely worth paying attention is checkout pages, client portals, and anything touching payment data, where an IT security review of your whole certificate lifecycle, not just the certificate type, catches the gaps that a one-off purchase decision never will.
— Ru
Sources
- DV, OV, EV SSL certificate validation levels explained
- What is SSL certificate validation?
- Types of SSL certificates | SSL certificate types explained
FAQ
What are the different types of SSL certificates?
They split by domain coverage (single-domain, wildcard, multi-domain/SAN) and by validation level (DV, OV, EV). A site typically needs one option from each axis, not one certificate type in isolation.
What are DV, OV, and EV SSL certificates?
DV confirms domain control only and issues fast. OV adds manual checks of business identity. EV requires the most rigorous human-vetted verification of legal existence and operational status. All three encrypt traffic identically.
What are the different formats of SSL certificates?
Certificates commonly come in formats such as PEM (Base64 text, used on most Linux/Apache/Nginx servers), DER (binary, common on Java platforms), and bundled types that combine certificates and keys or certificates only, used in different operating systems and servers.
What is an SSL and TLS certificate?
SSL was the original encryption protocol for securing web traffic; TLS replaced it years ago as the modern, more secure standard. The industry still calls certificates “SSL certificates” out of habit, even though they run on TLS.
Do I need a wildcard or a SAN certificate?
Choose a wildcard if you have many subdomains under one root domain, and a SAN certificate if you’re covering several distinct domains or brands under one certificate.