Wildcard vs SAN certificates for monitoring

wildcard vs san certificate monitoring boils down to one notAfter on the cert but many hostnames in DNS—every name customers use still needs a live TLS check, not just the CN on the invoice.

Platform teams buy *.example.com to simplify ACME while product spins up app, api, and legacy hostnames weekly. Security wants a single renewal calendar row; SRE knows anycast and SNI can serve different material on the same wildcard if someone mis-uploaded a default cert.

The mistake is monitoring only the wildcard’s apex check while a vanity subdomain hits a forgotten default certificate with yesterday’s dates. Another is assuming SAN listing equals routing—DNS can point elsewhere entirely.

You will compare wildcard and multi-SAN coverage rules, design hostname inventories for monitors, and read one shared expiry without missing per-vhost presentation bugs.

What to check

Wildcard certificates cover one label: *.example.com matches app.example.com but not example.com itself unless also listed, and not deep.app.example.com.

SAN (multi-domain) certificates enumerate explicit DNS names—sometimes dozens—including apex and www pairs, regional hosts, and microservice URLs. One notAfter applies to the entire cert object.

Monitoring must track:

• The certificate file or secret renewal pipeline (one deadline)
• Each public hostname that must present that cert (many SNI checks)
• Exceptions where a host uses a different cert (marketing microsites, third-party SaaS)

Partial coverage incidents appear in SAN certificate partial expiry patterns when only some names on the cert are served correctly.

When a wildcard expires, every covered subdomain fails together—see wildcard SSL certificate expired for blast-radius triage.

Certificate Transparency logs list issued names even when operators forget to update internal spreadsheets. CT is not monitoring by itself, but it helps audit whether last month’s SAN expansion actually includes the microservice you launched.

Load balancers may terminate TLS with a default cert that is not the wildcard your ACME job renewed. SNI mismatches look like random expiry when only some hostnames fail—per-host serial comparison catches that class of bug faster than reading one PEM in git.

Step-by-step

1. Inventory hostnames from DNS and analytics

Export apex, www, product subdomains, and API gateways from DNS zone files or your CDN dashboard—not only the cert’s SAN printout.

2. Read the cert’s SAN and wildcard flag

echo | openssl s_client -connect www.example.com:443 -servername www.example.com 2>/dev/null \
  | openssl x509 -noout -text | grep -A1 "Subject Alternative Name"

SNI must match each hostname you probe.

On the host storing PEM files:

openssl x509 -in /etc/ssl/certs/example-fullchain.pem -noout -text | grep -A1 "Subject Alternative Name"

SNI must match each hostname you probe.

Confirm whether the cert is *.example.com, explicit SAN list, or both.

3. Live probe each critical hostname

for h in www.example.com api.example.com app.example.com; do
  echo "== $h =="
  echo | openssl s_client -connect "${h}:443" -servername "${h}" 2>/dev/null \
    | openssl x509 -noout -dates -serial -subject 2>/dev/null
done

SNI must match each hostname you probe.

Mismatched serial or notAfter between hosts means different certificates are live—your monitoring must not assume one check covers all.

4. Document shared renewal

Record a single renewal ticket for the cert object, but attach per-host s_client output after deploy proving each name received the new chain.

PowerShell loop example

$hosts = @("www.example.com","api.example.com","app.example.com")
foreach ($h in $hosts) {
  Write-Host "== $h =="
  curl.exe -vI --connect-timeout 15 "https://$h/" 2>&1 | Select-String -Pattern "expire|SSL certificate|subject"
}

SNI must match each hostname you probe.

Sort hostnames by business criticality before building loops—authenticate checkout and login endpoints first when you are capacity-constrained during an incident.

Kubernetes operators should read tls.crt in the live ingress secret via kubectl only after confirming the data plane reloaded; better yet, openssl against the public URL the ingress publishes.

kubectl get secret -n ingress TLS_SECRET -o jsonpath='{.data.tls\.crt}' | base64 -d | openssl x509 -noout -dates -subject

SNI must match each hostname you probe.

Compare that output with external s_client—mismatches mean the dataplane has not picked up the secret.

How to read the output

notAfter= is identical for all names sharing the same deployed cert and serial. If loops show different serials, you have multiple cert objects—tag each in inventory.

subject= CN may read *.example.com while SAN lists additional literals. Clients match SAN first; do not rely on CN alone.

When dates match but one host fails trust, suspect incomplete chain on that listener only—a single renewal still requires per-server reload verification.

Wildcard shape does not appear as SAN text the same way on all platforms; read X509v3 Subject Alternative Name carefully for DNS:*.example.com.

Analytics spikes on obscure subdomains should add those hosts to monitors even if they were not on the original SAN order—DNS might CNAME to a shared pool still using the wildcard.

OV wildcard renewals may require human approval while ACME HTTP-01 on apex proceeds automatically—track procurement state separately from notAfter to avoid surprise manual steps.

Third-party SaaS vanity domains (customer.vendor.com) usually are not covered by your corporate wildcard. Do not merge them into wildcard renewal tickets without reading their actual cert presentment.

Common mistakes

One external monitor on https://example.com/ while checkout lives on shop.example.com with a different default cert on the load balancer.

Renewing the wildcard in vault A while Kubernetes ingress in cluster B still mounts last month’s secret.

Assuming a single ACME timer refreshed every subdomain automatically—each terminator must load the new PEM.

Monitoring PEM mtime on disk instead of live TLS; files update before nginx reload completes.

Omitting apex (example.com) when only *.example.com was purchased—browsers hitting bare apex see name errors or old defaults.

Blue/green deploys that mount new wildcard secrets on green only leave blue presenting stale material—monitor both colors or drain blue before closing change records.

When to use automation

Treat cert object expiry as one scheduled event, but configure per-hostname live TLS checks (or redirect-final URL checks) for every customer-facing name. ssldays and similar tools let you add multiple hosts while sharing one renewal calendar mentally.

Alert on serial change after deploy to detect partial rollouts. For large SAN lists, generate monitor targets from Infrastructure-as-Code rather than manual spreadsheets.

Pair TLS monitoring with RDAP domain expiry so wildcard re-issuance is not blocked by registrar issues. Review quarterly whether new microservices need SAN updates versus staying under an existing wildcard.

Define alert deduplication: one expiry event for the shared cert object, but distinct failure alerts per hostname when presentation diverges.

Use tags in monitoring tools (cert:wcard-main, listener:api-gw) so on-call knows whether to rerun certbot once or chase a single misconfigured ingress.

Game-day exercises should include rolling a wildcard renewal in staging with intentional partial reload on one node—per-host monitors must fire before production repeat.

Reference SAN certificate partial expiry when only a subset of SAN hosts fail while siblings succeed—wildcard estates see the same symptom when SNI defaults leak.

HashiCorp Vault and cloud secret managers version PEM blobs—monitoring should alert when the active secret version changes without a matching improvement in live notAfter, catching rollback mistakes.

Multi-cloud failover may present a DR region still bound to last year’s wildcard while primary shows renewed material—include DR hostnames in the same per-host loop, not only production primary URLs.

CTO dashboards showing “one wildcard, ninety days left” oversimplify SAN-heavy estates where individual microservices were carved onto separate certs after acquisitions—split inventory rows when billing teams merge entities.

CI pipelines that deploy fifty microservices from one Helm chart should still external-probe each public Ingress rule generated from values files—templating multiplies DNS rows faster than cert operations notices.

Educate product managers that requesting new.example.com may require either wildcard coverage or a SAN reissue with lead time; monitoring alerts should tag “needs CSR update” separately from “reload pending.”