{{ summaryHeading }}
{{ summaryFigure }}
{{ summarySecondaryLine }}
{{ stageBadgeText }} {{ leadBadgeText }} {{ coverageAssessment.badgeText }} {{ protocolBadgeText }} {{ portBadgeText }}
SSL expiry inputs
Checking the live certificate…
Enter one host, URL, or host:port, such as example.com or api.example.com:8443.
Use 443 for normal HTTPS, or enter 1-65535 for ports such as 8443.
Leave blank to use the host name; enter a DNS name for shared or staging endpoints.
Pick how many days before Not After should count as renewal work.
Range: 1000-15000 ms; raise it for distant or slow TLS endpoints.
ms
Field Value Copy
{{ row.label }} {{ row.value }}
Field Value Copy
{{ row.label }} {{ row.value }}
Field Value Copy
{{ row.label }} {{ row.value }}
Priority Action Evidence Copy
{{ row.priority }} {{ row.action }} {{ row.evidence }}
No expiry runway values were available.

	                
Customize
Advanced
:

Introduction

TLS certificates have a validity window with a fixed start and end time. Once the end time passes, browsers, API clients, and monitoring systems can start rejecting the service even if nothing else changed on the host. An expiry check helps you spot that deadline early enough to renew, deploy, and confirm the right certificate before users see failures.

This checker connects to a live host, reads the certificate that listener presents, and turns the result into a renewal brief, a certificate facts table, a hostname coverage review, and a JSON export. It accepts a hostname, a full URL, or a host:port target, and it lets you override the port, the SNI hostname, the reminder lead time, and the timeout when the default probe is not enough.

Certificate runway timeline A certificate timeline from issue date to expiry, with the chosen action-by date marked before the final deadline and the overdue period shown after expiry. Valid from Action by Not After Healthy runway Reminder window Expired The checker calculates days left from the certificate expiry time and marks the action-by date using your chosen lead window.
The main summary is about timing first: how much runway remains, when your reminder window opens, and whether the listener is already past its expiry time.

It is most useful when you need to verify the certificate that is actually live on a specific listener. That includes post-renewal checks, shared-IP or load-balancer environments where SNI changes the answer, alternate ports such as 8443, and handoff work where you need serial numbers or fingerprints in a ticket.

This is not a full trust audit. The probe reads the presented certificate and reports timing, names, protocol, cipher, and fingerprints, but it does not decide whether the chain is trusted or whether revocation checks would pass. Because the browser cannot open raw TLS sockets to arbitrary hosts by itself, the entered host, port, optional SNI value, and timeout are sent to the site's helper service so the live handshake can be performed.

Technical Details

X.509 certificates carry two validity timestamps, notBefore and notAfter. RFC 5280 defines the certificate validity period as the interval from notBefore through notAfter, inclusive. This checker reads those timestamps from the live certificate and shows them in local time, along with the raw certificate identity fields that matter during renewal work.

The helper first normalizes the target, resolves one IP address, opens a TLS connection to the selected host and port, and uses the entered SNI override when provided. If you leave SNI blank and the target is a hostname, the hostname is used for the handshake. If the target is an IPv4 literal, no SNI is sent unless you supply one explicitly. That detail matters on shared listeners where the default certificate is different from the hostname-specific certificate.

The response includes the checked host, resolved IP, port, negotiated TLS protocol, cipher, subject, common name, issuer, SAN list, serial number, validity timestamps, and SHA-256 and SHA-512 fingerprints. The helper does not reject expired or self-signed certificates during collection, which is why this checker can still inspect a broken deployment well enough to help with renewal triage.

Core calculations used here
days_left = ceil((valid_to_ts - now) / 86400000)
action_by = valid_to_ts - (reminder_days * 86400000)

The first value drives the large summary figure. Because it uses ceiling arithmetic, a certificate with only a few hours left can still show 1 day remaining, while a certificate that has crossed the deadline shows 0 or a negative number depending on the exact second of the check. The second value powers the reminder badge and the renewal brief, so changing the lead time changes when the checker starts treating the certificate as active renewal work.

Renewal stage logic

