Wildcard vs. Multi-Domain (SAN) Certificates: Navigating the New Cryptographic Landscape

For over a decade, the debate between using Wildcard certificates and Multi-Domain (SAN) certificates was largely a matter of administrative convenience versus strict security. IT administrators often defaulted to Wildcard certificates to avoid the headache of provisioning a new certificate every time a developer spun up a new subdomain.

However, the cryptographic landscape is undergoing a massive shift. With the impending reality of 90-day certificate lifespans, the finalization of Post-Quantum Cryptography (PQC) standards, and the universal mandate for Zero Trust Architecture, the old rules of convenience no longer apply.

In this comprehensive guide, we will break down the technical realities of Wildcard and Multi-Domain certificates, analyze their respective risk profiles, and provide a definitive framework for when to use each in modern infrastructure.

Understanding the Core Mechanics

Before diving into the security implications, it is critical to define exactly how these two certificate types operate at the protocol level.

Wildcard Certificates

A Wildcard certificate secures a single base domain and an unlimited number of first-level subdomains using a single private key. Denoted by an asterisk in the Common Name (CN) or Subject Alternative Name (e.g., *.example.com), it provides a blanket of cryptographic trust. It will secure api.example.com and dev.example.com, but importantly, it will not secure second-level subdomains like v1.api.example.com or the bare apex domain example.com (unless explicitly added as a SAN).

Multi-Domain / SAN Certificates

Multi-Domain certificates utilize the Subject Alternative Name (SAN) extension of the X.509 standard. They allow you to secure multiple distinct domains, subdomains, and even entirely different Top-Level Domains (TLDs) under a single certificate. Every domain must be explicitly listed within the certificate payload (e.g., example.com, api.example.com, example.net).

Why the 90-Day Lifespan Changes the Debate

Historically, the primary argument for Wildcard certificates was "ease of management." Managing individual certificates that expired every 1-2 years was tedious.

Google’s "Moving Forward, Together" initiative has proposed reducing the maximum validity of public TLS certificates from 398 days to just 90 days. This shift fundamentally alters the management paradigm. Manual certificate management is no longer viable; automated issuance via the Automated Certificate Management Environment (ACME) protocol is now a strict requirement.

Because automation is mandatory, the administrative burden of managing 50 individual SAN certificates is virtually identical to managing one Wildcard certificate. Tools like Certbot and Kubernetes cert-manager handle renewals invisibly. Consequently, the primary historical advantage of the Wildcard certificate has been neutralized by modern DevOps practices.

The Security Risk Profile of Wildcard Certificates

In a modern Zero Trust Architecture (ZTA), the core tenet is "Least Privilege." Wildcard certificates inherently violate this principle by granting broad, overarching trust.

Private Key Sprawl

To use a Wildcard certificate across multiple distinct servers (e.g., a load balancer, a production API, and a development server), the single private key must be copied and distributed to all of those machines.

This creates "private key sprawl." If an attacker compromises a poorly secured development server and extracts the Wildcard private key, they have effectively compromised the encryption of your entire infrastructure. They can now impersonate your production billing portal or intercept traffic via Man-in-the-Middle (MitM) attacks.

Subdomain Takeover Facilitation

Wildcard certificates act as a force multiplier for subdomain takeover attacks. Consider the historical breach of Epic Games: hackers discovered an old, orphaned DNS record pointing to an unused AWS service. Because Epic Games used a Wildcard certificate, the attackers claimed the AWS resource, and the Wildcard automatically lent cryptographic legitimacy to their malicious endpoint. This allowed them to bypass Cross-Origin Resource Sharing (CORS) restrictions and steal authentication tokens for millions of users.

Ransomware and C2 Evasion

Threat intelligence reports from 2024 indicate that Initial Access Brokers (IABs) actively hunt for Wildcard private keys on compromised corporate networks. Once obtained, attackers use the legitimate Wildcard to encrypt their Command and Control (C2) traffic. Because the traffic utilizes a trusted corporate certificate, it easily bypasses Deep Packet Inspection (DPI) firewalls and Data Loss Prevention (DLP) systems.

Multi-Domain (SAN) Certificates: The Modern Standard

Multi-Domain and single-domain certificates align perfectly with modern security practices. By issuing unique certificates to specific services, you isolate risk. If a single server is compromised, you only need to revoke that specific certificate, leaving the rest of your infrastructure untouched.

The Hidden Danger: Certificate Transparency (CT) Logs

While SAN certificates are vastly superior for security, they introduce a unique risk: information disclosure.

Certificate Transparency (CT) logs are public, append-only cryptographic ledgers that record every public TLS certificate issued. You can query these logs using tools like crt.sh. When you issue a SAN certificate, every domain listed is publicly visible.

If your DevOps team requests a SAN certificate that includes example.com alongside secret-unreleased-project.example.com, competitors, journalists, or attackers can scrape the CT logs to discover your unreleased product.

Best Practice: To mitigate this, avoid grouping highly sensitive internal subdomains on the same SAN certificate as your public-facing apex domains. Issue them separately.

