Can a Wildcard certificate secure multiple levels of subdomains?

No. A standard Wildcard certificate for *.example.com will secure blog.example.com and shop.example.com, but it will not secure dev.shop.example.com. It only covers one subdomain level.

Can I get an Extended Validation (EV) Wildcard certificate?

No. The CA/Browser Forum rules prohibit issuing Extended Validation (EV) certificates as Wildcards because the CA cannot verify the identity of an unlimited number of future subdomains.

Do I have to reissue a SAN certificate to add a new domain?

Yes. Because a SAN certificate secures a fixed, explicit list of domains, adding or removing a domain requires you to update the list and have the Certificate Authority (CA) reissue the certificate.

Which certificate is more cost-effective?

It depends on your infrastructure. If you have dozens of subdomains under one main domain, a Wildcard is usually cheaper and easier to manage. If you manage multiple distinct parent domains, a single SAN certificate is more cost-effective than buying individual certificates for each.

Wildcard vs SAN Certificates: Which Do You Need?

Q: What is a Wildcard certificate?

A Wildcard certificate is an SSL/TLS certificate that secures a single primary domain and an unlimited number of its first-level subdomains. It uses an asterisk (e.g., *.example.com) as a placeholder for the subdomains.

Q: What is a SAN certificate?

A SAN (Subject Alternative Name) certificate, also known as a Multi-Domain certificate, secures a specific list of multiple, often entirely different, domain names and subdomains under a single certificate.

Introduction

Managing SSL/TLS certificates for a growing organization is a balancing act, and the wildcard vs SAN certificate decision sits at the center of it. If you buy a standard single-domain certificate for every new service your engineering team launches, your IT budget and management overhead will spiral out of control. Soon, you are tracking dozens of individual expiration dates, increasing the risk that a forgotten certificate expires and takes down a production service.

To solve this, Certificate Authorities (CAs) offer two primary solutions for consolidating certificate management: Wildcard certificates and SAN (Subject Alternative Name) certificates. Both reduce the number of certificates you need to buy and manage, but they operate on entirely different technical principles. Choosing the wrong type can result in broken trust chains for nested subdomains or an inability to pass strict compliance audits that require Extended Validation (EV).

This article breaks down the wildcard vs SAN certificate difference, explains the technical limitations of each approach, and provides a clear framework for deciding which certificate type best fits your organization’s infrastructure.

What Is a Wildcard Certificate?

A Wildcard certificate is designed to secure one primary domain and an unlimited number of its subdomains using a single certificate.

When you generate a Certificate Signing Request (CSR) for a Wildcard certificate, you place an asterisk (*) in the Common Name (CN) field before your domain name—for example, *.example.com.

When a user’s browser connects to a server presenting this certificate, the browser sees the asterisk and accepts any valid string in that position. Therefore, a single certificate for *.example.com will successfully secure:

www.example.com
blog.example.com
shop.example.com
api.example.com

The primary advantage of a Wildcard certificate is future-proofing and agility. If your engineering team spins up staging.example.com tomorrow, they can simply deploy the existing Wildcard certificate. You do not need to contact the Certificate Authority, pay for a new certificate, or go through the domain validation process again.

However, Wildcard certificates have a strict technical limitation: they only cover one subdomain level. The asterisk does not traverse dot (.) boundaries. A certificate for *.example.com will not secure dev.api.example.com. To secure that second-level subdomain, you would need to purchase a separate Wildcard certificate specifically for *.api.example.com.

What Is a SAN Certificate?

A SAN certificate (also known as a Multi-Domain or Unified Communications certificate) allows you to secure a specific, explicit list of multiple domain names under a single certificate.

Historically, SSL certificates only looked at the “Common Name” field to verify a domain. As web hosting evolved and servers needed to host multiple secure sites on a single IP address, the Subject Alternative Name (SAN) extension was introduced to the X.509 certificate standard. Today, modern browsers actually ignore the Common Name entirely and only look at the SAN extension to verify the domain.

A SAN certificate leverages this extension to list multiple distinct hostnames. Unlike a Wildcard certificate, a SAN certificate can secure completely unrelated parent domains. For example, a single SAN certificate can secure:

example.com
example.net
my-other-company.org
blog.example.com

