How to Choose an SSL Certificate: DV/OV/EV vs. Single Domain, Wildcard, and Multi-Domain

The two concepts that most people get stuck on when choosing a certificate are: DV / OV / EV and Single Domain / Wildcard / Multi-Domain.

First, let’s clarify the most critical point: these two groups are orthogonal and independent. “DV” answers “to what extent is verification performed,” while “Wildcard” answers “how many domains can be covered.” They can be combined arbitrarily—there are both DV Wildcards and OV Single Domains. Treating them as options within a single dimension is the root cause of confusion in selection.

Dimension 1: Verification Level

It is important to clarify: the encryption strength of all three is identical. DV and EV use the same TLS algorithms, and man-in-the-middle attacks are equally ineffective against both. The difference lies solely in “how much information about you is written in the certificate” and “to what extent browsers disclose this information.”

Therefore, for most people debating “whether to upgrade to EV,” the answer is usually no—unless your industry has compliance requirements or visitors actually check the organization information in the certificate.

Dimension 2: Coverage Scope

Wildcards have two boundaries that many people trip over:

• No cross-level coverage: *.example.com covers a.example.com, but does not cover x.a.example.com
• Does not include the naked domain: *.example.com does not cover example.com itself. If you need to cover the naked domain, it must be included in the SAN list as well.

Check Existing Certificate Type and Coverage

# View all domains covered by the certificate (SAN)
openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null 
  | openssl x509 -noout -ext subjectAltName

# Determine verification level: Check the O (Organization) field
# DV certificates typically lack an O field, or only contain CA info
openssl x509 -in cert.pem -noout -subject

# Validity period
openssl x509 -in cert.pem -noout -dates

Decision Tree

Select Certificate
├─ Step 1: Determine Verification Level
│  ├─ Compliance required / Need to display org identity → OV or EV
│  └─ Other cases                                    → DV (Sufficient, fastest issuance)
└─ Step 2: Determine Coverage Scope
   ├─ Only one domain          → Single Domain
   ├─ Multiple subdomains under one main domain → Wildcard (Remember to add the naked domain)
   ├─ Multiple unrelated main domains    → Multi-Domain SAN
   └─ Need both subdomains and multiple main domains → Multi-Domain SAN + Wildcard entries combination

Scenario Walkthrough: Bought a “Sufficient” Certificate, But Subdomains Are Not Covered

Symptom: A certificate was purchased and deployed for a main domain.
The main site accesses normally. A few days later, newly launched subdomain services start reporting certificate errors.

1. Check if the error is related to the domain name → The browser提示s a name mismatch, indicating the certificate is valid but does not cover the currently accessed domain.
2. Check which domains the existing certificate actually covers → The extension fields only list the main domain and the www version;
   none of the subdomains are in the list.
3. Confirm the type purchased → It was a single-domain certificate, covering only one hostname (usually with www), lacking wildcard capabilities.
4. Evaluate remediation plans → Issuing certificates for each subdomain individually means re-issuing every time a new subdomain is added;
   since the number of subdomains is growing, a wildcard is clearly more suitable.
5. Replace the certificate and redeploy → Switch to a wildcard certificate to cover the main domain and all its sibling subdomains.
6. Verify coverage and deployment → Access each subdomain to confirm correctness and add expiration monitoring.

# See which domains the certificate actually covers—the only way to judge "if bought correctly"
echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null 
  | openssl x509 -noout -subject -ext subjectAltName -enddate

# Verify each subdomain (wildcards cover one level, not multiple levels)
for h in a.example.com b.example.com a.b.example.com; do
  printf '%-24s ' "$h"
  echo | openssl s_client -connect $h:443 -servername $h -verify_return_error 2>&1 
    | grep -o 'Verify return code: [0-9]*'
done

Root Cause: During procurement, a single-domain certificate was selected based on “how many domains exist currently,”
while the actual business domains are growing. The selection criterion was current quantity rather than growth pattern.

Two key takeaways:

• When selecting a certificate, look not at how many domains you have now, but whether the number will continue to increase.
  If it grows continuously, use a wildcard; if domains are unrelated and fixed in number, consider multi-domain types.
• Wildcards only cover one level of subdomains.
  *.example.com covers a.example.com, but not a.b.example.com.
  Additional confirmation is needed for multi-level requirements.

Direct Mapping by Scenario

There is a detail worth mentioning separately: the “Naked Domain + www” combination. Most sites require both to be accessible. If a single-domain certificate has only one entry, you must confirm it includes both—otherwise, one will inevitably report a certificate mismatch, and this issue often remains hidden until someone accesses the site using the other format.

Comparison of Issuance and Operational Costs

This table does not aim to show “which is better,” but rather that the length of the validity period directly determines the management method.
Certificates with short validity periods will inevitably fail if managed manually; they rely on automatic renewal.
Certificates with a one-year validity are suitable for ledger tracking with reminders, allowing enough time for processing before expiration.

# View current certificate type, validity, and covered domains
echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null 
  | openssl x509 -noout -subject -issuer -dates -ext subjectAltName

# View only remaining days (suitable for monitoring scripts)
echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null 
  | openssl x509 -noout -enddate

# Same applies to local certificate files
openssl x509 -in fullchain.pem -noout -subject -dates -ext subjectAltName

Running these commands to inspect existing certificates is often more effective than starting from a selection chart:
First, clearly see what you have, when it expires, and which domains it covers.
The selection question usually resolves itself once this information is reviewed.

8 Common Pitfalls

1. Confusing verification level with coverage scope: These are two independent matters and should be decided separately.
2. Assuming EV is more secure: Encryption strength is identical to DV; the difference lies only in the disclosure of identity information.
3. Assuming wildcards cover the naked domain: They do not; it must be added separately to the SAN.
4. Assuming wildcards cross levels: *.example.com cannot manage x.a.example.com.
5. Bought a single-domain certificate, then added subdomains: Requires re-issuance, so reserve capacity during planning.
6. Focusing only on price, ignoring issuance speed: OV/EV takes several working days; there is no time for last-minute launches.
7. Omitting domains in multi-domain certificates: SAN is a whitelist; anything not listed is not covered, requiring re-issuance afterward.
8. Ignoring renewal costs: The more domains and heavier the verification, the more troublesome the renewal. Although wildcards are slightly more expensive, their management cost is significantly lower.

Real Customer Feedback (From Cloud Market Reviews and Consultations for Similar Products)

The following excerpts are taken from real buyer reviews and consultations for similar operations services on Alibaba Cloud / Tencent Cloud / Huawei Cloud marketplaces (service providers include our store and competitors, provided for reference only, not fictional tickets from this site):

l****w Rating: 5.0 points 2020-08-06 16:31 b****b Rating: 5.0 points 2020-05-11 10:38 Fragrant****9 Rating: 5.0 points 2019-09-20 17:06 River****Community Rating: 5.0 points 2019-09-11 09:46

2****7 Rating: 5.0 points 2022-02-18 14:38

Jian****Wei Rating: 5.0 points 2021-01-20 15:02