“Your connection is not private”? A cert expired on a host you forgot you had.
One day every visitor hits a full-page browser warning, or your webhooks from Slack, Stripe, and Twilio go quiet with a handshake error nobody is watching. It is almost always an expired certificate — and usually on the subdomain your one “wildcard” check never actually covered. Here is the fast triage list, and the monitoring rule that keeps it from happening again.
One wildcard check is a false sense of safety.
A wildcard cert covers your apex and its direct subdomains — but the API host, the webhook receiver, or the marketing subdomain on a different edge often isn’t on the same certificate at all. Auto-renewal usually works, until an ACME challenge quietly fails or the renewed cert drops a SAN. The fix is boring and reliable: watch every hostname that terminates TLS, on its own check, well before the deadline.
Five ways a certificate quietly expires
Auto-renewal silently stopped
Symptom: The cert was renewing for months, then the clock simply ran out with no warning.
Fix: Check the ACME client's renewal logs and confirm the account email isn't expired or bouncing; renewals fail quietly when the registered contact goes stale.
The cert was issued for the wrong SAN list
Symptom: Your apex domain is fine, but an API or webhook subdomain throws a cert error.
Fix: Inspect the certificate's subjectAltName and confirm it covers the exact failing host; reissue with the missing SAN included.
The CDN edge is serving a stale certificate
Symptom: The origin has a fresh cert, but browsers still see the expired one.
Fix: Force-renew, then purge the CDN/edge cache so the new certificate actually reaches visitors.
A DNS change broke ACME http-01 validation
Symptom: Renewal started failing right after a DNS or hosting change.
Fix: Confirm /.well-known/acme-challenge/ is reachable on the host (no redirect, no auth wall), or switch that host to DNS-01 validation.
You're only watching one hostname
Symptom: The site is fine; an API client or webhook sender fails a TLS handshake out of nowhere.
Fix: Add one SSL monitor per hostname that terminates TLS — apex, www, api, webhooks, app — and don't trust a single wildcard check to cover them.
Paste this into your incident notes
SSL / certificate expiry triage
[ ] Read the live cert dates + subject + SANs:
openssl s_client -servername HOST -connect HOST:443 </dev/null \
| openssl x509 -noout -dates -subject -ext subjectAltName
[ ] Confirm the SAN list covers the exact failing host.
[ ] Check the issuer and the ACME/auto-renewal logs for a failed renewal.
[ ] If ACME http-01: confirm /.well-known/acme-challenge/ is reachable.
[ ] Confirm the registered account email isn't expired or bouncing.
[ ] Force renewal, then clear the CDN / edge cache.
[ ] Re-test the handshake from the failing client (browser + API).
[ ] Add a per-hostname SSL check at a 21-day threshold so it pages early.One SSL check per hostname, with 21 days of runway
Nightlamp runs an ssl monitor on every hostname that terminates TLS — not one wildcard check it hopes covers everything. Each check reads the live certificate, confirms the SAN list still includes that host, and pages you by default 21 days before expiry. That is enough runway to fix a failing ACME renewal or a missing SAN calmly, instead of at 3 a.m. behind a browser warning.
Want every cert watched, including the one you forgot?
Start a trial, list your hostnames — apex, www, api, webhooks, app — and Nightlamp checks each certificate daily, confirms its SAN coverage, and pages you weeks before expiry with the exact host and renewal step.
Start 14-day trial · no card