An SSL/TLS certificate type describes two separate things that buyers often confuse: how thoroughly the certificate authority checked who you are (DV, OV, EV) and how many names the certificate covers (single name, multi-domain SAN, wildcard). Neither makes the encryption stronger: a free domain validated certificate and an expensive extended validation certificate protect traffic identically. This explainer sets out what each type means under the CA/Browser Forum rules, what security value it really adds, the specific risks of wildcard certificates, and when a private certificate authority is the right answer instead of a public one. It is for engineers, platform owners and anyone choosing or buying certificates. Lifetimes, renewal and expiry outages are covered in the Certificate Expiry Outages and 47-Day TLS Certificates Guide.
Key takeaways
- Validation level is about identity, not encryption. DV, OV and EV certificates use the same algorithms and key sizes; they differ only in what the CA verified and what appears in the subject fields.
- Browsers no longer reward EV visually. Chrome moved the EV badge out of the address bar into Page Info in Chrome 77, after concluding the indicator did not protect users as intended.
- Coverage is a separate choice. Every public certificate lists its names in the Subject Alternative Name extension; a SAN certificate lists several, a wildcard covers one level of subdomains.
- Wildcards concentrate risk. One private key on many servers means one compromise impersonates every covered host, as NSA warned in its 2021 guidance.
- Internal names need a private CA. Public CAs must not issue for internal names such as
.localor.corp, so internal services and workload identities belong on a private PKI.
What it is
A TLS server certificate is an X.509 document, signed by a certificate authority (CA), that binds a public key to one or more names. A client trusts it if it chains to a root in the client's trust store and the name the client asked for appears in the certificate. "SSL certificate" is the common commercial name, although SSL itself has been obsolete for years and everything in use today is TLS.
Publicly trusted certificates are governed by the CA/Browser Forum's TLS Baseline Requirements (version 2.3.1, dated 4 October 2026, at the time of checking) and, for EV, the Extended Validation Guidelines (version 2.0.4, adopted through Ballot SC102). Browser root programmes require CAs to follow them, and every public certificate carries a policy identifier that tells you which validation level was applied.
| Type | Policy OID in the certificate | What the CA verifies | What the subject shows |
|---|---|---|---|
| Domain Validated (DV) | 2.23.140.1.2.1 | Control of each domain name (or IP address), using an approved method such as a DNS record or HTTP challenge | Domain names only, no organisation |
| Organization Validated (OV) | 2.23.140.1.2.2 | Domain control plus the organisation's identity and address from reliable data sources | Organisation name, locality and country |
| Individual Validated (IV) | 2.23.140.1.2.3 | Domain control plus the identity of a named individual | The individual's name |
| Extended Validation (EV) | 2.23.140.1.1 | Domain control plus legal existence, physical existence, operational existence, a reliable means of communication, and the authority of the people requesting and approving the certificate | Organisation name, jurisdiction of incorporation, registration number and business category |
Name coverage is independent of validation level:
| Coverage | What it means | Example names | Restrictions |
|---|---|---|---|
| Single name | One fully qualified domain name (often issued with its www variant) | shop.example.com | None beyond validation |
| Multi-domain (SAN, sometimes sold as UCC) | Several names, possibly in different domains, in one certificate | example.com, example.co.uk, mail.example.net | Each name validated separately; all names are visible to anyone who inspects the certificate |
| Wildcard | A name starting with *. that covers any single label in that position | *.example.com covers api.example.com, not example.com or a.b.example.com | Not permitted for EV; CAs must refuse wildcards on public suffixes such as *.co.uk |
| IP address | A public IPv4 or IPv6 address in the SAN | 203.0.113.10 | Reserved (private) IP ranges are prohibited |
How it works
Validation
- Domain control: the Baseline Requirements list the permitted methods in section 3.2.2.4, including a DNS change (3.2.2.4.7), an agreed change to the website (3.2.2.4.18), the ACME HTTP method (3.2.2.4.19) and TLS using ALPN (3.2.2.4.20). Automated issuance through ACME uses these. Wildcards need a DNS-based method; Let's Encrypt, for example, requires the DNS-01 challenge for wildcards.
- Reuse of validation: CAs may reuse earlier checks for a limited time. For domain and IP validation the maximum reuse period is 200 days for certificates issued from 15 March 2026, falling to 100 days from 15 March 2027 and 10 days from 15 March 2029. Organisation identity data may be reused for up to 398 days from 15 March 2026.
- Organisation and EV checks: these use official registers, reliable data sources and call-backs, which is why they take days rather than seconds and are hard to automate.
Name matching
- SAN is authoritative: public certificates must carry a Subject Alternative Name extension with at least one
dNSNameoriPAddress; the Common Name is optional and, if present, must copy one SAN value. RFC 9525 (Service Identity in TLS, November 2023) says the Common Name must not be used to identify a service. - Wildcard matching rules: under RFC 9525 a wildcard must be the complete left-most label and matches exactly one label.
*.example.comdoes not match the bare domain or deeper subdomains.
Lifetime
All public types share the same maximum validity schedule in Baseline Requirements section 6.3.2: 200 days for certificates issued from 15 March 2026, 100 days from 15 March 2027, and 47 days from 15 March 2029. Paying for OV or EV does not buy a longer certificate. Let's Encrypt issues DV only, with a default 90-day lifetime and an opt-in six-day certificate, and states it has no plans to issue OV or EV.
Why it matters
Choosing a validation level
| Situation | Sensible choice | Reason |
|---|---|---|
| Public websites, APIs and services where automation matters | DV through ACME | Same encryption, issuance in seconds, fits short lifetimes |
| A contract, regulator or partner requires organisation identity in the certificate | OV (or EV where explicitly required) | Meets the requirement; plan for slower, partly manual issuance |
| Anti-phishing or brand trust for customers | DV plus brand protection controls | Browsers do not show EV in the address bar, and users did not change behaviour when EV indicators were shown |
| Internal services, workloads, devices, mTLS | Private CA | Internal names are not allowed in public certificates, and you control profile and lifetime |
As validity periods shrink to 47 days, manual OV and EV workflows become the main source of renewal pain. Organisations that keep OV or EV should confirm their CA can pre-validate the organisation and issue through automation, and should keep the reason for the higher validation level written down.
Wildcard risk
NSA's Cybersecurity Information Sheet "Avoid Dangers of Wildcard TLS Certificates and the ALPACA Technique" (7 October 2021) explains the core problem: if an attacker obtains the private key of a wildcard certificate, they can impersonate any site the certificate covers. The same key is often copied to load balancers, mail servers, VPN appliances and test boxes with very different security levels, so the weakest host sets the security of all of them. NSA also described ALPACA, a cross-protocol technique that abuses non-HTTP services sharing a certificate's scope. Its recommended mitigations: document the scope of every wildcard certificate, put an application gateway or web application firewall in front of servers including non-HTTP ones, use encrypted DNS and validate DNSSEC, enable Application-Layer Protocol Negotiation (ALPN) so servers state which protocols they accept, and keep browsers updated.
- When a wildcard is reasonable: a single, well-protected termination point (one load balancer or CDN) serving many dynamically created subdomains, where per-host certificates are impractical.
- When to avoid it: when the key would be copied to many servers, to third-party hosts or to systems run by different teams. Use per-service certificates issued through ACME instead.
- If a wildcard key leaks: every covered name is exposed, so the revocation and reissue is as wide as the scope. See the Leaked TLS Private Key Response guide.
Public versus private certificates
| Factor | Public CA | Private CA |
|---|---|---|
| Trusted by | All mainstream browsers and operating systems | Only clients where you install the private root |
| Rules | CA/Browser Forum Baseline Requirements and root programme policies | Your own certificate policy |
| Names | Publicly resolvable domains and public IPs only | Any name, including internal names and workload identifiers |
| Transparency | Logged publicly, so hostnames become visible | Not logged publicly |
| Best for | Anything reached by browsers or external clients | Internal services, service mesh and mTLS, devices, workload identity |
See the Private CA Design and Operations Guide and the Certificate Transparency Guide.
Where identity fits
Every certificate and its private key is a machine credential. The certificate type decides how much damage a stolen key can do: a wildcard or many-name SAN certificate is a broad credential, a single-name certificate a narrow one. Inventory certificates and keys as non-human identities with owners, apply least privilege to their scope, and automate rotation. See the Machine Identity, PKI and Certificate Lifecycle Guide.
Common misconceptions
- "EV encrypts better": it does not. The cipher suite and key size are chosen by your server configuration, not the validation level. See the TLS Server Configuration Baseline Guide.
- "A padlock means the site is safe": it means the connection is encrypted to whoever controls that domain. Phishing sites routinely obtain DV certificates, and attackers obtaining certificates is a recognised ATT&CK technique (T1588.004 Digital Certificates).
- "Free certificates are less secure": a free DV certificate from an automated CA is cryptographically identical to a paid DV certificate and usually better managed because renewal is automated.
- "A wildcard covers everything under the domain": it covers one label only, and not the bare domain.
- "Longer validity is better value": maximum lifetimes are capped for every type and are falling to 47 days; plan for automation, not for buying longer certificates.
- "We can buy a public certificate for our internal server name": CAs must not issue certificates containing internal names or reserved IP addresses.
Related concepts
| Concept | How it relates | Read next |
|---|---|---|
| ACME automation | Automated DV issuance and renewal; essential for short lifetimes | ACME and Automated Certificate Management Guide |
| Revocation | How a compromised certificate is invalidated, and why it is unreliable | Certificate Revocation Guide |
| Code signing and S/MIME certificates | Different certificate types with their own CA/Browser Forum requirements | Code Signing Certificate Validity Changes |
| Certificate file formats | PEM, DER, PFX and how keys are packaged | Certificate and Key File Formats |
| mTLS | Client certificates for service-to-service authentication, usually from a private CA | mTLS Guide |
Framework mapping: NIST SP 800-53 Rev. 5 SC-17 Public Key Infrastructure Certificates (issue certificates under an approved policy), SC-12 Cryptographic Key Establishment and Management, SC-8 Transmission Confidentiality and Integrity, IA-5(2) Public Key-based Authentication; NIST CSF 2.0 PR.DS-02 (data in transit protected).
Practitioner checklist
- Default to DV certificates issued and renewed through ACME for public services; record a business reason for any OV or EV purchase.
- Check the policy OID of existing certificates to confirm what validation you are actually paying for.
- List every wildcard certificate, the hosts holding its key and the owner; replace wildcards whose keys sit on many or third-party servers.
- Apply NSA's wildcard mitigations where wildcards remain: ALPN, a gateway or WAF in front of non-HTTP services, DNSSEC validation.
- Keep SAN certificates small and group names by owner and security level, not by convenience.
- Use a private CA for internal names, service mesh, devices and workload identity; never request public certificates for internal names.
- Monitor Certificate Transparency logs for certificates issued for your domains that you did not request.
- Prepare for the 200, 100 and 47-day maximum lifetimes by confirming every certificate, including OV and EV, can renew automatically.
Standards and references
- CA/Browser Forum: TLS Baseline Requirements
- CA/Browser Forum: Guidelines for the Issuance and Management of Extended Validation Certificates
- IETF: RFC 9525 Service Identity in TLS
- NSA: Avoid Dangers of Wildcard TLS Certificates and the ALPACA Technique
- Chromium: EV UI moving to Page Info
- Let's Encrypt: FAQ
- NIST: SP 800-53 Rev. 5
Related NHI Mgmt Group resources: Certificate Expiry Outages and 47-Day TLS Certificates Guide · How TLS Works Guide · Private CA Design and Operations Guide · ACME and Automated Certificate Management Guide