SSL/TLS Certificate Checker
Point this tool at any hostname and it opens a TLS connection to read the certificate the server actually presents — no login or agent needed. It reports the issuer, subject, every SAN hostname, the expiry date with exact days left, and the TLS version that was negotiated. It also tells you whether the certificate is short-lived/auto-renewing (ACME, like Let's Encrypt) or a long-lived cert someone has to renew by hand, and tunes its expiry alarms accordingly.
Reviewed by the SysGlass team · Updated July 21, 2026
What it checks
- Issuer and subject (common name) of the leaf certificate
- Subject Alternative Names (SAN) — every hostname the certificate covers
- Expiry date (notAfter), start date (notBefore), and the exact number of days left
- Certificate validity lifetime in days (notAfter minus notBefore)
- Whether the cert is auto-renewing/short-lived (ACME issuers like Let's Encrypt, ZeroSSL, Google Trust Services, Buypass Go, or any cert with a ~100-day-or-shorter lifetime) versus manually-managed/long-lived
- The TLS protocol version actually negotiated (TLS 1.0, 1.1, 1.2, or 1.3)
- Whether the certificate is already expired
- Certificate Transparency — counts the Signed Certificate Timestamps (SCTs) the cert carries, embedded or delivered in the handshake, since browsers require publicly-trusted certs to be CT-logged
- OCSP must-staple — whether the certificate demands a stapled OCSP response (RFC 7633) and whether the server actually delivered one
- A custom port (defaults to 443) for TLS services that aren't on the standard HTTPS port
- Inspects rather than trusts — reports what the server presents, including self-signed or expired certificates
- The equivalent openssl s_client command so you can reproduce the check from a shell
How to read the result
- Pass (OK): the certificate is valid and not in any alarm window — the summary shows the days left and the negotiated TLS version.
- Fail — EXPIRED: the certificate's expiry date is already in the past; the site is serving an invalid cert right now.
- Auto-renewing cert, days left critically low → Fail: for short-lived/ACME certs a low day count means renewal is failing (a healthy ACME cert renews itself well before expiry). For a 90-day Let's Encrypt cert this fires at roughly 3 days left.
- Auto-renewing cert, days left getting low → Warn: the cert hasn't renewed yet — check the ACME client/timer. For a 90-day cert this fires around 10 days left.
- Manually-managed cert ~30 days out → Warn: nothing renews it automatically, so plan the renewal now.
- Manually-managed cert in its final week → Fail: it expires in days and is not auto-renewed — act immediately.
- Warn — deprecated TLS: the server negotiated TLS 1.0 or TLS 1.1; require TLS 1.2+ and disable the old versions.
- Thresholds are issuer- and validity-aware on purpose: short-lived certs only alarm when they're critically low (a low number = broken renewal), while long-lived certs alarm earlier to give a human time to act.
Frequently asked questions
How do I check when an SSL certificate expires?
Enter the hostname and the tool connects over TLS and reads the certificate's notAfter date, showing both the expiry date and the exact number of days left. It also shows the start date (notBefore) and the certificate's total validity lifetime in days.
What's the difference between an auto-renewing and a manually-managed certificate, and why does it matter?
Auto-renewing (short-lived) certificates are issued by ACME CAs like Let's Encrypt or have a lifetime of about 100 days or less; software renews them automatically. Manually-managed (long-lived) certificates have to be reissued by a person. It matters because the checker uses different expiry alarms for each: a long-lived cert is flagged about a month out, while a short-lived cert is only flagged when it's critically low — because for an auto-renewing cert, a low day count usually means the renewal is broken, not that you forgot.
Why doesn't the checker warn about my Let's Encrypt certificate at 30 days left?
Because a healthy auto-renewing certificate is expected to renew itself roughly a third of the way before expiry, so seeing 30 days left on a 90-day cert is normal. The tool only warns when a short-lived cert drops critically low (around 10 days for a 90-day cert) and fails it near the end (around 3 days), since by then the ACME renewal is clearly failing and needs attention.
Does it work on expired, self-signed, or untrusted certificates?
Yes. The checker inspects rather than trusts — it reports exactly what the server presents, including expired and self-signed certificates. An expired certificate is reported as a critical failure with its details still shown.
Which TLS versions does it flag as deprecated?
It reports the TLS version actually negotiated (TLS 1.0, 1.1, 1.2, or 1.3) and raises a warning when the connection negotiates TLS 1.0 or TLS 1.1, both of which are deprecated. The recommended fix is to require TLS 1.2 or higher and disable the older versions on the server.
Can I check a certificate on a port other than 443?
Yes. The port defaults to 443 (standard HTTPS), but you can set a custom port to check TLS on other services such as mail submission, IMAPS, or an internal app on a non-standard port.
What does the tool show besides the expiry date?
For each certificate it reports the issuer and subject common name, all Subject Alternative Name (SAN) hostnames the cert covers, the notBefore/notAfter dates, days left, the validity lifetime, whether it's auto-renewing or manually managed, the negotiated TLS version, and the equivalent openssl s_client command to reproduce the check.
Does it check Certificate Transparency and OCSP must-staple?
Yes. It counts the Signed Certificate Timestamps (SCTs) the certificate carries — embedded in the cert or delivered during the TLS handshake — because Chrome and Safari require publicly-trusted certificates to be logged to Certificate Transparency, so a public cert with no SCTs can be rejected (a private/self-signed cert legitimately has none). It also detects the OCSP must-staple flag (RFC 7633): if the certificate demands a stapled OCSP response but the server doesn't deliver one, strict clients may refuse the connection.