--- title: "Wildcard vs SAN Certificates: What Each Means for Monitoring | FourSight" description: "Wildcards cover one label level, SAN certs cover explicit names — and each fails differently. How to monitor coverage gaps, not just expiry dates." lang: en json-ld: | [ { "@context": "https://schema.org", "@type": "Article", "headline": "Wildcard vs SAN Certificates: What Each Means for Monitoring", "description": "Wildcards cover one label level, SAN certs cover explicit names — and each fails differently. How to monitor coverage gaps, not just expiry dates.", "author": { "@type": "Organization", "name": "FourSight" }, "publisher": { "@type": "Organization", "name": "FourSight" }, "url": "https://foursight.cloud/guides/wildcard-vs-san-certificate-monitoring", "mainEntityOfPage": "https://foursight.cloud/guides/wildcard-vs-san-certificate-monitoring", "datePublished": "2026-07-14", "dateModified": "2026-07-14", "wordCount": 1600 }, { "@context": "https://schema.org", "@type": "BreadcrumbList", "itemListElement": [ { "@type": "ListItem", "position": 1, "name": "Home", "item": "https://foursight.cloud" }, { "@type": "ListItem", "position": 2, "name": "Guides", "item": "https://foursight.cloud/guides" }, { "@type": "ListItem", "position": 3, "name": "Wildcard vs SAN Certificates: What Each Means for Monitoring", "item": "https://foursight.cloud/guides/wildcard-vs-san-certificate-monitoring" } ] }, { "@context": "https://schema.org", "@type": "FAQPage", "mainEntity": [ { "@type": "Question", "name": "Does *.example.com cover example.com itself?", "acceptedAnswer": { "@type": "Answer", "text": "No. The wildcard matches exactly one subdomain label, so *.example.com covers api.example.com but not the bare apex domain. That's why wildcards are typically issued with example.com included as an additional SAN entry — and why it's worth verifying yours was." } }, { "@type": "Question", "name": "Does a wildcard cover second-level subdomains like v2.api.example.com?", "acceptedAnswer": { "@type": "Answer", "text": "No — the asterisk matches a single label, so *.example.com covers api.example.com but not v2.api.example.com. Deeper levels need their own certificate or their own wildcard (*.api.example.com). Host-mismatch monitoring on each served hostname is how you catch these gaps before users do." } }, { "@type": "Question", "name": "Why do wildcard certificates require DNS validation?", "acceptedAnswer": { "@type": "Answer", "text": "CA/Browser Forum rules require proving control of the entire namespace, which HTTP-01 (fetching a file from one specific host) can't demonstrate. DNS-01 — publishing a TXT record at _acme-challenge.example.com — proves zone control. The operational consequence is a standing DNS API credential in your renewal path, which is the most common wildcard renewal failure point." } }, { "@type": "Question", "name": "Are SAN certificates safer than wildcards?", "acceptedAnswer": { "@type": "Answer", "text": "They trade risks rather than eliminating them. SANs bound the blast radius of a renewal failure and avoid the standing DNS credential, but they drift — new hostnames silently ship without coverage — and large SAN lists rebuild the concentration problem. Monitoring each served hostname for expiry, chain validity, and name coverage protects you under either choice." } }, { "@type": "Question", "name": "Should I monitor per certificate or per hostname?", "acceptedAnswer": { "@type": "Answer", "text": "Per hostname. Users connect to hostnames, and a single certificate can be correctly deployed on one endpoint and stale, missing, or mismatched on another (a CDN edge, a legacy load balancer). Per-hostname checks of the actually-served certificate are the only view that matches user experience." } } ] } ] --- [FourSight ](/) [Features](/#features)[Pricing](/pricing)[Guides](/guides)[Glossary](/glossary)[FAQ](/faq) [Login](/auth)[Start free](/auth?signup=true) [Start free](/auth?signup=true) [All Guides](/guides) Reliability & Infrastructure # Wildcard vs SAN Certificates: What Each Means for Monitoring Wildcards cover one label level, SAN certs cover explicit names — and each fails differently. How to monitor coverage gaps, not just expiry dates. 8 min read Guide Published Jul 14, 2026 ## Two Ways to Cover Multiple Names — Two Different Risk Profiles A [wildcard certificate](/glossary/wildcard-certificate "Glossary: 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. Related Reading - [→ Feature: SSL certificate monitoring](/features/ssl-monitoring) - [→ Glossary: wildcard certificate](/glossary/wildcard-certificate) ## 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](/glossary/dns "Glossary: 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](/glossary/txt-record "Glossary: 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](/glossary/blast-radius "Glossary: 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](/glossary/ssl-tls "Glossary: 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. Related Reading - [→ Let's Encrypt auto-renewal failures: ACME failure modes explained](/guides/lets-encrypt-renewal-failures) ### Monitoring a Commercial SaaS? FourSight's free plan includes 10 commercial-safe monitors with multi-region validation — free forever, no card. [Start Monitoring Free](/auth?signup=true) ## SAN 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](/glossary/lets-encrypt "Glossary: 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](/glossary/cdn "Glossary: CDN") edge that serves a stale copy for one subdomain and the new hostname the wildcard doesn't actually cover. **💡** One monitor per public hostname is the honest budget. A typical SaaS with app, api, www, status, docs, and a marketing site is six SSL monitors — on FourSight that fits comfortably inside a Growth plan alongside your HTTP checks, and each monitor validates expiry, chain, and hostname coverage on every cycle. 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. [How FourSight validates hostname coverage →](/features/ssl-monitoring) Related Reading - [→ How to audit SSL certificates across your fleet](/guides/auditing-ssl-certificates-across-fleet) - [→ How SSL certificates expire silently: the failure modes](/guides/how-ssl-certificates-expire-silently) ## Frequently Asked Questions ### Does \*.example.com cover example.com itself? ### Does a wildcard cover second-level subdomains like v2.api.example.com? ### Why do wildcard certificates require DNS validation? ### Are SAN certificates safer than wildcards? ### Should I monitor per certificate or per hostname? #### Related Guides [What Is Uptime Monitoring? The Complete Guide 12 min ](/guides/what-is-uptime-monitoring)[Multi-Region Monitoring Explained 8 min ](/guides/multi-region-monitoring-explained)[SSL Certificate Expiry Monitoring 10 min ](/guides/ssl-certificate-expiry-monitoring)[How SSL Certificates Expire Silently: The Failure Modes 8 min ](/guides/how-ssl-certificates-expire-silently) #### Compare FourSight [vs UptimeRobot →](/compare/uptimerobot-alternative)[vs StatusCake →](/compare/statuscake-alternative)[vs Pingdom →](/compare/pingdom-alternative) 10 free commercial-safe monitors [View Pricing](/pricing) ## Protect Your SaaS Revenue Start monitoring in under 60 seconds. [Start Monitoring Free](/auth?signup=true)[View Pricing](/pricing) FourSight © 2026 [TetraCore](https://tetracorehq.com/). All rights reserved. FourSight is a TetraCore product — Bowling Green, Ohio. Product [Pricing](/pricing)[Guides](/guides)[Glossary](/glossary)[FAQ](/faq)[About](/about)[For Agencies](/solutions/agencies)[For Startups](/solutions/startups)[Privacy](/privacy)[Terms](/terms) Features [Cron Job & Heartbeat Monitoring](/features/cron-job-monitoring)[SSL Certificate Monitoring](/features/ssl-monitoring)[Status Pages](/features/status-pages)[Domain Expiry Monitoring](/features/domain-expiry-monitoring)[DNS Monitoring](/features/dns-monitoring)[Port Monitoring](/features/port-monitoring) Compare [All comparisons](/compare)[vs UptimeRobot](/compare/uptimerobot-alternative)[vs StatusCake](/compare/statuscake-alternative)[vs Freshping](/compare/freshping-alternative)[vs Pingdom](/compare/pingdom-alternative)[vs Pulsetic](/compare/pulsetic-alternative)[vs Better Stack](/compare/better-stack-alternative)[vs Uptime Kuma](/compare/uptime-kuma-alternative)[vs Cronitor](/compare/cronitor-alternative)[vs Healthchecks.io](/compare/healthchecks-alternative)[vs Hyperping](/compare/hyperping-alternative) Pricing Guides [UptimeRobot Pricing](/compare/uptimerobot-pricing)[StatusCake Pricing](/compare/statuscake-pricing)[Pingdom Pricing](/compare/pingdom-pricing)[Better Stack Pricing](/compare/better-stack-pricing)[Uptime Kuma Pricing](/compare/uptime-kuma-pricing)[Cronitor Pricing](/compare/cronitor-pricing)[Healthchecks.io Pricing](/compare/healthchecks-pricing)[Hyperping Pricing](/compare/hyperping-pricing)[Pulsetic Pricing](/compare/pulsetic-pricing)