When managing SSL/TLS for anything beyond a single website, the certificate strategy quickly becomes an architectural decision rather than a checkbox task. Should you use a wildcard certificate to cover unlimited subdomains? Or is a multi-domain (SAN) certificate the better option for flexibility and isolation?
For hosting providers, SaaS platforms, agencies, and enterprises running dozens (or thousands) of domains, this decision affects security posture, automation complexity, cost structure, and operational risk.
Let’s break down the real trade-offs.
Understanding the Basics (Quickly)
Before diving into architecture implications, a quick recap:
Wildcard Certificate
A wildcard certificate secures:
*.example.com
This covers:
- app.example.com
- blog.example.com
- api.example.com
But not:
- example.com (unless explicitly included)
- sub.app.example.com
Multi-Domain (SAN) Certificate
A SAN (Subject Alternative Name) certificate can secure:
example.com
example.net
api.example.org
client-site.com
One certificate, multiple fully qualified domain names.
1. Security Surface Area: Shared Risk vs Segmented Risk
Wildcard: Large Blast Radius
A wildcard private key typically lives on multiple servers. If that private key is compromised:
Every subdomain is compromised.
This is especially risky in:
- Shared hosting environments
- Microservices with different trust boundaries
- Multi-tenant SaaS systems
If one system gets breached and the wildcard private key is exfiltrated, the attacker can impersonate any subdomain.
SAN Certificates: More Granular Exposure
SAN certificates allow segmentation:
- Group domains by function
- Separate staging and production
- Isolate high-risk applications
Compromise of one SAN certificate does not automatically affect unrelated domains outside that certificate.
Architectural Insight:
In zero-trust or microservice architectures, segmentation often outweighs convenience.
2. Operational Simplicity vs Scalability
Wildcard: Simple to Deploy
One certificate. Unlimited subdomains.
For environments like:
- cPanel/hosting clusters
- Agencies managing subdomains
- SaaS apps generating dynamic subdomains
Wildcard certificates reduce overhead significantly.
However, they require DNS validation (DNS-01 challenge) when issued via Let’s Encrypt or other ACME providers. That means:
- API access to DNS
- Automation complexity
- Careful secret management
SAN Certificates: Explicit Domain Management
Each domain must be explicitly added. This creates:
- More tracking requirements
- Certificate reissuance when adding domains
- Potential SAN count limits
But automation tools and ACME clients make this manageable at scale.
Architectural Insight:
Wildcard simplifies domain growth within a namespace.
SAN simplifies control across namespaces.
3. Performance Considerations
Performance differences are subtle but real.
SAN Certificates
Large SAN certificates increase:
- Certificate size
- TLS handshake payload
- Slight latency increase
In high-performance environments (CDNs, APIs with millions of connections), this matters.
Wildcard Certificates
Typically smaller than large SAN certificates, especially if SAN lists are extensive.
However, in most real-world applications, performance differences are negligible compared to network latency and application logic.
4. Automation and DevOps Workflows
Modern infrastructure relies heavily on automation.
With Wildcards
Pros:
- No need to reissue for new subdomains
- Works well with dynamic environments
Cons:
- Requires DNS API automation
- Harder to delegate certificate management to isolated teams
With SAN Certificates
Pros:
- Easier HTTP-01 validation
- Clear domain ownership tracking
- Better for multi-team governance
Cons:
- Needs updates when domains change
- Risk of “certificate sprawl”
DevOps Insight:
Wildcard works well for centralized control.
SAN works better for distributed teams.
5. Multi-Tenant Hosting and SaaS Platforms
This is where the decision becomes strategic.
Scenario A: SaaS with Custom Domains
If customers use:
customer1.yourapp.com
customer2.yourapp.com
Wildcard is efficient.
If customers use:
customer1.com
customer2.com
You need SAN certificates (or individual certificates per domain).
Large SaaS platforms often combine:
- Wildcard for internal/system domains
- Automated per-domain certificates for customer domains
6. Revocation and Incident Response
Imagine a certificate needs revocation.
Wildcard Revocation
Revoking means:
- Every subdomain is affected
- Emergency reissuance required
- Potential downtime across services
SAN Revocation
Only domains in that SAN certificate are affected.
In regulated industries (PCI DSS, finance, healthcare), this containment capability is critical.
7. Compliance and Governance
Organizations operating under compliance frameworks often prefer:
- Domain isolation
- Certificate lifecycle auditing
- Limited key distribution
Wildcard certificates often conflict with strict internal policies because:
- Private keys are distributed more widely
- Access control becomes harder
SAN or individual certificates allow tighter governance controls.
8. Cost Structure
Historically:
- Wildcard certificates were more expensive
- SAN certificates increased cost per domain
Today, with providers like Let’s Encrypt offering free certificates, cost is less about purchase price and more about:
- Operational overhead
- Automation maintenance
- Incident response complexity
Commercial providers still price differently for:
- Extended Validation (EV)
- Large SAN bundles
- High warranty certificates
9. Certificate Transparency (CT) Implications
All publicly trusted certificates are logged in Certificate Transparency logs.
Wildcard Visibility
A wildcard entry:
*.example.com
Does not expose specific subdomains.
SAN Certificates
Every domain listed becomes publicly visible.
This can:
- Reveal staging domains
- Expose internal project names
- Leak business relationships
Security-conscious companies sometimes prefer wildcards to reduce CT exposure — though obscurity is never real security.
10. Hybrid Strategy: The Most Common Enterprise Approach
In mature infrastructures, the answer is rarely “either/or.”
Typical enterprise model:
- Wildcard for:
- Internal microservices
- Platform subdomains
- Dev/staging environments
- SAN or individual certificates for:
- Customer-facing domains
- High-security services
- Compliance-bound systems
This layered approach balances:
- Risk containment
- Automation efficiency
- Governance control
11. When to Choose Wildcard
Wildcard certificates are ideal when:
- You control the entire domain namespace
- Subdomains are created dynamically
- Infrastructure is centralized
- DNS automation is available
- Security boundaries are uniform
Example use cases:
- Internal API clusters
- SaaS subdomain-based customers
- Hosting reseller environments
12. When to Choose SAN Certificates
SAN certificates are better when:
- Domains span multiple TLDs
- You need segmentation
- Different teams manage different services
- Compliance requirements demand isolation
- Customer-owned domains are involved
Example use cases:
- Agencies managing multiple client domains
- Enterprises with multiple brands
- Multi-region infrastructure with separated trust zones
Final Thoughts: Architecture First, Certificate Second
The choice between wildcard and SAN certificates is not about convenience. It’s about:
- Trust boundaries
- Key management strategy
- Automation maturity
- Incident response planning
- Compliance posture
If your infrastructure is simple, wildcard certificates reduce friction.
If your infrastructure is complex, segmentation usually wins.
The real mistake is treating certificates as a deployment afterthought. SSL/TLS is part of your security architecture — and your certificate strategy should reflect that.