Wildcard SSL vs SAN Certificate: Which One Covers What You Actually Have

Most guides about wildcard and SAN certificates start with definitions. This one starts with the question that actually matters: what does your domain structure look like?

If everything you need to secure sits under one domain name (yourdomain.com) but across many subdomains (shop.yourdomain.com, api.yourdomain.com, staging.yourdomain.com), you have a subdomain problem. A wildcard certificate is built for exactly that.

If you need to secure several different domain names that share no common root (yourdomain.com, yourdomain.co.uk, differentbrand.com, client-site.net), you have a multi-domain problem. A SAN certificate is built for that.

Both certificate types use the same underlying X.509 standard. Both provide the same 256-bit AES encryption for the TLS connection. The difference is not about encryption strength or trust level. It is entirely about coverage scope. Understanding that distinction before anything else saves a lot of time and money spent on the wrong certificate type.

What a Wildcard Certificate Actually Covers

A wildcard certificate contains an asterisk in its Common Name field: *.yourdomain.com. The asterisk is a placeholder that matches any single subdomain label to the left of the base domain. The certificate is issued for the pattern, not for a specific list of hostnames.

The asterisk in a wildcard certificate matches exactly one subdomain label. It cannot match multiple labels. This is defined in RFC 6125. api.v2.yourdomain.com has two labels between the asterisk position and the base domain, so *.yourdomain.com does not cover it. A separate wildcard certificate for *.v2.yourdomain.com would be needed, or a SAN certificate listing api.v2.yourdomain.com explicitly.

One property of wildcard certificates that often surprises people: new subdomains created after the certificate is issued are covered automatically. If you build a new microservice at analytics.yourdomain.com six months after installing the wildcard, it is already covered. You do not request a new certificate, contact the CA, or redeploy anything. The wildcard pattern matches it immediately.

What a SAN Certificate Actually Covers

A SAN certificate, also called a multi-domain certificate or UCC (Unified Communications Certificate), works differently. Instead of a pattern, it contains an explicit list. The Subject Alternative Names extension in the certificate contains every hostname the certificate is valid for. The browser checks whether the hostname it is connecting to appears in that list. If it does, the certificate is valid. If it does not, the browser rejects it.

The SAN list is fixed at issuance. Every hostname must be specified when the certificate is created. If you acquire a new domain or need to add a new hostname after issuance, you must reissue the certificate with the updated SAN list, validate ownership of the new domains, and redeploy the new certificate to every server that uses it. This reissuance process is a meaningful operational overhead compared to wildcards, but it provides a precise and auditable scope of coverage.

Most CAs allow free reissuance for adding SANs during an active certificate’s validity period. You pay for the certificate once and can update the SAN list as needed. However, each reissuance requires fresh domain validation for any newly added domains and requires redeployment of the new certificate file to your servers. With the CA/B Forum’s 200-day maximum validity coming into effect in March 2026, this reissuance and redeployment cycle becomes more frequent regardless of whether you add new domains.

How Each Certificate Type Looks Inside the X.509 Structure

Both certificate types use the Subject Alternative Names (SAN) extension in the X.509 certificate structure. This is worth understanding because it clarifies why the naming can be confusing: wildcard certificates use SAN entries too, they just use a wildcard pattern in those entries rather than explicit hostnames.

The last example above is the multi-domain wildcard certificate, a hybrid type that deserves its own mention because most buying guides treat wildcard and SAN as mutually exclusive. They are not. A single certificate can contain both wildcard patterns and explicit hostnames as SAN entries, covering multiple base domains each with their own subdomain wildcard. This combination is the most flexible option available but also the most expensive.

Three Certificate Types Compared: Single, Wildcard, and SAN

Putting all three types alongside each other shows where each makes economic and operational sense.

Matching the Certificate to the Domain Structure

The decision between wildcard and SAN is almost entirely determined by whether your hostnames share a common base domain or span multiple unrelated domain names. Work through these scenarios against your own infrastructure.

