SSL Expiry Checker
Check certificate expiry online for a live host, confirm SAN coverage, and export renewal facts so you can replace the right TLS certificate before outages.{{ summaryHeading }}
| 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 }} |
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.
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.
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
| 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.
| 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.
| 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
- Enter the target as a hostname, a full URL, or a
host:portpair such asapi.example.com:8443. - Open
Advancedonly when you need to change the port, force a specific SNI hostname, adjust the reminder lead time, or give the handshake more time. - Run the check and wait for the live certificate probe to finish.
- 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.
- Open
Renewal Briefand read the checklist before making assumptions about the next step. - Open
Certificate Factsto confirm issuer, serial number, expiry timestamps, protocol, cipher, and fingerprints. - Open
Name Coverageif the listener might be serving the wrong certificate or if you are checking a host that shares infrastructure with other names. - 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.
References:
- RFC 5280: Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile, IETF, May 2008.
- RFC 6125: Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS), IETF, March 2011.
- RFC 6066: Transport Layer Security (TLS) Extensions: Extension Definitions, IETF, January 2011.
- Baseline Requirements for the Issuance and Management of Publicly-Trusted TLS Server Certificates, CA/Browser Forum.