The Death of the Wildcard? Navigating Wildcard vs. Multi-Domain Certificates in 2024
For over a decade, the Wildcard certificate was the undisputed "easy button" for IT administrators. If you needed to secure a dozen new subdomains for a growing application, purchasing a single *.example.com certificate and deploying it across your infrastructure saved time, money, and administrative headaches.
But the landscape of web security has fundamentally shifted.
The rise of Zero Trust Architecture (ZTA), the ubiquity of automated certificate provisioning via the ACME protocol, and Google's impending mandate to reduce maximum certificate lifespans to just 90 days have turned the traditional arguments for Wildcard certificates upside down. Today, relying on Wildcards often introduces unacceptable security risks and compliance violations.
In this comprehensive guide, we will break down the technical differences between Wildcard and Multi-Domain (SAN) certificates, analyze the severe "blast radius" security risks associated with shared private keys, and provide a concrete decision matrix for when to use each in modern infrastructure.
Understanding the Mechanics: Wildcard vs. Multi-Domain
Before diving into architectural decisions, it is critical to understand the technical boundaries of both certificate types.
Wildcard Certificates: The One-Size-Fits-Most Approach
A Wildcard certificate uses an asterisk (*) in the domain name field to secure a base domain and an unlimited number of its subdomains.
The Technical Limitation: The asterisk only matches exactly one level of subdomains.
For example, a certificate issued to *.example.com will successfully secure:
* api.example.com
* blog.example.com
* mail.example.com
It will not secure:
* dev.api.example.com (Requires a separate *.api.example.com certificate)
* example.com (The root domain is not covered unless explicitly added as a Subject Alternative Name by the Certificate Authority).
Multi-Domain (SAN) Certificates: The Precision Tool
Multi-Domain certificates, also known as SAN (Subject Alternative Name) or UCC (Unified Communications Certificate), secure multiple distinct domains or subdomains under a single certificate using the subjectAltName X.509 extension.
The Technical Capability: A single SAN certificate can secure entirely different Top-Level Domains (TLDs) and deeply nested subdomains simultaneously. Most CAs allow between 100 and 250 SANs per certificate.
You can easily inspect the SANs on any given certificate using OpenSSL. Here is how you check the SANs of a live server:
echo | openssl s_client -connect example.com:443 2>/dev/null | openssl x509 -noout -ext subjectAltName
Output example:
X509v3 Subject Alternative Name:
DNS:example.com, DNS:example.net, DNS:api.example.org, DNS:dev.internal.example.com
This precision allows DevOps teams to explicitly define exactly which hostnames are secured by a specific cryptographic key, leaving no room for ambiguity.
The "Blast Radius" Problem: Why Security Teams Hate Wildcards
The primary argument against Wildcard certificates in modern infrastructure is the concept of the "blast radius." When you use a Wildcard certificate, you are inherently violating the principle of least privilege.
1. Private Key Sprawl
To use a Wildcard certificate across multiple servers, the associated private key must be exported and copied to every single load balancer, web server, and edge device hosting those subdomains.
Tracking where a private key lives becomes an operational nightmare. If a low-security development server hosting test-blog.example.com is compromised, the attacker gains access to the Wildcard private key. With that key, they can now perform Man-in-the-Middle (MitM) attacks or decrypt traffic for your highly secure production environment at api.example.com.
We saw this exact scenario play out in the widespread VPN Edge Device Exploits of 2023 and 2024. Advanced Persistent Threat (APT) groups targeted vulnerabilities in edge VPN devices. Because many organizations installed their primary corporate Wildcard certificate on these VPNs, attackers were able to steal the private keys and seamlessly intercept internal corporate traffic without triggering certificate mismatch warnings.
2. Subdomain Takeover and CORS Bypasses
Wildcard certificates amplify the danger of dangling DNS records. If an attacker gains control of an abandoned subdomain, a Wildcard certificate allows them to instantly spin up a perfectly trusted, encrypted phishing site (e.g., secure-login.example.com).
This is not a theoretical risk. In a highly publicized incident, hackers found an abandoned AWS CloudFront distribution belonging to Epic Games. Because Epic utilized a Wildcard certificate, the attackers were able to claim the subdomain. The presence of the valid Wildcard certificate allowed them to bypass Cross-Origin Resource Sharing (CORS) restrictions, ultimately enabling them to steal authentication tokens from millions of Fortnite players.
3. ALPACA Attacks
Wildcards also facilitate cross-protocol attacks like ALPACA (Application Layer Protocol Confusion - Analyzing and Mitigating Cracks in TLS). In this attack, a threat actor tricks a victim's browser into sending HTTPS requests to an FTP or email server that happens to share the same Wildcard certificate as the web server. Because the TLS certificate is technically valid for both services, the browser sends the payload (including session cookies), which the attacker can then extract.
Multi-Domain Vulnerabilities: The Certificate Transparency (CT) Log Leak
While SAN certificates solve the blast radius problem by allowing you to use unique private keys for specific groupings of domains, they come with their own unique operational hazard: Information Leakage.
Since 2018, all major browsers require public TLS certificates to be logged in Certificate Transparency (CT) logs. These logs are public, searchable databases of every certificate issued by a trusted CA. Security researchers and attackers routinely use tools like Censys and Shodan to monitor CT logs for reconnaissance.
If an IT administrator creates a single SAN certificate that mixes public-facing domains with internal, sensitive subdomains, they are broadcasting their internal network topology to the world.
Imagine a SAN certificate with the following entries:
* www.example.com
* api.example.com
* jira-internal.example.com
* payroll-staging-v2.example.com
By simply searching CT logs for example.com, an attacker immediately knows exactly where your internal Jira instance and staging payroll applications live.
The Solution: Never mix external and internal hostnames on a public SAN certificate. Use separate Single-Domain or SAN certificates to isolate infrastructure, and strongly consider using a Private CA (like HashiCorp Vault or an internal Microsoft CA) for non-public domains so they are not published to public CT logs.
The 90-Day Mandate and the Automation Revolution
Historically, the strongest argument for Wildcard certificates was administrative overhead. Buying and manually installing 50 individual certificates was a terrible use of an engineer's time.
Two major shifts have destroyed this argument.
1. The ACME Protocol and cert-manager
The Automated Certificate Management Environment (ACME) protocol, popularized by Let's Encrypt, has made certificate provisioning entirely programmatic.
In modern containerized environments like Kubernetes, tools like cert-manager make issuing highly specific, Single-Domain or SAN certificates completely frictionless. You no longer need a Wildcard; you simply define the exact domains you need in a YAML manifest, and the infrastructure handles the rest.
apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
name: api-example-com
namespace: production
spec:
secretName: api-example-com-tls
duration: 2160h # 90 days
renewBefore: 360h # 15 days
issuerRef:
name: letsencrypt-prod
kind: ClusterIssuer
dnsNames:
- api.example.com
- grpc.example.com
With automation, issuing 100 individual certificates takes the exact same amount of human effort as issuing 1 Wildcard certificate: zero.
2. Google's 90-Day Validity Mandate
The Google Chromium root program has announced its intention to reduce the maximum lifespan of public TLS certificates from 398 days to just 90 days.
When this mandate takes effect (expected in late 2024 or 2025), manual certificate management will become mathematically impossible for most organizations. You will be forced to adopt ACME and automated provisioning. Once you implement automation to handle 90-day renewals, the administrative need for Wildcard certificates vanishes entirely.
Furthermore, as the industry prepares for Post-Quantum Cryptography (PQC), organizations need "crypto-agility." Replacing a compromised Wild