The primary advantage of a SAN certificate is extreme flexibility across domain boundaries. It is ideal for organizations that manage multiple brands, top-level domains, or distinct product websites.

The limitation of a SAN certificate is administrative overhead. The list of domains is cryptographically baked into the certificate when it is issued. If you launch a new website or service, it is not automatically covered. You must generate a new CSR, request the CA to add the new domain to the SAN list, and reissue the certificate.

Notice how the Wildcard certificate acts as an umbrella for a single domain family, while the SAN certificate acts as a targeted list that can span completely unrelated domain names.

This breakdown visually illustrates how the asterisk in a Wildcard certificate functions compared to the explicit domain listing required by a SAN certificate.

Wildcard vs SAN Certificate

Feature	Wildcard Certificate	SAN (Multi-Domain) Certificate
Primary Use Case	Securing one domain and unlimited subdomains.	Securing multiple distinct, unrelated domains.
Syntax Example	`*.example.com`	`example.com`, `example.net`, `test.org`
Adding New Domains	Automatic (if it matches the wildcard level).	Requires CA re-issuance to update the list.
Subdomain Depth	Limited to one level (does not cover nested subdomains).	Can cover specific nested subdomains if explicitly listed.
Extended Validation (EV)	Not allowed by CA/Browser Forum rules.	Supported.
Security Risk	High if the private key is compromised (affects all subdomains).	Moderate (only affects explicitly listed domains).

Real-World Use Cases

SaaS Platforms with Customer Subdomains. If you run a SaaS application where every customer gets their own tenant URL (e.g., customerA.myapp.com, customerB.myapp.com), a Wildcard certificate for *.myapp.com is mandatory. It is operationally impossible to reissue a SAN certificate every time a new customer signs up.

Corporate Rebranding and Acquisitions. When a parent company acquires several smaller brands, they often want to manage security centrally. Instead of buying individual certificates for brand-a.com, brand-b.com, and brand-c.com, the IT team can purchase a single SAN certificate covering all three distinct domains, simplifying deployment on the corporate load balancer.

Strict Financial Compliance. If you operate a bank or financial institution, compliance policies often mandate the use of Extended Validation (EV) certificates, which display verified company details to the user. Because the CA/Browser Forum strictly prohibits issuing EV certificates as Wildcards, these organizations must use SAN certificates to explicitly list every domain and subdomain they operate.

Common Mistakes to Avoid

Deploying a Wildcard private key everywhere. Because a Wildcard certificate covers unlimited subdomains, it is tempting to install the exact same certificate and private key on dozens of different servers (the web server, the mail server, the VPN appliance). This is a massive security risk. If a single edge server is compromised and the private key is stolen, the attacker can impersonate any subdomain on your network. Our guide on digital certificates explains why private keys should be isolated.

Misunderstanding the asterisk boundary. A very common configuration error is attempting to use a *.example.com certificate for api.v1.example.com. The browser will throw a stark SSL warning because the wildcard only covers one dot level. If you have nested subdomains, you must explicitly list them in a SAN certificate, or buy a secondary Wildcard for *.v1.example.com.

Forgetting to update SAN certificates during migrations. When migrating services or renaming internal applications, IT teams often forget that the new hostname must be explicitly added to the SAN certificate. The application goes live, but users are immediately blocked by browser security warnings because the new name is not cryptographically signed by the CA.

Getting Started

Map your domain architecture. Before purchasing a certificate, draw out your current and planned domain architecture. If your structure is deep (nested subdomains like app.prod.us-east.example.com), a Wildcard certificate will fail. If your structure is wide (many distinct parent domains), a SAN certificate is the most cost-effective choice.

Combine them if necessary (Multi-Domain Wildcard). Many modern Certificate Authorities offer a hybrid product called a Multi-Domain Wildcard (or SAN Wildcard). This certificate uses the SAN extension, but allows you to put wildcards in the SAN list (e.g., *.example.com AND *.example.net). This is highly flexible but often the most expensive option.

Automate your renewals. Regardless of which certificate type you choose, manual renewal is a recipe for an eventual outage. Implement the ACME (Automated Certificate Management Environment) protocol via tools like Certbot or Let’s Encrypt to automate the issuance and installation of both Wildcard and SAN certificates, ensuring your infrastructure is never caught off guard by an expiration date.