Renewal stage logic used by the SSL expiry checker
Stage Rule used here How to read it
Expired days_left < 0 The listener is already past the certificate end time. Replace it and verify the new certificate is actually being served on the same host and port.
Final week 0 <= days_left <= 7 The checker treats the last seven days as urgent regardless of the selected reminder window.
Reminder window open 8 <= days_left <= reminder_days, when the reminder setting is above 7 days The certificate is not in the last week yet, but the chosen lead window says renewal work should already be in flight. If the reminder lead is set to 7 days, this stage collapses into the final-week rule.
Healthy runway days_left > reminder_days The certificate still has buffer before the current reminder policy kicks in.

Hostname coverage rules

The checker also compares the requested host against the certificate names. SAN entries are checked first. Exact matches pass. Wildcards are accepted only when they cover exactly one left-most label, so *.example.com matches api.example.com but not deep.api.example.com. If the SAN list exists and only the common name matches, the result is intentionally downgraded because modern TLS identity checks rely on SAN coverage.

Hostname coverage outcomes produced by the checker
Coverage outcome What triggered it Operational meaning
SAN match or Wildcard SAN The requested host matches a SAN entry directly or through a one-label wildcard. The presented certificate names cover the checked host as expected.
CN only No SAN list is present and the common name matches. The host matches only through legacy common-name behavior. Reissuing with explicit SAN coverage is safer.
SAN mismatch A SAN list exists, but only the common name matches the host. The certificate may look plausible to a human while still failing modern hostname validation rules.
Name mismatch Neither SAN nor common name covers the checked host. You are looking at the wrong certificate for that host, port, or SNI target, or the certificate needs reissuance.

Current public Web PKI rules make these checks more time-sensitive than they used to be. The CA/Browser Forum's Baseline Requirements version 2.2.6, dated March 31, 2026, says the maximum validity period for publicly trusted subscriber certificates became 200 days on March 15, 2026. The math in this checker is the same for every certificate, but many public-facing sites now renew more often than older environments did.

Everyday Use & Decision Guide

Start with the exact listener you care about. If your environment uses the normal HTTPS port and one certificate per hostname, entering the hostname is enough. If the certificate lives on another listener, use a host:port target or set the port manually. If the listener sits behind a shared IP, CDN edge, reverse proxy, or staging gateway, fill in the SNI override so the handshake asks for the correct hostname instead of whatever default certificate that IP would return.

The reminder lead time is not cosmetic. It changes the action-by date and the warning badge. Shorter values are useful for low-friction automated renewals. Longer values fit environments with approval chains, change windows, hardware imports, or manual certificate packaging. The timeout is mainly for slow or distant endpoints. Raising it will not fix a bad certificate, but it can help distinguish a slow handshake from a dead listener.

The normal reading order is Renewal Brief first, then Certificate Facts, then Name Coverage. The first tab tells you whether the issue is timing. The second tells you exactly which certificate was served. The third tells you whether that certificate belongs on the host you checked. Use JSON only when you need a raw handoff record or want to compare outputs between runs.

Which SSL expiry checker tab to read first
If you need to know Open this first Why
How urgent the renewal is Renewal Brief It summarizes the current stage, the action-by date, the validity window, and the checklist the checker builds from the result.
Which certificate is actually live Certificate Facts It lists the host, IP, issuer, serial number, validity timestamps, protocol, cipher, and fingerprints from the live handshake.
Whether the host is covered by the certificate names Name Coverage It shows the checked target, the matching name if one exists, and whether the answer came from SAN coverage, CN-only fallback, or a mismatch.
What to send to a ticket, report, or another team JSON You can copy or download the structured result instead of retyping certificate details by hand.

Step-by-Step Guide

  1. Enter the target as a hostname, a full URL, or a host:port pair such as api.example.com:8443.
  2. Open Advanced only when you need to change the port, force a specific SNI hostname, adjust the reminder lead time, or give the handshake more time.
  3. Run the check and wait for the live certificate probe to finish.
  4. Read the summary figure and badges first. They tell you how many days remain, whether the lead window is already open, whether the host is covered by the certificate names, which TLS protocol was negotiated, and which port answered.
  5. Open Renewal Brief and read the checklist before making assumptions about the next step.
  6. Open Certificate Facts to confirm issuer, serial number, expiry timestamps, protocol, cipher, and fingerprints.
  7. Open Name Coverage if the listener might be serving the wrong certificate or if you are checking a host that shares infrastructure with other names.
  8. Copy or download CSV, DOCX, or JSON only after the result matches the listener you intended to inspect.

