Wildcard vs SAN Certificates for CDN: Making the Right Choice

Back in 2019, I got a call at 2 a.m. because a customer's new marketing domain wasn't loading through our CDN — just a stark certificate error in every browser. They'd assumed their shiny new wildcard certificate would cover it, but the domain was a completely different root than the one they'd secured. That's a mistake I've seen dozens of times since, and it's exactly why certificate selection matters more than most teams think when you're running behind a CDN.

What a Wildcard Certificate Actually Covers (and What It Doesn't)

When I explain a wildcard certificate to folks who are new to CDN SSL/TLS, I keep it simple: it's a single certificate that secures one domain and all of its immediate subdomains. If you own example.com, a wildcard for *.example.com will happily cover www.example.com, api.example.com, cdn.example.com, and anything else you spin up at that level. You don't need to reissue the cert every time marketing wants a new subdomain, which is why operations teams love them. We've had customers running hundreds of ephemeral preview subdomains like pr-1234.example.com who would've drowned in certificate management without one.

But the limits trip people up. A wildcard won't cover the apex domain itself unless you explicitly include it as a SAN entry — most providers do this by default now, but you should always check. More importantly, it only covers a single level. A cert for *.example.com does not cover *.api.example.com or sub.sub.example.com in most browser implementations. And it absolutely won't cover a different domain like example.net or example.co.uk. I once worked with a retailer who bought *.retail-brand.com and then tried to use it for retail-brand.eu — it just doesn't work that way. If your CDN needs to serve assets for multiple root domains, a wildcard alone won't cut it.

From a CDN edge perspective, wildcards are efficient. You deploy one cert and one private key across your entire edge footprint, and every PoP can terminate TLS for any matching subdomain. That's less config drift and faster deployments. You can verify what your wildcard actually covers with a quick OpenSSL check on the edge certificate — I still run this before any major rollout:

# Inspect the Subject Alternative Name field for wildcard coverage
openssl x509 -in /etc/cdn/certs/wildcard_example_com.crt -noout -text | grep -A 4 "Subject Alternative Name"

# Expected output for a properly configured wildcard:
# X509v3 Subject Alternative Name:
#   DNS:example.com, DNS:*.example.com

# Example Nginx edge configuration using the wildcard
server {
    listen 443 ssl http2;
    server_name *.example.com;
    ssl_certificate /etc/cdn/certs/wildcard_example_com.crt;
    ssl_certificate_key /etc/cdn/certs/wildcard_example_com.key;
    ssl_trusted_certificate /etc/cdn/certs/ca-chain.crt;
}

How SAN Certificates Solve the Multi-Domain Puzzle

A SAN certificate — also called a UCC or multi-domain SSL certificate — takes a different approach. Instead of saying "anything under this domain," it contains an explicit list of every fully qualified domain name it's allowed to secure. That list lives in the Subject Alternative Name extension, and it can mix completely different domains together. So a single SAN certificate could cover www.example.com, www.example.net, cdn.example.org, and api.partner-site.com all at once. For our CDN customers who manage a portfolio of brands or who've gone through acquisitions, that's incredibly handy.

When I'm helping a team decide on certificate selection, I always point out that SAN certificates give you precision. You enumerate exactly what you need, no more and no less. Need to add a new domain next month? You'll need to reissue the certificate with the new SAN entry added, which is where automation becomes critical. If you're not automating, that reissue process can be a headache — I've seen teams forget to include an older domain during reissue and accidentally drop coverage for it. That's why I usually recommend pairing SAN usage with solid monitoring, as we describe in Certificate Lifecycle Automation: From Issuance to Renewal at CDN Scale. And if you're worried about handshake privacy, it's worth understanding how your certificate choice interacts with TLS Fingerprinting Defense: Preventing Client Identification Through Handshake Analysis, since the SAN list is visible in the handshake.

Creating a SAN certificate means defining all those names up front in your CSR. Here's what that looks like with OpenSSL — this is the config snippet I give to junior engineers so they don't have to memorize the syntax:

# san_config.cnf - Define all domains for a multi-domain SSL cert
[req]
distinguished_name = req_distinguished_name
req_extensions = v3_req
prompt = no

[req_distinguished_name]
CN = www.example.com

[v3_req]
subjectAltName = @alt_names

[alt_names]
DNS.1 = www.example.com
DNS.2 = www.example.net
DNS.3 = cdn.example.org
DNS.4 = api.partner-site.com
DNS.5 = static.example.com

# Generate the CSR and key:
# openssl req -new -newkey rsa:2048 -nodes -keyout san.key -out san.csr -config san_config.cnf

# Verify the CSR contains all SANs:
# openssl req -in san.csr -noout -text | grep -A 6 "Subject Alternative Name"

Wildcard vs SAN on a CDN: Performance, Cost, and Management Compared

On a CDN, every millisecond in the TLS handshake counts, and your certificate choice affects both performance and day-to-day operations. In terms of raw handshake speed, there's virtually no difference — a wildcard certificate and a SAN certificate with a handful of entries will perform identically if they're using the same key type and chain. The real performance factor is what happens around the certificate. For instance, whether you've enabled OCSP Stapling for CDN: Eliminating Certificate Validation Delays matters far more than wildcard vs SAN. I've measured staple validation saving 80-150ms on high-latency mobile networks, which dwarfs any cert-type difference. For broader context on how TLS fits into the web platform, the HTTP Working Group Specifications and guides on web.dev Articles are excellent references for understanding these optimizations at a protocol level.

Where the two options really diverge is cost and operational risk. A wildcard lets you scale infinitely within one domain without paying for more domains or reissuing, but if that private key is compromised, every subdomain is at risk at once. A SAN certificate limits your blast radius — you can split domains across multiple SAN certs — but adding or removing a domain means reissuance and redeployment across all CDN edges. At scale, that redeployment isn't trivial. We've clocked full global edge propagation at 4-7 minutes for a single cert, and if you're doing that weekly for SAN updates, it adds up. For teams just starting out, my rule of thumb is: use a wildcard when you have many subdomains under one root, use a SAN certificate when you have a few distinct domains that must be served over HTTPS from the same CDN distribution.

Deploying Wildcard and SAN Certificates on Your CDN: A Practical Guide

If you're running on CloudFront, Fastly, Akamai, or Cloudflare, you aren't installing certs on a single origin — you're pushing them to 300+ edge PoPs. That's why the deployment workflow matters more than the purchase. For a wildcard, you'll generate a single CSR with *.example.com as the Common Name, validate via DNS-01 (adding a _acme-challenge TXT record), and upload once to your CDN's certificate manager. We've seen teams cut provisioning time from 45 minutes to under 90 seconds this way, but don't forget — that wildcard's private key is now your single point of failure. If it's compromised, you'll need to revoke and re-deploy everywhere at once.

SAN deployment is a bit more hands-on but gives you far better blast-radius control. You'll list every domain explicitly in the Subject Alternative Name field — example.com, www.example.com, api.example.net, cdn.example.io — and validate each one separately. Most CAs and ACME providers like Let's Encrypt cap you at 100 SAN entries per certificate, and public TLS certs now max out at 398 days validity, so automation is non-negotiable. We strongly recommend ACME-based auto-renewal with a 30-day renewal window; we've debugged too many 3 AM outages where a SAN cert covering 40 domains expired because someone forgot to add the 41st to the renewal script.

# Example: Generate a SAN CSR for multi-domain CDN setup
# Covers apex, www, and two alternate domains - wildcards can't do this
openssl req -new -newkey rsa:2048 -nodes \
  -keyout cdn-san.key -out cdn-san.csr \
  -subj "/CN=example.com" \
  -addext "subjectAltName=DNS:example.com,DNS:www.example.com,DNS:example.net,DNS:cdn.example.io"

# Verify SANs before submitting to your CA/CDN
openssl req -in cdn-san.csr -noout -text | grep -A 1 "Subject Alternative Name"

# For ACME/CDN automation (e.g., with certbot + Cloudflare/Fastly API)
certbot certonly --dns-cloudflare --dns-cloudflare-credentials ~/.secrets/cloudflare.ini \
  -d example.com -d www.example.com -d example.net -d cdn.example.io \
  --deploy-hook "fastly-tls-upload.sh"

Once issued, don't just upload and forget. Test your edge handshake immediately. Your CDN should serve the full chain (leaf + intermediate) and prefer ECDSA (P-256) for a ~30% smaller handshake vs RSA 2048. And if you're tuning for performance after deployment, you'll want to look at TLS Record Size Optimization: Balancing Latency and Throughput at the Edge — we've measured a 12-18ms TTFB improvement by dropping record size from 16KB to 4KB for users on high-loss mobile networks, which compounds nicely with a clean cert setup.

Advanced Patterns and Troubleshooting Real-World CDN Failures

Here's where teams get burned: mixing wildcard assumptions with SAN reality. A wildcard like *.example.com will not cover sub.sub.example.com or the apex example.com itself — that's the most common ticket we see. And it definitely won't cover example.net. If your CDN serves 4 brands across different TLDs, a single wildcard is useless. The modern pattern we recommend is a hybrid: use one wildcard per brand for infinite subdomains (*.brand-a.com) and wrap them all into a single SAN certificate if your CDN supports multi-SAN wildcards, or deploy separate certificates per domain using SNI. Cloudflare and Akamai handle this seamlessly; older origins behind an AWS ALB might need careful SNI mapping.

Troubleshooting-wise, 90% of "certificate invalid" errors at the edge aren't the cert — they're the chain or SNI misconfiguration. If users report ERR_CERT_COMMON_NAME_INVALID on eu.cdn.example.com, first check that the SAN list actually includes it — browsers don't fall back to CN anymore. Second, verify your CDN is serving the correct intermediate; an incomplete chain adds 300-600ms while clients fetch the missing intermediate via AIA, killing your cache hit ratio. Finally, if you're still relying on pinning to prevent mis-issuance, you're creating a bigger outage risk than you're solving. We've helped clients migrate away from it after a failed pin rotation took down their app for 4 hours. Look at Beyond Certificate Pinning: Modern Alternatives for CDN Trust Verification for CT monitoring and Expect-CT / DANE alternatives that don't brick your users.

One last non-negotiable: once your SAN or wildcard is stable at the edge, enforce it. Don't let an HTTP downgrade undo your work. Set a strict HSTS header like Strict-Transport-Security: max-age=63072000; includeSubDomains; preload at the CDN edge — that's two years — and consider submitting your apex domains to the hstspreload.org list. It'll add your domains to Chrome's static preload list, which eliminates the very first insecure request. Our guide on HSTS Preloading for CDN Domains: Permanent HTTPS Enforcement Guide walks through the preload pitfalls, especially how a wildcard HSTS policy can lock you out of HTTP-only staging subdomains if you're not careful.

Frequently Asked Questions