SSL certificate expired on an API subdomain
The main site is fine, but api.yourdomain.com (or app., or admin.) suddenly throws certificate errors — browsers show warnings and every API client starts hard-failing at once.
- Any stack
- Webflow
- Replit
- DNS & SSL
Root cause, in plain English
Your main site's host renews its certificate automatically, but each subdomain served from somewhere else — an API on a VPS, a load balancer, an old service — carries its own certificate with its own renewal path. Those renewals fail quietly: a DNS change breaks the ACME challenge, a certbot timer dies, a CAA record blocks issuance. Nothing complains until the expiry date, when clients hard-fail simultaneously. A wildcard for *.example.com doesn't cover deeper levels like api.eu.example.com either.
How to fix it
Confirm which certificate actually expired: echo | openssl s_client -connect host:443 -servername host 2>/dev/null | openssl x509 -noout -enddate — run it per hostname, since each can differ.
Renew or reissue on the host that actually serves that subdomain (not your main site's provider). For Let's Encrypt, run the renewal and read its error — an ACME failure message names the broken challenge.
Fix the underlying renewal break: restore the DNS record or HTTP path the ACME challenge needs, re-enable the renewal timer/cron, and check CAA records permit your CA.
Inventory every hostname you serve — including ones only API clients and webhooks use — by listing your DNS zone; forgotten subdomains are where this bites.
Put expiry monitoring on each hostname with alerts at 21/14/7 days, so renewal failures become a calm ticket instead of an outage.
Go deeper: read the full guide · copy the open-source health-check recipe.
How Nightlamp detects this automatically
- SSL expiry
- HTTP status
An ssl monitor checks each hostname's certificate chain and expiry on a schedule and warns weeks before the date — turning a hard outage into a routine fix. An http_status check on the same hosts catches the moment clients begin failing, including mid-chain problems (intermediate certificates, SNI misconfig) that expiry math alone misses.
Catch this before your customers do
Nightlamp runs these checks continuously against your live app and sends a plain-English diagnosis — not a wall of logs — the moment this pattern shows up.
Related patterns
Frequently asked questions
- Why didn't my uptime monitor catch this before users did?
- Many uptime checks either ignore certificate validity or only watch the main domain. The failing host is usually a subdomain that was never added to monitoring. Monitor every hostname you serve, and use a check that validates the certificate, not just the response.
- I have a wildcard certificate — how did a subdomain still expire?
- Either that subdomain is served by different infrastructure with its own certificate, or it's a deeper level (a.b.example.com) that *.example.com doesn't cover — wildcards match exactly one label. Check what the failing host actually presents with openssl.
- Why did automatic renewal stop working?
- Renewal depends on a moving environment: the ACME HTTP challenge needs a reachable path on port 80, the DNS challenge needs an API credential that may have rotated, and the whole thing needs its timer alive. Any infra change since issuance can break the next renewal without breaking the current certificate.
Newsletter
Get new incident patterns as we publish them
One email when new failure patterns, fixes, and monitoring recipes for no-code and AI-built apps land. No fluff, unsubscribe any time.
Double opt-in. One-click unsubscribe. No spam, ever.