Use a wildcard certificate when:

• You run a SaaS platform with customer subdomains. Each customer gets their own subdomain (customer1.yourapp.com, customer2.yourapp.com). You cannot enumerate them all at certificate issuance time because new customers will appear after the certificate is issued. A wildcard is the only practical option.
• You have a staging and development workflow with subdomains. yourdomain.com, dev.yourdomain.com, qa.yourdomain.com, feature-branch.yourdomain.com. These change frequently and having to reissue a certificate each time a new environment is created adds friction. A wildcard covers everything automatically.
• You run microservices or APIs on subdomains of one domain. yourdomain.com, auth.yourdomain.com, webhook.yourdomain.com, static.yourdomain.com. If all services live under one domain and you add services regularly, a wildcard certificate eliminates certificate management overhead for each new service.
• You are a web hosting agency or reseller. You create subdomains for clients on your platform (client1.youragency.com, client2.youragency.com). A single wildcard covers the entire platform without needing a separate certificate per client subdomain.

Use a SAN certificate when:

• You own the same brand across multiple TLDs. com, yourdomain.co.uk, yourdomain.de, yourdomain.fr. A wildcard for *.yourdomain.com covers only .com subdomains. A SAN certificate can list all TLD variants and their www subdomains in one certificate.
• You manage multiple distinct client websites. An agency maintaining separate client domains (client1.com, client2.net, client3.org) on shared hosting can consolidate them into a single SAN certificate, simplifying renewal management to one certificate instead of three or more.
• You need EV validation. Extended Validation certificates cannot be wildcards under CA/B Forum Baseline Requirements. If EV is required for any domain, a SAN certificate (either single or multi-domain) is the only option.
• You need to secure deep subdomains. If any hostname is more than one level deep below the base domain (api.v2.yourdomain.com, admin.portal.yourdomain.com), a wildcard cannot cover it. A SAN entry for the exact hostname is required.
• You host applications on different server infrastructure. yourdomain.com on Exchange, www.yourdomain.com on Apache, and app.differentdomain.com on an entirely different server. A SAN certificate can be installed on all three servers, or separate certificates per server can be issued from the same SAN cert by reissuing with the appropriate SAN subset.

Use a multi-domain wildcard when:

• You need wildcard coverage for multiple separate domains. com and differentbrand.com, each with unpredictable subdomain growth. A SAN cert containing *.yourdomain.com and *.differentbrand.com as SAN entries covers all subdomains of both domains in one certificate.
• You manage a group of companies or brands. A holding company with multiple brand domains, each needing full subdomain coverage. One multi-domain wildcard certificate handles all of them with a single renewal date and a single private key management responsibility.

Multi-domain wildcard certificates are the most powerful option but also carry the largest blast radius in a security incident. One private key protects every subdomain of every domain listed. Before choosing this option, ensure that the private key is stored in a hardware security module (HSM) or equivalent secure key storage, and that access to it is strictly controlled. The broader the coverage, the more valuable the private key becomes to an attacker.

The Security Trade-Off: Shared Private Keys and Blast Radius

Every certificate type has a private key. The private key is what proves the certificate belongs to the entity presenting it during a TLS handshake. If an attacker obtains the private key, they can impersonate any hostname the certificate covers until the certificate is revoked.

For a single-domain certificate, a compromised private key exposes one hostname. For a wildcard certificate, a compromised private key exposes every subdomain of the base domain, including any new ones created before the compromise is detected. For a multi-domain SAN certificate, it exposes every domain in the SAN list. For a multi-domain wildcard, it exposes every subdomain of every domain in the certificate.

This does not mean wildcard certificates are insecure. It means the private key management requirement scales with coverage breadth. A single-domain certificate for a low-security staging server can have its private key stored in a standard file with reasonable permissions. A wildcard certificate protecting a production e-commerce platform and its payment subdomain warrants HSM storage, strict access controls, and an automated rotation policy.