Technical Implementation: The ACME Challenge Divide

When automating certificate issuance with Let's Encrypt or other ACME-compliant Certificate Authorities, the technical implementation differs drastically between SAN and Wildcard certificates.

Automating SAN Certificates (HTTP-01)

SAN certificates can be easily automated using the HTTP-01 challenge. The ACME client simply places a token on the web server, and the CA verifies it over HTTP. This requires no elevated privileges beyond writing to the webroot.

# Automating a SAN certificate via HTTP-01 challenge
certbot certonly --webroot -w /var/www/html \
  -d example.com -d api.example.com -d blog.example.com

Automating Wildcard Certificates (DNS-01)

Let's Encrypt and other CAs require the DNS-01 challenge to issue Wildcard certificates. You must prove control over the entire domain by provisioning a specific TXT record in your DNS zone.

To automate this, your web server's ACME client needs API access to your DNS provider (e.g., AWS Route53, Cloudflare).

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

This introduces a severe new attack vector. You are now forced to store highly privileged DNS API keys on your web servers. If the web server is compromised, the attacker doesn't just get your certificate; they get the ability to alter your global DNS routing.

Compliance and Regulatory Impact

Regulatory frameworks are increasingly hostile toward Wildcard certificates in sensitive environments.

• PCI DSS v4.0: The Payment Card Industry Data Security Standard enforces strict environment scoping. If you use the same Wildcard certificate in your Cardholder Data Environment (CDE) and your non-CDE environments, auditors may bring your non-secure systems into the scope of the PCI audit. PCI auditors strongly advise against using Wildcards anywhere near payment data.
• Extended Validation (EV) Restrictions: According to the CA/Browser Forum Baseline Requirements, Wildcard certificates cannot be issued with Extended Validation. If your organization requires the highest level of identity verification (the green bar/company name in older browsers, or strict compliance requirements), you must use Single-Domain or SAN certificates.

The Decision Matrix: When to Use Which

Despite the risks, there are still specific architectural patterns where Wildcards make sense. Here is the definitive guide on when to use each.

When to Use Multi-Domain (SAN) Certificates

• Production Environments: Any internet-facing application where Zero Trust and least privilege are required.
• Containerized Microservices: In Kubernetes, use tools like cert-manager to automatically provision individual SAN or single-domain certificates for every ingress route.
  ```yaml
  apiVersion: cert-manager.io/v1
  kind: Certificate
  metadata:
  name: api-cert
  spec:
  secretName: api-cert-tls
  issuerRef:
  name: letsencrypt-prod
  kind: ClusterIssuer
  dnsNames:
  • api.example.com
  • webhooks.example.com
    ```
• Compliance-Heavy Applications: Healthcare (HIPAA), Finance (PCI-DSS), or environments requiring EV certificates.
• Distinct Brand Portfolios: Securing brand-a.com and brand-b.com on a shared load balancer.

When to Use Wildcard Certificates

• Centralized Edge Termination: Wildcards are acceptable if the certificate is installed only on a highly secure edge appliance—like an AWS Application Load Balancer, a Cloudflare proxy, or a dedicated Web Application Firewall (WAF)—and the private key never leaves that appliance. Traffic should then be re-encrypted using internal SAN certificates before passing to the backend servers.
• Ephemeral Internal Development: Rapidly spinning up temporary internal environments (e.g., pr-123.dev.internal.com) where automated DNS-01 challenges are handled by a secure, centralized internal PKI (like HashiCorp Vault), rather than public CAs.

Managing the Chaos: Expiration and Observability

Transitioning from a single, manually managed Wildcard certificate to dozens or hundreds of automated SAN certificates dramatically improves your security posture. However, it shifts the operational burden from provisioning to observability.

When you have automated certificates renewing every 60 to 90 days across disparate CI/CD pipelines, Kubernetes clusters, and legacy VMs, the risk of a silent automation failure skyrockets. A broken cron job or an expired DNS API token can lead to a sudden, catastrophic outage when a certificate expires unnoticed.

This is where dedicated expiration tracking becomes critical. Using a platform like Expiring.at allows DevOps teams to continuously monitor the actual public-facing expiration dates of all SAN and single-domain certificates, regardless of the internal tooling used to provision them.

Instead of relying on the assumption that Let's Encrypt successfully renewed your certificate, Expiring.at acts as an independent verification layer. It queries your endpoints, tracks the cryptographic validity, and alerts your team via Slack, email, or webhooks long before an automation failure turns into a production outage.

Conclusion

The era of defaulting to Wildcard certificates for the sake of convenience is over. Driven by shrinking certificate lifespans, the necessity of ACME automation, and the adoption of Zero Trust architectures, the industry has definitively moved toward Multi-Domain (SAN) and single-domain certificates.

While Wildcards still have a niche place at the highly-secured network edge, distributing a single private key across multiple servers is an unacceptable risk in the modern threat landscape. By embracing automated SAN certificates and implementing robust, independent expiration monitoring, organizations can achieve both frictionless operations and cryptographic integrity.