DNS Tools
CERTIFICATE LIFETIME

SSL Certificate Expiry Checker

Check when your site's certificate expires, how many days remain, and whether other certificates in the chain are close to lapsing.

Run Certificate expiry

The domain (or a subdomain). The check stays within that name and its www counterpart, like the full assessment.

No sign-up required. Public hosts and addresses only; results show what was observed, nothing is simulated.

What this checker measures

The checker connects to the site over HTTPS, reads the certificate chain the server sends and reports the date each certificate is valid until, with the days remaining. The leaf certificate decides what visitors experience, so its date is the headline. Other certificates the server sends, usually intermediates, are listed too, and if one is close to expiry it is reported as an informational note because clients that build their path from the sent chain can fail when an intermediate lapses.

Thresholds match the full domain assessment so the two never disagree: an expired certificate or one with fewer than 7 days left is high risk, fewer than 21 days is an improvement with medium severity, and anything longer passes.

Expiry is not the only certificate problem

A certificate can be inside its validity window and still fail. The tool separates several causes, because they need different fixes.

  • Expired: the date has passed. Renew and install.
  • Not yet valid: the validity start is in the future, often because of a wrong server clock or a certificate installed too early.
  • Hostname mismatch: the names in the certificate do not include the host visited, for instance a certificate for example.com served for www.example.com.
  • Untrusted issuer or self-signed: the chain does not lead to a root in the trust store.
  • Incomplete chain: the server did not send an intermediate.

How to read the output

The validity block shows the host, how the chain was verified, the leaf expiry in UTC and the days left. Below it a table lists each certificate with role, subject, issuer, validity dates and days left. When verification fails, the tool reads the certificate the server presented without trusting it, only to show its dates, so you can see whether expiry is the cause or just one fact among several. Verification failure and expiry are therefore reported separately.

Why certificates lapse

Most lapses are process failures, not technical ones. Typical causes are manual renewals that depend on one person, automated renewal that silently stopped after a DNS or firewall change broke the validation challenge, a certificate renewed but not deployed to every server or load balancer, and a certificate on a secondary hostname nobody tracks. Short certificate lifetimes make automation the norm, so a failed job is noticed sooner but still has to be monitored.

How to renew safely

Prerequisites: access to your certificate authority account or ACME client, the ability to prove control of each name, and a deployment path to every server that terminates TLS. Risk: a bad install can interrupt HTTPS. Rollback: keep the previous certificate and key until the new one is confirmed working.

  1. List every hostname served and every system that terminates TLS, including load balancers and CDNs.
  2. Renew the certificate through your CA or ACME client, ensuring the names include apex and www if both are used.
  3. Install the new leaf with its intermediates on every endpoint, then reload the service.
  4. Re-run this checker for each hostname and confirm the days remaining reset and the chain verifies.
  5. Add monitoring that warns well before the 21 day threshold and test the automation after any DNS or firewall change.

Limits

Only certificates the server sends are examined; roots are not assessed. Revocation through CRL or OCSP is not checked, so a revoked certificate inside its dates would still show its dates. One path on the apex or www host is requested from one network position. Services other than HTTPS, such as mail on its own ports, have their own certificates that this tool does not read.

Frequently asked questions

Why does the tool report a failure instead of just days left?

Expiry is only one reason a certificate is rejected. If verification fails, the tool shows the reason and the dates separately.

What are the warning thresholds?

Under 7 days, or already expired, is high risk. Under 21 days is a medium improvement. Longer than that passes.

Does this check revocation?

No. CRL and OCSP revocation checks are not performed.

My renewal ran but the site still shows the old date. Why?

The new certificate may not be installed on every server or the service was not reloaded. Another endpoint behind a load balancer may still present the old one.

Do mail servers use the same certificate?

Not necessarily. Mail ports have their own certificates; this tool reads the HTTPS one.

Should I worry about intermediate expiry?

Rarely, but a lapsed intermediate sent by your server can break some clients, so it is listed.

Scope of this tool

  • Only the domain's apex and www host are contacted over HTTPS (and port 80 where stated); redirects to any other host are reported, never followed.
  • Spectra identifies itself honestly and does not imitate a browser, so sites that block automated clients may not show their real headers.
  • A single request path (/) is examined from this scanner's network position; other pages, other nodes of a load-balanced site and other regions may differ.

Written by DNS Tools editorial · Last updated 2026-10-09