Wildcard vs. SAN Certificates: Security, Automation, and Compliance

For years, the choice between a Wildcard certificate and a Multi-Domain (SAN) certificate came down to a simple calculation: convenience and cost. Buying a single Wildcard certificate for *.example.com and distributing it across dozens of servers saved IT teams from the administrative overhead of generating individual Certificate Signing Requests (CSRs) and paying per-domain fees.

Today, that calculation has fundamentally changed.

The widespread adoption of Zero Trust Architecture (ZTA), the automation capabilities of the ACME protocol, and the impending industry shift toward 90-day maximum certificate lifespans have flipped the script. The conversation is no longer about convenience versus cost; it is about security versus automation.

Understanding the technical distinctions, security vulnerabilities, and compliance implications of Wildcard and Subject Alternative Name (SAN) certificates is critical for architecting modern infrastructure.

Technical Distinctions: How They Actually Work

Before diving into the security implications, it is important to clarify how these two certificate types operate at a cryptographic and protocol level.

Wildcard Certificates

A Wildcard certificate uses an asterisk (*) in the domain name field to secure a base domain and an unlimited number of first-level subdomains. For example, a certificate for *.example.com will secure www.example.com, api.example.com, and mail.example.com.

However, they come with strict technical boundaries:
* No Second-Level Support: A certificate for *.example.com will not secure api.staging.example.com. You would need a separate wildcard for *.staging.example.com.
* Shared Cryptographic Identity: To use a Wildcard certificate across multiple servers, the exact same private key must be copied and distributed to every machine hosting those subdomains.

Multi-Domain / SAN Certificates

Multi-Domain certificates utilize the Subject Alternative Name (SAN) extension (defined in RFC 5280) to secure multiple distinct hostnames under a single certificate. A single SAN certificate can secure example.com, example.net, api.example.org, and blog.different-domain.com.

• Explicit Trust: Every domain protected by the certificate is explicitly listed in the certificate details.
• Hard Limits: Certificate Authorities (CAs) typically cap SAN certificates at 100 to 250 domains. Modifying this list (adding or removing a domain) requires generating a new CSR and completely reissuing the certificate.

The Security Trade-offs

The security community has increasingly turned against the widespread use of Wildcard certificates in production environments. The danger doesn't lie in the cryptographic strength of the certificate itself, but in human behavior and architectural limitations.

The Wildcard Problem: Private Key Proliferation

In a Zero Trust Architecture, access is governed by the principle of least privilege. Wildcard certificates inherently violate this principle by granting a single private key the authority to authenticate any subdomain.

When an organization uses a Wildcard certificate across multiple servers, they are forced to distribute the private key to every endpoint. This creates a massive lateral movement risk. If an attacker breaches a low-security internal development server and steals the privkey.pem file, they now possess the cryptographic material to impersonate your highly secure production billing server (billing.example.com) via a Man-in-the-Middle (MitM) attack.

Furthermore, Wildcards facilitate cross-protocol attacks like ALPACA. If a web server (HTTPS) and an FTP server share a Wildcard certificate, an attacker can exploit vulnerabilities in the less secure FTP server to compromise the TLS session of the HTTPS traffic.

Finally, Wildcards leave organizations vulnerable to subdomain takeovers. If a DNS record points to a decommissioned service (like a deleted AWS S3 bucket or an old Heroku app), but the Wildcard certificate is still valid and trusted by the browser, an attacker can claim that subdomain and serve perfectly valid, HTTPS-secured phishing pages to your customers.

The SAN Problem: Certificate Transparency Leaks and Bloat

SAN certificates solve the private key proliferation problem by allowing you to generate unique keys for different server clusters while grouping the domains logically. However, they introduce their own unique challenges.

The most significant risk of a SAN certificate is information disclosure via Certificate Transparency (CT) logs. CT logs are public, append-only ledgers that record every TLS certificate issued by a trusted CA. If your DevOps team provisions a SAN certificate for example.com and includes secret-unreleased-project.example.com, competitors, security researchers, and attackers can instantly see that subdomain by querying tools like crt.sh.

