SSL certificate types explained

Overview

"SSL certificate type" usually means one of two things: how strongly the certificate authority (CA) validated you before issuing, and which hostnames the certificate can cover. Both decisions matter, because the first changes what a visitor sees when they click the padlock, and the second changes whether your site, subdomains, and email all work without extra certificates.

Validation classes

Every public certificate is backed by the contents of the CA, but that content is checked in one of three ways:

| Class | What the CA verifies | Typical use |

| DV (Domain Validation) | Control of the domain: file upload, TXT record, or email reply | Most websites, blogs, and small business sites |

| OV (Organization Validation) | Domain control plus the registered organization exists at a verified address | Companies that want the business name shown in the padlock |

| EV (Extended Validation) | Legal identity documents and proof of the right to the domain | Finance, payments, and other high-trust public-facing services |

DV is issued in minutes because it only needs a DNS or file check. OV and EV add human review, so they take hours to days and cost more. Modern browsers do not display the green EV label in the address bar the way they once did, but the underlying chain verification still works for all three classes.

Coverage shapes

A single certificate can cover the apex domain only, or a set of host names:

• Single domain: covers one name, for example www.example.com or example.com, but not both unless you buy the usually bundled extra name.
• Multi-domain (SAN): covers several specific names, for example example.com, www.example.com, shop.example.com. You pay per additional name.
• Wildcard: covers *.example.com, so every subdomain shares certificate. It does not cover the bare apex example.com; many providers sell the apex as an extra SAN.

The certificates all do the same encryption work. The differences are the hostnames they protect and the validation depth.

Order of operations when choosing

1. Write the complete list of hostnames your visitors actually use, for example example.com, www.example.com, and mail.example.com.
2. If the list is a handful of fixed names, a multi-name certificate is right.
3. If you manage many subdomains and new ones appear often, a wildcard saves renewal and management overhead.
4. Remember that a certificate only protects names that appear in its subject alternative names list; any other name shows an error even if the encryption works.
5. Buy or renew through a CA or reseller you trust, because the CA signs the certificate and the browser trusts the whole chain, which continues after any one certificate expires.

When to involve a professional

If you need OV or EV, certificates for mail servers with downloadable clients, or a certificate that must remain valid across server moves and name changes, it is worth having someone who has done it before hold the private key and running a checklist. The certificate management is one part of the work; the encryption chain, the TTL, the ACME client and the Cron job matter too, and those break in the ways described in the articles below.

Prevention

• Keep one inventory of every hostname that must stay encrypted and recheck it at every renewal.
• Test https://example.com and https://www.example.com side by side after any certificate change.
• Store the document under the private key release procedure and keep the contact email for the CA current, so account and renewal terminology reaches the right person.
• If you do not yet understand the difference between the renewal automation and a manual reload of a new certificate, read the renewal checklist before your next expiry.