Wildcard vs SAN Certificates: What Monitoring Teams Need to Track
A wildcard certificate's coverage grows automatically. A SAN certificate's coverage is frozen at issuance. Learn what actually changes for your monitoring setup with each and where the coverage gaps quietly hide.
A single certificate can cover your entire domain. Another kind of certificate can cover a dozen completely unrelated domains at once. Both are valid ways to secure a growing infrastructure and both create a specific, easy to miss monitoring blind spot if your team doesn't know which one you're actually running.
This isn't a "which one should you buy" guide. It's about what changes for your monitoring setup once you have one, the other, or both because the failure mode for each is genuinely different, and treating them the same is how a subdomain or a secondary domain quietly ends up unprotected.
The Two Minute Version
A wildcard certificate secures one domain and all of its first level subdomains using a single certificate yourdomain.com covers app.yourdomain.com, blog.yourdomain.com, shop.yourdomain.com, and so on, all under one certificate.
A SAN certificate (Subject Alternative Name, sometimes called a multi domain SSL certificate) covers a specific, explicitly listed set of domain names which can be entirely unrelated domains, not just subdomains of one root.
The monitoring implication in one sentence: a wildcard certificate's coverage grows automatically as you add subdomains, while a SAN certificate's coverage is frozen at exactly whatever list was configured when it was issued and neither of those facts is obvious just by looking at your site working correctly today.
Head to Head: Wildcard vs SAN
| Wildcard Certificate | SAN Certificate | |
|---|---|---|
| Covers | One domain + all first-level subdomains | An explicit, named list of domains/subdomains |
| New subdomain added later | Automatically covered, no certificate change needed | Not covered until manually added to the certificate and reissued |
| Different root domains | Not supported one wildcard covers one root domain only | Fully supported can cover entirely unrelated domains on one certificate |
| Monitoring blind spot risk | Low for subdomains, but a second level subdomain (api.eu.yourdomain.com) is NOT covered by yourdomain.com | Higher any domain not explicitly on the list at issuance is simply unprotected, with no automatic inclusion |
| What to track | Whether new subdomains actually exist under the wildcard's scope, and whether any are second level | The complete, current list of domains actually included, versus the list of domains that should be included |
| Typical failure mode | A nested subdomain silently assumed to be covered, when it isn't | A newly added domain or service quietly launched without ever being added to the certificate |
Why the Difference Matters for Monitoring, Not Just Purchasing
Most teams choose between wildcard and SAN certificates based on cost, issuance convenience, or existing infrastructure a purchasing decision, made once. What often doesn't get revisited is that this decision permanently shapes what your TLS monitoring actually needs to check.
A wildcard certificate creates an assumption of coverage that isn't always accurate: yourdomain.com genuinely does not cover api.eu.yourdomain.com, because that's a second level subdomain, one level deeper than a standard wildcard reaches. Teams who assume "wildcard means everything under our domain is covered" are frequently wrong the moment they add a nested subdomain.
A SAN certificate creates a different, arguably more dangerous assumption: that everything currently live is on the list. Unlike a wildcard, a SAN certificate has zero automatic coverage a new domain, a new regional site, or a newly spun-up service is invisible to that certificate until someone explicitly adds it and reissues.
The Coverage Gap Problem
Here's the operational risk in practice: your monitoring might correctly confirm that your certificate itself is valid and not expired, while completely missing that a specific domain or subdomain isn't actually covered by it at all.
This happens because most basic uptime or SSL checks validate one thing: does this specific URL have a valid, non expired certificate right now. That check passes even when the broader picture do we actually have complete coverage across every domain and subdomain we run is badly out of date.
A few specific ways this plays out:
- A new subdomain launches without anyone checking whether it falls inside the wildcard's actual scope, particularly if it's a second level subdomain that a standard wildcard doesn't reach.
- A SAN certificate's domain list drifts from reality over time as teams launch new regional sites, staging environments, or partner facing domains without a formal process to add them to the existing certificate.
- Nobody maintains a running certificate inventory mapping which certificate is supposed to cover which domains, so there's no single source of truth to check drift against.
- A domain gets manually pointed at existing infrastructure (a quick DNS change) without anyone confirming SSL coverage was part of that launch checklist.
How to Monitor Each Type Correctly
For Wildcard Certificates
Monitor for second level subdomain exposure specifically. yourdomain.com does not cover sub.sub.yourdomain.com. If your infrastructure uses nested subdomains anywhere common in multi region or multi environment setups those need either their own certificate coverage or a nested wildcard, and monitoring needs to explicitly check for this rather than assume blanket coverage.
Maintain a list of every subdomain currently in production, and periodically confirm each one is genuinely first-level (covered) rather than assumed to be.
For SAN Certificates
Monitor the domain list itself as a piece of configuration that can drift, not just the certificate's validity. This means maintaining a certificate inventory a running record of exactly which domains a given SAN certificate is supposed to cover and checking new domains against it before they go live, not after.
The critical monitoring signal for SAN certificates is a comparison: domains actually live in production versus domains actually listed on the certificate. Any domain live in the first list but missing from the second is a real, unprotected gap.
For Both Types
Wildcard SSL monitoring and SAN certificate monitoring share one non negotiable requirement: check every individual hostname your infrastructure actually serves, not just the root domain. A certificate check against yourdomain.com alone tells you nothing about whether checkout.yourdomain.com or partner portal.com (if included on a SAN cert) are actually protected.
A Practical Production Scenario
A growing SaaS company runs its main product under a wildcard certificate covering company.com. As the product scales, the infrastructure team spins up a new customer facing analytics service at analytics.eu.company.com a second level subdomain, added quickly to support a specific enterprise client's regional data requirements.
Nobody flags it during launch, because the assumption across the team is simple: "we have a wildcard, everything under company.com is covered." The service goes live, functions correctly, and passes every existing uptime check, since those checks only confirm the service responds not whether its specific certificate coverage is actually valid.
Weeks later, a security conscious enterprise customer's own compliance scan flags the analytics subdomain as presenting an invalid certificate the wildcard genuinely doesn't extend to a second level subdomain, and no additional certificate was ever issued for it. What should have been caught at launch instead surfaces through a customer's own audit, an embarrassing way to learn about a coverage gap.
Recommended Monitor Setup
- Maintain a certificate inventory: every domain and subdomain in production, mapped to the specific certificate meant to cover it.
- For wildcard certificates, explicitly flag any second level subdomain as needing separate verification or its own coverage.
- For SAN certificates, compare the certificate's actual domain list against what's live in production on a recurring schedule, not just at issuance.
- Add a certificate coverage check to your service launch checklist, not just a DNS and uptime check.
- Monitor every individual hostname independently, rather than relying on a single root domain check to represent the whole certificate's coverage.
- Alert specifically when a live, monitored domain's certificate doesn't match the expected wildcard or SAN certificate on file.
Best Practices for Certificate Inventory and Monitoring
Keep a living certificate inventory, not a one time document. Record every domain and subdomain your infrastructure serves, and which specific certificate is supposed to cover each one then revisit it as part of any new domain or service launch, not just annually.
Treat second level subdomains as their own category for wildcard coverage. Don't assume "we have a wildcard" answers the coverage question without checking whether any subdomain goes one level deeper than the wildcard reaches.
Add certificate coverage to your launch checklist. A new domain or subdomain going live should trigger an explicit check: is it covered by an existing certificate, or does it need to be added to one?
Monitor SAN certificates for list drift, not just expiry. The domain list itself is configuration that can go stale exactly like any other setting check it against production reality on a schedule.
Check every hostname individually, not just the primary domain. A single check against your root domain says nothing about coverage for every subdomain or additional domain your certificate is meant to protect.
Assign ownership for keeping the certificate inventory current. Without a named owner, this kind of cross cutting configuration tends to drift silently as different teams launch new domains independently.
Common Mistakes
Assuming a wildcard covers everything under the domain, including second level subdomains. It doesn't this is one of the most common and easily overlooked gaps in wildcard coverage.
Letting a SAN certificate's domain list go stale. New domains and services launch faster than certificate lists get updated, unless there's a deliberate process tying the two together.
Monitoring only the root domain and assuming it represents full coverage. Every additional domain or subdomain needs its own explicit check coverage on one hostname says nothing about coverage on another.
Not maintaining any certificate inventory at all. Without a documented mapping of domains to certificates, there's no way to systematically check for drift only to discover gaps reactively, often through an external audit or an unlucky customer.
Treating certificate coverage as a one time setup task. New domains and subdomains launch continuously in a growing infrastructure; certificate coverage needs the same ongoing attention as any other production configuration.
Skipping certificate checks during service launches. DNS and basic uptime checks are common launch checklist items; certificate coverage verification is just as important and far more often forgotten.
Start Monitoring Every Domain, Not Just the One You Remembered
A wildcard or SAN certificate only protects what it actually covers not what you assume it covers. As your infrastructure grows, that gap between assumption and reality is exactly where a real, customer facing certificate error tends to show up first.
Start a 30 day Statixoup free trial and configure SSL monitoring across every domain and subdomain you actually run, not just the ones you remember to check. The next new subdomain you launch won't slip through unmonitored.