Additionally, SAN certificates suffer from "certificate bloat." Adding 150 domains to a SAN certificate physically increases the kilobyte size of the certificate payload. During the TLS handshake, this larger payload must be transmitted to the client, which can marginally slow down performance for high-traffic applications.

There is also the "all-eggs-in-one-basket" architectural risk. If a SAN certificate expires, is misconfigured, or is revoked by the CA, every single domain listed on that certificate goes offline simultaneously.

Automation and the 90-Day Lifespan Shift

The operational reality of managing certificates is about to change drastically. Google's Chromium Root Program has signaled its intention to reduce the maximum validity of public TLS certificates from 398 days to just 90 days.

Manually updating a Wildcard certificate across 50 different load balancers, web servers, and firewalls every 60 to 90 days is operationally impossible without causing outages. This impending shift forces organizations to adopt the Automated Certificate Management Environment (ACME) protocol.

Once you implement ACME, the primary benefit of a Wildcard certificate—convenience—evaporates. Tools like certbot or acme.sh make provisioning an individual or SAN certificate just as easy as provisioning a Wildcard.

In fact, automating Wildcard certificates is often harder than automating specific domains. To issue a Wildcard certificate via Let's Encrypt, you are strictly required to use the DNS-01 challenge, which requires granting your ACME client programmatic access to your DNS provider's API.

# Automating a Wildcard requires DNS plugins and API credentials
certbot certonly \
  --dns-route53 \
  -d "*.example.com" \
  -d "example.com"

Conversely, issuing a SAN or single-domain certificate can be done using the much simpler HTTP-01 challenge, which only requires the ACME client to place a temporary file on the web server.

# Automating a SAN cert uses a simple webroot or standalone challenge
certbot certonly \
  --webroot -w /var/www/html \
  -d example.com \
  -d api.example.com \
  -d blog.example.com

In modern containerized environments, the industry standard is to abandon Wildcards entirely in favor of automated, single-domain certificates managed by cert-manager in Kubernetes. cert-manager automatically provisions and rotates certificates for your ingress controllers without human intervention:

apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: api-example-com
  namespace: production
spec:
  secretName: api-example-com-tls
  issuerRef:
    name: letsencrypt-prod
    kind: ClusterIssuer
  commonName: api.example.com
  dnsNames:
  - api.example.com

Compliance Reality Check

Regulatory bodies and security frameworks have recognized the risks associated with Wildcard certificates and are clamping down on their usage.

• NIST & FedRAMP: The National Institute of Standards and Technology (NIST) explicitly advises against the use of Wildcard certificates in Special Publication 800-52 Revision 2. Consequently, FedRAMP strict guidelines prohibit Wildcard certificates in federal cloud environments unless they are strictly contained to a single boundary (like a single load balancer) and the private key is never exported.
• PCI-DSS v4.0: While the Payment Card Industry Data Security Standard does not explicitly ban Wildcards, the strict key-management and isolation requirements in version 4.0 make it incredibly difficult for an auditor to sign off on a Wildcard certificate whose private key is shared across multiple systems.
• HIPAA: Healthcare applications require rigorous access controls. Sharing a private key across multiple departments, applications, or servers via a Wildcard is generally considered a violation of HIPAA’s technical safeguards regarding transmission security and access control.

Decision Matrix: When to Use Each

Despite the industry shift, there are still specific architectural scenarios where each certificate type shines. Use this matrix to determine your deployment strategy:

When to use SAN or Single-Domain Certificates

• High-Security & Regulated Applications: Fintech, healthcare, and government applications should strictly use single-domain or SAN certificates to ensure private key isolation and comply with NIST/FedRAMP guidelines.
• Multiple Distinct Brands: If you operate a single load balancer or Exchange server that handles traffic for brand-one.com and brand-two.com, a SAN (often called a Unified Communications Certificate or UCC in Microsoft environments) is the only way to secure both completely different root domains on one listener.
• SaaS Platforms with Customer Vanity Domains: If you offer a service where customers can point their own domain to your app (e.g., shop.customer.com), use automated APIs (like Let's Encrypt or Cloudflare SSL for SaaS