SSL certificate expired: what the browser warning means (and how to fix it)
When an SSL certificate expires, the lock on the browser turns into a scary interstitial. CrowWake’s check is a live TLS handshake on the hostname you typed—days remaining, not a full PKI audit. Fix the live cert first; then watch so the next near-miss crows early.
What “SSL certificate expired” means
Operators searching for SSL certificate expired usually hit a browser warning (NET::ERR_CERT_DATE_INVALID and cousins): the public certificate’s not-after date is in the past. Visitors see “Your connection is not private,” payment and login flows stall, and trust dies even when SPF/DKIM/DMARC still look green. CrowWake answers with a TLS connect to port 443, reads the peer certificate end date, and reports days remaining—or expired. It sits beside CAA and website HTTPS so “the lock failed” shows up in the same flock as “who may renew” and “is the homepage up.”
What CrowWake checks
We open TLS to your domain on port 443, capture the peer certificate, and compute days remaining. Expired → fail. Under 21 days → warn. Healthy runway → ok with days left. The free SSL expiry checker uses the same live handshake with no login—the same signal the hourly probe uses. We do not crawl every SAN on every CDN edge; this is the hostname you typed. For the earlier “watch runway before day zero” job, see the dedicated SSL certificate monitoring guide.
Expired vs SSL certificate monitoring
This guide is the already-red case: browsers are warning, renew/reinstall now. SSL certificate monitoring is the earlier rooster—catch the under-21-day window while auto-renew still has time to fail loudly to you, not to your clients. Both use the same free SSL checker; CrowWake just repeats the pulse every hour so the next expiry is not a surprise ticket.
What “good enough” looks like
Valid cert covering the hostname users type (apex and www if both serve). ACME or host auto-renew proven at least once. CAA allow-list still matches the CA you renew with. CrowWake’s under-21-day warn is intentional runway—not a suggestion to wait until the interstitial appears.
Quick triage when the certificate is already expired
1) Re-run the free SSL expiry checker and confirm days left shows expired (not a DNS or origin-down false alarm). 2) Renew or re-issue at the host/CDN/ACME panel for the public hostname customers type—not only an origin behind the proxy. 3) Confirm the new cert is served on 443 (re-run the free SSL checker). 4) Confirm CAA still allows that CA (free CAA checker)—a missing allow-list will not un-expire today’s cert, but it can block the next issuance. 5) Confirm HTTPS still answers (website HTTPS / uptime checker)—a dead cert and a down origin feel similar to users. 6) Add the domain so CrowWake crows on the next under-21-day window instead of waiting for another client screenshot.
CAA and SSL belong together
Expiry answers “is the live cert still valid?” CAA answers “who is allowed to mint the next one?” After a zone rebuild, run the free CAA checker as well as SSL—missing CAA will not expire the current cert, but it can block or widen future issuance. Pair with SSL certificate monitoring so runway and issuance permission stay inventoriable together.
If CrowWake crows
Renew and reinstall (or repair Let’s Encrypt / host automation). Verify the live hostname—not only a CDN origin—matches what customers use. After renewing, re-run the free SSL checker, then keep watching. CrowWake monitors days-to-expiry—it does not renew the cert, open a ticket with your CA, or rewrite your ACME cron for you.
Watch this on CrowWake
Add the domain, leave the boxes checked, and the flock will crow when this drifts.
Or try the free SSL certificate expired checker with no login.
Deep dive: SSL certificate monitoring — watch days-to-expiry before browsers scream, with the same free SSL checker.
Also check CAA records so the next cert can still be issued by the CAs you intend. Pair with uptime monitoring when a scary lock and a down origin feel the same to users.