SSL Certificate Checker

Enter a hostname → expiry date, days left, and issuer. Spot check only — set up continuous monitoring for production.

Hostname

Certificate

Days until expiry
Expires:
Issuer:
Valid:

SSL expiry and reliability

An expired TLS certificate takes your site offline for browsers even when your application process is healthy. That outage is embarrassing, preventable, and often excluded from “real” incident retros — yet customers experience it as total failure.

This checker connects to port 443 from our server and reads the certificate the host presents. It is a point-in-time smoke test, not continuous SSL monitoring. No signup required.

What we show and how to read it

  • Expiry date — when the cert becomes invalid (shown in UTC).
  • Days left — countdown for renewal planning; not a guarantee auto-renew succeeded.
  • Issuer — CA name (Let's Encrypt, DigiCert, Amazon, etc.).
  • Valid flag — whether the cert is currently within notBefore/notAfter window at check time.

Worked example 1 — manual cert renewal window

Hostname: shop.example.com · Days left: 22 · Issuer: DigiCert

Action: open renewal ticket now — allow time for validation, install, and deploy to all load balancers.

Worked example 2 — false confidence from ACME

Days left: 45 but last auto-renew job failed silently (DNS challenge broke).

Lesson: monitor renewal success, not only expiry date. Alert on cert age > 60 days for 90-day LE certs.

Worked example 3 — CDN vs origin mismatch

Edge cert valid 90 days; origin cert expired yesterday — customers fine until you bypass CDN.

Check both customer-facing hostname and origin hostname used during incidents.

Honest limitations

  • Does not validate full chain trust exactly as every browser OS store.
  • Standard port 443 only — custom TLS ports not supported here.
  • No alerting — you must run the check or use real monitoring.
  • Single location — cannot detect regional TLS termination issues.

When NOT to use this tool

  • Enterprise PKI with internal CAs — use org tooling.
  • Certificate transparency audit for compliance — dedicated CT log tools.
  • mTLS service meshes — client cert requirements break simple checks.

Certificate types quick reference

  • DV (Domain Validated): fast issuance, suitable for most public sites.
  • OV/EV: org verification; EV shows company name in older browser UIs.
  • Wildcard (*.example.com): one cert for subdomains — renewal blast radius larger.
  • Short-lived (90-day LE): automation mandatory; monitor renewals not just expiry.

Incident runbook snippet

If SSL checker shows <7 days: page platform on-call, verify ACME logs, prepare manual cert if needed.

If expired: execute cert deploy runbook, confirm chain on load balancer, re-check from external tool.

Deep dive: certificate inventory at scale

Small teams check certs ad hoc with tools like this. Growing teams maintain spreadsheets or CMDB rows: hostname, issuer, expiry, automation owner, dependency (CDN vs origin). Run this checker when onboarding a acquired company’s domains into your inventory.

Wildcard cert renewal failure takes down every subdomain at once — higher blast radius than single-host certs. Flag wildcards in change management with stricter review.

After SSL incidents, add error budget or downtime cost minutes to the post-mortem — expired certs are preventable full outages, not “minor ops issues.”

TLS lifecycle checklist (manual teams)

  1. Day 90 before expiry: inventory confirms automation owner
  2. Day 30: manual renew trigger if non-ACME
  3. Day 7: verify staging cert matches production SAN list
  4. Day 0 deploy: roll load balancers sequentially; re-check each node
  5. Day +1: external smoke check (this tool) from outside VPN

Mixed SAN certificates covering both example.com and *.example.com simplify ops but increase renewal blast radius — document every hostname covered before change windows.

Days-until-expiry alert thresholds (methodology)

Manual certificate teams often use tiered alerts: 30 days = open renewal ticket, 14 days = escalate to on-call roster, 7 days = executive visibility, 0 days = incident. For 90-day Let's Encrypt certs, also alert when cert age exceeds 60 days without successful renewal — expiry date looks fine while automation is broken. Formula: days_left = floor((notAfter − now) / 86400000) in UTC. This checker computes that at click time only; production needs scheduled checks at daily cadence minimum.

Common mistakes in TLS expiry management

  • Monitoring only the CDN edge hostname. Origin cert expires; edge looks fine until bypass.
  • Assuming ACME success from expiry date alone. Failed renewals last week still show 30 days left on old cert.
  • Wildcard renewal without staging test. One bad SAN list takes down 40 subdomains simultaneously.
  • Forgetting load balancer cert bundles. Node 1 updated, node 2 still serves expired chain — customers see intermittent errors.
  • Ignoring CAA records after DNS migration. New CA cannot issue; renewal fails at day 7 panic.
  • Classifying expiry as “minor ops.” Full customer outage with zero application errors — still SEV1 impact.

Worked example — renewal timeline with numbers

Hostname: api.example.com · 90-day LE cert · Checked today: 18 days left.

Day 0 (today): This checker shows 18 days — open ticket, verify ACME cron last success was 32 days ago (missed cycle).

Day 1: Fix DNS-01 TXT; staging cert issued with matching SAN.

Day 2: Rolling deploy to 6 load balancers; re-check each — all show 89 days left.

Prevented outage window: customers would have hit expiry in 18 days ≈ potential 100% traffic loss for duration of fix (often 1–4 hours if unplanned).

When NOT to use this checker alone

  • Inventory of 200+ hostnames — use automated SSL monitoring with alerting.
  • Internal PKI with private roots — browser trust differs from our probe.
  • Certificate pinning in mobile apps — expiry may break app before web checker reflects issue.
  • Compliance audits requiring CT log correlation — need dedicated tooling.

Honest limits

One TCP connection to port 443 from one server location at one instant. No OCSP stapling analysis, no weak cipher enumeration, no mTLS client cert paths. Does not prove all load balancer nodes share the same cert. Run after every cert deploy; schedule real monitoring for everything else.

ACME renewal failure patterns

HTTP-01 challenges fail when port 80 is blocked or redirects incorrectly. DNS-01 fails when TXT record is missing, duplicated, or cached at wrong resolver. After fixing automation, wait for propagation then re-check with DNS Analysis on _acme-challenge hostnames before assuming renewal will succeed on next cron run.

Staging environment certs often expire unnoticed because traffic is low — include staging hostnames in the same monthly inventory as production. A staging cert expiry rarely hits customers but blocks release testing the week you need it most.

Post-incident SSL review checklist

  1. Confirm which hostname customers hit vs origin bypass path
  2. Verify all load balancer nodes show same expiry after renew
  3. Check automation logs for last 3 successful ACME runs
  4. Add days-left alert at 30/14/7 if not already paging
  5. Log preventable cert outage minutes in post-mortem with downtime cost

Quantifying cert outage impact

Expired cert on primary domain at peak hour: if traffic is 12,000 sessions/hour and 100% fail TLS handshake, duration 45 minutes → 9,000 lost sessions. At 2.8% conversion and $62 AOV, rough order loss ≈ 9,000 × 0.028 × $62 ≈ $15,624 (illustrative — use your funnel math in Downtime Cost). Preventable cert incidents deserve SEV1 severity and post-mortem, not quiet cert renewal tickets.

Certificate transparency and inventory hygiene

Quarterly, export hostname list from load balancers, CDN panels, and kubernetes secrets — run this checker on each public name. Orphan certs on deprecated subdomains still appear in CT logs and confuse auditors. After acquisitions, acquired domains often carry unknown expiries — inventory before integration cutover.

Load balancer rolling deploy tip

During cert renewal, roll nodes one at a time and re-check from this tool through customer hostname — mixed expiry across pool causes intermittent TLS errors that look like flaky network bugs. Budget 10–15 minutes per node for validation in runbook, not “deploy and hope.”

Related tools

Availability Checker · DNS Analysis (CAA, validation records) · Downtime Cost · Free Tools.

Frequently Asked Questions

How many days before SSL expiry should I renew?

Manual certs: renew at 30 days or sooner. ACME setups usually auto-renew earlier — verify automation still runs.

Is this continuous SSL monitoring?

No. One port 443 check when you click. Production needs scheduled monitoring with alerts.

Why does SSL expiry cause outages?

Browsers refuse expired certificates even if your app is healthy — users see security warnings.

Does this validate the full certificate chain?

It reads the cert on port 443. Full trust chain validation may differ — use openssl for deep audits.

Can CDN edge certificates differ from origin?

Yes. Check the hostname customers actually hit versus origin during bypass scenarios.

What if the checker cannot connect?

Host may block our IP, TLS on non-standard port, or nothing on 443. Verify firewall and SNI.

Should I include SSL incidents in downtime cost?

Yes — expired cert outages are full customer-facing failures. Log duration and run Downtime Cost Calculator.

When should I not rely on this checker alone?

When you manage many hostnames or wildcard renewals — use automated SSL monitoring with alerting.