How to choose an SSL certificate

Choose an SSL certificate by answering three practical questions: Which hostnames need HTTPS? Who must be verified? Who will install and renew the certificate? A more expensive certificate is not automatically better protection for a normal website.

1. Decide which names to cover

One hostname

Single-name certificate

A base domain and selected additional names

Multi-domain/SAN certificate, subject to product limits

Many first-level subdomains such as shop.example.com

Wildcard certificate for *.example.com

A wildcard for *.example.com does not automatically protect nested names such as a.shop.example.com, and the apex example.com must also be covered explicitly if needed.

2. Choose validation level separately

DV validates control of the domain. Suitable for most blogs, shops, app endpoints and APIs.
OV adds organization identity verification and may fit corporate procurement requirements.
EV involves more extensive legal-entity checks; browser UI does not guarantee a prominent company-name display.

All properly deployed public TLS certificate types provide transport encryption. None proves a site's content is safe from all attacks.

3. Match your deployment workflow

Confirm whether the hostname points to a shared host, IIS/Apache/Nginx server, CDN, load balancer or managed platform. Check that you can perform DNS/HTTP validation, preserve the private key and install the full chain. SNI commonly allows HTTPS hosting without a dedicated IPv4 address.

4. Plan renewal before buying

Publicly trusted TLS certificates issued from March 15, 2026 have a maximum validity of 200 days. Choose a product and hosting setup that supports frequent replacement, ideally automated where verified. Compare the subscription price and renewal assistance, not just the first certificate issue.

After choosing a product, continue with How to Generate a CSR and How to Install SSL Certificates.

Three real purchasing scenarios

Scenario A — single company website. example.com and www.example.com both need HTTPS. A single-name certificate is not enough unless its SANs include both names. Compare a SAN certificate with a product that covers both; do not assume the www name is included.

Scenario B — SaaS with many customer-facing subdomains. app.example.com, admin.example.com and docs.example.com may fit a wildcard for *.example.com. A deeper hostname such as api.eu.example.com does not match that wildcard and needs separate coverage. Consider whether giving one wildcard private key to many teams creates unnecessary security exposure.

Scenario C — enterprise procurement. A customer asks for documented company identity. Compare OV and EV vetting rather than treating EV as stronger transport encryption. Ask which identity data the CA validates and what evidence your procurement team needs.