Interpreting Results

The large day count is the fastest signal, but it is not the whole story. A value above your reminder threshold means the certificate still has runway under your current policy. A value inside the reminder window means renewal planning should already be active. A value in the final week is urgent even if your chosen lead window was shorter. A negative value means the endpoint is already past expiry.

Read 0 days and 1 day carefully. Because the calculation uses ceiling arithmetic, 1 day can mean there are only a few hours left before the exact expiry time. A 0 day reading means you are right at the edge and should treat the certificate as immediate work, even if the listener has not crossed into a negative result yet.

The protocol badge shows the protocol negotiated for this specific probe, not every protocol the server might offer under other conditions. The resolved IP is one address returned to the helper environment for that run, not a complete inventory of every edge behind a hostname. In a load-balanced environment, reruns can land on a different node and show a different certificate. That is why the serial number and fingerprints matter after a renewal.

The name coverage result often explains why a site appears healthy in one place and wrong in another. A SAN or wildcard SAN match means the requested host is explicitly covered. CN-only and SAN-mismatch results are warnings that the certificate naming is behind modern practice. A full name mismatch usually means the wrong certificate answered because the host, port, or SNI target was not the one the listener expected.

Worked Examples

Confirming that a renewal really reached the live listener

You renew portal.example.com and expect the new certificate to expire next year. The checker still shows the old expiry date, the same serial number, and the same SHA-256 fingerprint as yesterday. That means the new certificate was probably issued but not deployed on the listener you just tested, or the request reached a different edge that still has the old certificate.

Finding the right certificate on a shared IP and custom port

An internal gateway terminates TLS on 8443 for several hostnames. A plain probe without SNI returns a certificate for the default tenant, so the coverage tab says Name mismatch. You rerun the check against gateway.example.net:8443 with an SNI override of api.example.net, and the result changes to a SAN match with the expected issuer and expiry date. The port and SNI settings were the missing context.

Spotting a legacy naming problem before rollout

A certificate appears to match because the common name says shop.example.com, but the SAN list contains only www.example.com. The checker marks that as SAN mismatch instead of a clean pass. That is the right warning to act on before deployment, because modern clients are expected to prefer SAN coverage over common-name fallback.

FAQ:

Does this read the live certificate or a cached browser copy?

It reads the certificate returned by a new server-side TLS handshake. That makes it useful for confirming what the listener is serving right now, not what your browser cached earlier.

Why can the result differ from what I see in my browser?

Browsers can connect to a different IP, send a different SNI hostname, or use a different port than the one you checked here. Load balancers and multi-tenant edges can also serve different certificates to different paths through the same hostname.

Does this verify trust chains, OCSP, or revocation?

No. This checker focuses on the presented certificate, its timing, its names, and a few transport facts from the handshake. Use a dedicated trust or certificate-chain checker when you need full validation.

Can I check an IP address directly?

IPv4 targets can be checked, but they usually need extra care. Most certificates are issued for DNS names, not bare IPs, and SNI is not sent automatically for an IPv4 target unless you provide an override. IPv6 literals are not supported by this checker at the moment.

Why does the checker say 1 day left when the certificate expires later today?

The day count rounds up. Anything above zero but below one full day still appears as 1 day, which is why the exact expiry timestamp in the facts table matters when the deadline is close.

Is anything kept after I run a check?

The page sends the target details to the helper service so the live handshake can run, but the page itself does not save your checks as a history list. Copy, CSV, DOCX, and JSON exports happen only when you choose them.

Glossary:

Not After
The certificate end time. Once that timestamp passes, the certificate is expired.
SAN
Subject Alternative Name. This is the extension that lists the DNS names or IP addresses the certificate is meant to cover.
Common Name
An older certificate name field that some legacy checks still look at when SAN coverage is missing.
SNI
Server Name Indication, the TLS extension that tells a shared endpoint which hostname the client wants before the certificate is chosen.
Fingerprint
A hash of the certificate bytes, useful for proving that the live listener changed to a different certificate after renewal.