Some security frameworks and enterprise security policies prohibit wildcard certificates for this reason, preferring shorter-lived individual certificates with automation rather than long-lived wildcards. This is the correct approach for environments where different subdomains have different security classifications (a marketing subdomain and a payment processing subdomain, for example, should not share a private key). In these cases, SAN certificates listing specific subdomains, or individual certificates per service, provide better security segmentation.

Financial services, healthcare, and other regulated industries often have compliance requirements that restrict or prohibit wildcard certificates for production systems handling sensitive data. If your environment is subject to PCI DSS, HIPAA, or FedRAMP requirements, review those standards before deploying a wildcard certificate across services that handle protected data. A SAN certificate with explicitly scoped hostnames may be required.

Validation Levels: DV, OV, and EV Across Both Types

Both wildcard and SAN certificates are available at Domain Validation (DV) and Organization Validation (OV) levels. The validation level determines how thoroughly the CA verifies the applicant’s identity before issuing the certificate, not how the certificate covers domains.

Extended Validation (EV) certificates are available for SAN certificates covering multiple specific domains, but EV wildcard certificates do not exist. The CA/B Forum Baseline Requirements, the industry rules that all publicly trusted CAs must follow, explicitly prohibit the use of wildcard characters in EV certificate subject fields. This is a deliberate policy decision: EV is intended to provide the highest level of verified identity assurance, and a wildcard’s open-ended coverage is considered incompatible with the precise identity binding EV requires.

For organizations that require EV certification, the path is an EV SAN certificate listing specific domains. The certificate can cover multiple domains under EV validation, but every domain and subdomain must be explicitly listed and individually validated at the EV level. There is no way to obtain wildcard coverage under EV.

How the 200-Day Validity Limit Changes the Wildcard vs SAN Decision

The CA/B Forum approved ballot SC-081v3 in April 2025. From March 15, 2026, all newly issued SSL certificates are capped at 200 days of validity. By March 2027, the cap drops to 100 days. By March 2029, it falls to 47 days. This trajectory has significant implications for the wildcard versus SAN decision that most existing comparison guides do not address because they were written before this change was confirmed.

For wildcard certificates, the 200-day limit reduces a meaningful advantage but does not eliminate it. The wildcard’s value is that new subdomains are covered automatically without reissuance. That advantage remains unchanged regardless of how often the certificate itself must be renewed. Renewal replaces the certificate but preserves the wildcard pattern, so all existing subdomains are automatically covered by the renewed certificate. Automation via ACME protocol (Certbot, acme.sh, or CA-provided automation) handles wildcard renewal with DNS-01 challenge validation.

For SAN certificates, the 200-day limit amplifies the reissuance friction. Adding a new domain to a SAN certificate always required reissuance. Now, the certificate itself must also be replaced every 200 days regardless of domain changes. Each renewal cycle is an opportunity to update the SAN list, which partially mitigates the overhead, but organizations with frequently changing domain portfolios face more operational complexity than with wildcards.

With 200-day validity, certificate automation is no longer optional for any organization managing more than a handful of certificates. Let’s Encrypt provides free wildcard certificates via DNS-01 ACME challenge and free SAN certificates with up to 100 domains per certificate. Setting up ACME automation now means the shorter validity window becomes a non-issue. The operational difference between wildcard and SAN narrows significantly when both are automated.

Free Wildcard and SAN Certificates via Let’s Encrypt

Let’s Encrypt issues both wildcard and multi-domain certificates at no charge. This changes the cost calculation significantly for sites that do not require OV or EV validation.

For wildcard certificates, Let’s Encrypt requires DNS-01 challenge validation. This means your DNS provider must support API-based DNS record creation, because the validation requires adding a _acme-challenge TXT record to your domain’s DNS zone. Most major DNS providers (Cloudflare, Route 53, DigitalOcean, Google Cloud DNS) support this. Shared hosting DNS panels that do not offer an API cannot be used for automated wildcard renewal and require manual DNS updates instead.

