Skip to main content
HostTracker
HostTracker
website monitoring service
Status pages Instant check Price
Login Register

Certificate health check

Enter a website address to see the certificate its server presents, whether the server sends the full chain, whether the certificate was revoked, what Certificate Transparency logs hold for the name, and whether its renewals look ready for 47-day certificates.

What this check reads

One TLS handshake with your server: the certificate, the chain it sends, the negotiated protocol and cipher. No web page is requested.

Find out more

What it cannot tell you

This is what one client negotiated, once, from one place. It is not a scan of everything your server accepts.

Find out more

A check shows today, monitoring shows the change

A certificate can look fine today and lapse next month. A monitor with the certificate check attached reminds you 30, 7 and 1 day before it expires.

Find out more

Keep watching it

Expiry reminders, certificate changes and the limits of monitoring are covered on these pages.

Related checkers

HostTracker is not affiliated with crt.sh, the CA/Browser Forum or any certificate authority named on this page.

A check reads the certificate you have today See SSL certificate monitoring

Key takeaways

  • The certificate health check runs one TLS handshake from one place and requests no page, so it reads what the server itself sends.
  • It reports a missing intermediate certificate by checking the chain against only the certificates the server sent, which a browser hides by fetching the gap itself.
  • Revocation reads as not revoked, revoked or could not check; naming no OCSP responder is not a fault, since Let's Encrypt ended OCSP in 2025 and uses CRLs.
  • It counts the SCTs embedded in the certificate and reads crt.sh once for the number of certificates in the last 12 months and the median gap between renewals.
  • Whether renewal looks ready for 47-day certificates is a labelled estimate; ballot SC-081 caps validity at 200 days from 15 March 2026, 100 from 15 March 2027 and 47 from 15 March 2029.

Frequently asked questions.

The CA/Browser Forum's ballot SC-081 shortens the longest a public TLS certificate may last, in steps written into the Baseline Requirements: 200 days from 15 March 2026, 100 days from 15 March 2027 and 47 days from 15 March 2029. A renewal done by hand once a year cannot keep up. This tool reads validity length, renewal rhythm and the issuer, then says "looks automated", "looks manual" or "cannot tell". It is a heuristic from outside, never a guarantee.
Certificate Transparency logs are public, append-only records of issued certificates (RFC 6962). The check counts the signed timestamps embedded in your certificate, which show it was logged, then reads the name's history once from crt.sh: certificates in the last 12 months and the median gap between renewals. If crt.sh is slow, the report says history unavailable and the rest stands. That is one read on request. HostTracker monitoring does not watch CT logs, so it will not tell you when someone else gets a certificate for your domain.
Both say whether a certificate authority has revoked a certificate. With OCSP, a client asks a responder about one certificate. With a CRL, it downloads a signed list. Each certificate names its own addresses, and the report shows them. Naming no OCSP responder is not a fault: Let's Encrypt turned its OCSP service off in August 2025 and publishes CRLs. "Could not check" means the service did not answer in time or the certificate names none, which says nothing about your site. A CRL is republished periodically, so a very recent revocation may not be on it yet.
A server should send its certificate plus the intermediates that link it to a trusted root. When one is left out, many browsers still get there, by fetching it from the address in the certificate or by using a copy they already hold. curl and many API clients and scripts do not, so the same site fails for them with a certificate error. The fix is on the server: configure the full chain, for example certbot's fullchain.pem rather than cert.pem, reload the server, then run this check again a few minutes later.
No. It offers TLS 1.2 and 1.3 only and reports what one client negotiated with your server, once, flagging a weak cipher, key or signature. A server that also accepts TLS 1.0 looks the same here as one that does not, so an old version can still be switched on, and a server that accepts nothing newer shows up as a failed handshake. For the full list of what a server accepts, run a dedicated scanner such as testssl.sh or nmap --script ssl-enum-ciphers against it.
This page makes one handshake from one place and goes deep: chain as sent, revocation, Certificate Transparency and renewal habits. The SSL check connects from many locations, so it shows whether different places receive different certificates. The certificate decoder reads a certificate you paste and contacts nothing. Monitoring repeats a check on a schedule and sends reminders 30, 7 and 1 day before expiry, which no one-off check can do.
The check opens one connection (one more only if the first is cut off), completes a TLS handshake of the kind any browser performs, and closes it without requesting a page. Your server may log the connection, but it carries no payload and no login attempt. Private, local and internal addresses are refused. A result is kept for about 5 minutes, so repeat checks do not reach your server again. Certificate history is read from crt.sh and revocation from the authority that issued the certificate, not from your server.

Part of HostTracker's website monitoring software.