Two Ways to Cover Multiple Names — Two Different Risk Profiles
A wildcard certificate covers every subdomain at a single label level: *.example.com matches api.example.com and app.example.com. A SAN (Subject Alternative Name) certificate covers an explicit list of names — which can mix specific hosts and even unrelated domains in one certificate. The choice looks like a convenience decision at issuance time, but it's really a risk-architecture decision that determines what happens when renewal fails, how validation works, where private keys travel, and — the subject of this guide — what your monitoring needs to check. The short version: wildcards concentrate risk into one certificate with one dangerous renewal dependency, SANs distribute risk but invite coverage drift, and in both cases the thing to monitor is each hostname you serve, not each certificate you remember issuing.
What Wildcards Do and Don't Cover
Wildcard matching is narrower than intuition suggests, and the gaps are where outages hide. The asterisk matches exactly one DNS label: *.example.com covers api.example.com but not example.com itself (the apex needs its own SAN entry, which is why wildcards are commonly issued as *.example.com plus example.com together), and not v2.api.example.com — a second-level subdomain needs its own certificate or a *.api.example.com wildcard. Teams discover these rules operationally: a new environment at staging.eu.example.com ships with a hostname-mismatch error because everyone assumed 'the wildcard covers everything.' The certificate is valid, renewal is healthy, and the site is still broken for that hostname — a failure class that pure expiry monitoring cannot see, and exactly what host-mismatch detection exists for.
The Wildcard Renewal Dependency Nobody Documents
Publicly trusted CAs require DNS-01 validation for wildcard issuance — proving control of the whole namespace requires publishing a TXT record at _acme-challenge.example.com, which means your renewal automation holds a standing API credential for your DNS provider. That credential is the wildcard's hidden single point of failure: token rotations, DNS provider migrations, and permission tightening all silently break renewal, and the blast radius is every subdomain at once. A wildcard expiry doesn't take down a service; it takes down your API, your app, your docs, and your status page's CNAME simultaneously. There's a security dimension too: the wildcard's private key must exist on every server terminating TLS for any covered subdomain, so one compromised edge box exposes the whole namespace. None of this makes wildcards wrong — it makes them a concentration of risk that deserves proportionally serious monitoring.
Monitoring a Commercial SaaS?
FourSight's free plan includes 10 commercial-safe monitors with multi-region validation — free forever, no card.
Start Monitoring FreeSAN Certificates: Distributed Risk, Drift-Prone Coverage
SAN certificates enumerate their names explicitly, which cuts both ways. The upside: HTTP-01 validation suffices (no standing DNS credential), coverage is auditable by reading the certificate, and splitting names across several certificates means one renewal failure has a bounded blast radius. The downside is drift: every new hostname requires deliberately adding a SAN entry and re-issuing, and the standard failure is launching a new subdomain whose certificate work happened in a different ticket that never got done. Let's Encrypt allows up to 100 names per certificate (as published, mid-2026), which tempts teams into mega-SAN certificates that quietly rebuild the wildcard's concentration problem — one renewal failure, 100 names down — while adding a new one: every certificate reissue publishes your full hostname list to Certificate Transparency logs, so a mega-SAN cert is also an architecture disclosure.
Monitoring Implications: Hostnames, Not Certificates
The organizing principle for monitoring either flavor: your unit of monitoring is the served hostname, because that's the unit your users experience. Monitoring 'the wildcard cert' as one item misses the CDN edge that serves a stale copy for one subdomain and the new hostname the wildcard doesn't actually cover.
| Risk | Wildcard | SAN | What monitoring catches it |
|---|---|---|---|
| Expiry blast radius | Entire subdomain level at once | Bounded by names on the failing cert | Per-hostname expiry countdown |
| Renewal dependency | DNS-01 → standing DNS API credential | HTTP-01 possible; no standing credential | Expiry alert fires when renewal stalls |
| Coverage gap | Apex and deeper levels not covered | New hostnames never added to SAN list | Host-mismatch detection per hostname |
| Deployment drift | Same cert must reach every edge/server | Different certs on different services | Checking the served cert from outside |
| Key exposure | One key across the whole namespace | Keys scoped to each cert's names | (Architecture choice — not a monitoring fix) |
The Dynamic-Namespace Case: Per-Customer Subdomains
The scenario where wildcards are genuinely irreplaceable deserves its own treatment: SaaS products serving customer1.yourapp.com, customer2.yourapp.com, and a new subdomain every time sales closes a deal. Issuing per-name certificates at signup speed is possible (many platforms do it with ACME automation) but operationally heavier than one wildcard that covers the namespace by construction. If you take the wildcard route here, adjust your monitoring to match the shape of the risk: you can't monitor every customer subdomain individually, so monitor a representative set — the apex, your own app subdomain, and a canary customer subdomain on each distinct piece of serving infrastructure (each load balancer, each CDN distribution). The canary matters because wildcard deployments drift per-infrastructure, not per-name: if one edge serves a stale wildcard, every customer name on that edge is affected identically, and one well-placed canary sees it. Add a heartbeat on the DNS-01 renewal job itself, and this estate is as observable as a static one.
Choosing Between Them (and Monitoring Your Choice)
A defensible default: use SAN certificates scoped to services for your core, stable hostnames, and reserve wildcards for genuinely dynamic namespaces — per-customer subdomains, preview environments, anything where hostnames appear faster than issuance can follow. If you run a wildcard, treat its renewal path as production infrastructure: document the DNS credential it depends on, put a heartbeat on the renewal job, and set expiry alerting thresholds assuming the worst-case debugging time is 'we have to figure out the DNS provider API from scratch.' Whichever you choose, wire every public hostname into external SSL monitoring with host-mismatch detection enabled — the choice between wildcard and SAN changes which failure you'll eventually have, and per-hostname monitoring is the strategy that catches both.