For SAN certificates, Let’s Encrypt supports up to 100 SANs per certificate and validates each domain using HTTP-01 or DNS-01 challenge. Adding a new domain to a Let’s Encrypt SAN certificate requires reissuing the certificate with the updated domain list and re-running validation for any newly added domains.

Quick Decision Guide: Which Certificate for Which Situation

Frequently Asked Questions

What is the difference between a wildcard and a SAN certificate?

A wildcard certificate uses an asterisk pattern (*.yourdomain.com) to cover all first-level subdomains of one base domain. Any subdomain you create after issuance is automatically covered without reissuing the certificate. A SAN (Subject Alternative Name) certificate contains an explicit list of every hostname it covers, which can include completely different domain names. SAN certificates can cover multiple unrelated domains but require reissuance whenever a new domain is added to the list.

Can a SAN certificate include wildcard entries?

Yes. A SAN certificate can include wildcard entries such as *.yourdomain.com as individual SAN entries alongside explicit hostnames and other domain names. A certificate that contains *.yourdomain.com, yourdomain.com, *.anotherdomain.com, and anotherdomain.com as SAN entries is called a multi-domain wildcard certificate. It provides wildcard subdomain coverage for multiple base domains under one certificate. This is the most flexible certificate type but also the most expensive and carries the largest blast radius in a key compromise scenario.

Which is cheaper: wildcard or SAN?

For a single domain with many subdomains, a wildcard certificate is generally cheaper than buying individual certificates for each subdomain. For multiple separate domains, a SAN certificate is generally cheaper than buying individual certificates per domain. If you need both wildcard subdomain coverage and multiple base domains, a multi-domain wildcard certificate is more expensive than either a standard wildcard or a basic SAN, but cheaper than multiple separate wildcard certificates. Free options from Let’s Encrypt exist for all three types at the DV validation level.

Does a wildcard certificate cover www.yourdomain.com?

Yes. www is a subdomain label, so *.yourdomain.com covers www.yourdomain.com. Most CAs also automatically include the bare domain yourdomain.com as a SAN entry in wildcard certificates, covering both the wildcard subdomains and the root domain in one certificate. Confirm with your CA whether the root domain is included, since technically the wildcard pattern only matches subdomains and not the root domain itself.

Can I get an EV wildcard certificate?

No. The CA/B Forum Baseline Requirements explicitly prohibit wildcard characters in Extended Validation certificates. If EV validation is required for a multi-hostname deployment, use an EV SAN certificate that lists each specific hostname. Every hostname in an EV certificate is individually verified at the EV level during issuance.

Can a wildcard certificate cover two levels of subdomains?

No. The wildcard character matches exactly one subdomain label. *.yourdomain.com covers api.yourdomain.com but not api.v2.yourdomain.com. To cover a two-level deep subdomain, either add it explicitly as a SAN entry in a SAN certificate, or obtain a second wildcard certificate for the intermediate level (*.v2.yourdomain.com) alongside the main wildcard.

How does the 200-day certificate validity limit affect wildcard certificates?

From March 15, 2026, all new certificates are capped at 200 days. For wildcard certificates, the certificate itself must be renewed more frequently, but the wildcard pattern means all existing subdomains are automatically covered by the renewed certificate without any changes to server configuration beyond the certificate file replacement. Automated renewal via ACME with DNS-01 challenge handles this without manual intervention. The key advantage of wildcards (new subdomains covered without reissuance) is unaffected by the shorter validity window.

What happens if a wildcard certificate’s private key is compromised?

Every hostname matching the wildcard pattern is exposed. An attacker with the private key can impersonate any subdomain of your domain until the certificate is revoked. Revocation requires contacting your CA immediately, requesting revocation of the compromised certificate, generating a new private key, and redeploying a new certificate to every server that uses the wildcard. The breadth of a wildcard means this remediation affects many services simultaneously. This is why private key storage security scales with coverage breadth: a wildcard certificate’s private key warrants more protection than a single-domain certificate’s key.