SSL Expiry Checker
Check SSL/TLS certificate expiry from a live host, with renewal timing, SAN coverage, issuer, serial number, and fingerprint evidence.{{ 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:
A TLS certificate expiry problem often looks like an outage, even when the web server, application, and DNS record are still running. After the certificate's Not After time passes, browsers, API clients, monitors, and partner integrations may refuse the connection because the encrypted listener can no longer prove its identity inside the allowed time window.
Expiry is only one part of certificate health. A certificate also has to be the certificate actually served by the live host, and its names have to cover the DNS name the client requested. That is why renewal checks are usually done against the public listener, not only against a certificate file in a vault, a hosting dashboard, or a certificate authority account.
- Validity window
- The time span between
Not BeforeandNot After. Expiry decisions come from the end timestamp. - Name coverage
- The certificate identity check that compares the requested hostname with Subject Alternative Name entries and, for diagnosis, the legacy Common Name.
- SNI
- The hostname sent during the TLS handshake so shared servers, load balancers, and gateways can choose the right certificate.
Most renewal surprises come from a gap between issuance and deployment. A replacement certificate can be approved and downloaded while an older serial number remains active on a load balancer, CDN edge, staging listener, or nonstandard port. The visible expiry date then answers a practical operational question: what certificate did a real TLS handshake receive from this exact place?
Public TLS operations are also moving toward shorter certificate lifetimes, so expiry checks are no longer a once-a-year housekeeping chore for many teams. The safest routine pairs the calendar deadline with identity evidence: issuer, serial number, fingerprint, SAN coverage, protocol, and cipher details from the listener that users actually reach.
A clean expiry result should still be treated as a point-in-time observation. Multi-edge hosting, shared IP addresses, DNS changes, and SNI defaults can all change which certificate is presented. A live check gives strong evidence for the path it reached, while monitoring from other regions and chain or revocation checks may still be needed for a complete TLS review.
How to Use This Tool:
Check the same host and listener a real client uses, then adjust the advanced fields only when the default HTTPS path is not the path you need to verify.
- Enter a hostname, URL, or
host:portvalue inHost or URL. Usehost:portfor listeners such asapi.example.com:8443. - Open
Advancedwhen you need a specificPort, anSNI override, a differentRenewal lead time, or a longerTimeoutfor a slow endpoint. - Select the renewal lead window that matches your operating policy. The result will show an
Action bydate and indicate when that lead window is already open. - Run
Check expiry. If the result is an invalid host, DNS failure, timeout, missing certificate, connection failure, or TLS handshake failure, fix that reachability issue before reading the output as a certificate defect. - Read the summary first for days remaining or days overdue, then confirm the badges for name coverage, TLS protocol, and checked port.
- Use
Renewal Brief,Certificate Facts,Name Coverage, andRenewal Actionstogether when a renewal ticket needs proof that the served certificate changed after deployment.
Interpreting Results:
The large day count is rounded up to the next whole day. A result of 1d can mean only a few hours remain, so use Valid to (UTC) and Expires (local) when the deadline is close. A negative day count means the listener is already past the certificate end time.
The renewal status combines the selected lead window with a fixed final-week warning. Final week is urgent even when your lead setting is shorter, while Lead window means the chosen action-by date has arrived. A healthy runway does not prove the certificate is acceptable for the hostname, so check Name coverage before treating the timing result as complete.
- SAN match and Wildcard SAN are the strongest hostname coverage results shown here.
- CN-only coverage and SAN mismatch are warning signs for public TLS use because modern clients rely on Subject Alternative Name coverage.
- Name mismatch usually points to the wrong host, port, or SNI value, or to a certificate that needs the requested name added.
- After renewal, compare the serial number and SHA-256 fingerprint as well as the expiry date. A later expiry date alone does not prove every live listener changed.
Technical Details:
X.509 certificates carry a validity interval with Not Before and Not After timestamps. Expiry checking compares the current time with the end timestamp, but normal TLS trust decisions also depend on certificate chain validation, revocation status, acceptable algorithms, and whether the requested hostname is covered by the certificate identity fields.
Server Name Indication changes which certificate can appear on a shared listener. A server, load balancer, or gateway may serve different certificates on the same IP address and port depending on the SNI name sent during the TLS handshake. Without the right SNI value, a test can measure a default certificate instead of the certificate users receive for the intended hostname.
Formula Core:
The expiry runway is a time difference measured in milliseconds and rounded upward to whole days.
The action-by date subtracts the selected renewal lead window from the same expiry timestamp.
| Symbol | Meaning | Displayed result affected |
|---|---|---|
T_notAfter |
Certificate end time from the certificate presented by the live TLS listener. | Days remaining, Expires, and Action by. |
T_now |
The moment the result is evaluated. | The summary day count, final-week state, and overdue state. |
L |
The selected renewal lead time in days. | The action-by date and lead-window badge. |
Renewal Stage Rules:
| Stage | Rule | Meaning |
|---|---|---|
| Expired | days_left < 0 |
The listener is past the certificate end time. |
| Final week | 0 <= days_left <= 7 |
Renewal and deployment should be treated as immediate work. |
| Lead window | 7 < days_left <= renewal lead time |
The configured action window is open. |
| Healthy runway | days_left > renewal lead time |
The certificate still has buffer under the selected policy. |
Name Coverage Rules:
Hostname coverage is checked against Subject Alternative Name entries before the Common Name. Exact SAN matches pass. A wildcard SAN covers only one left-most DNS label, so *.example.com covers api.example.com but not deep.api.example.com.
| Coverage result | Condition | How to read it |
|---|---|---|
| SAN match | The checked host appears directly in the SAN list. | Strong evidence that the served certificate covers the requested DNS name. |
| Wildcard SAN | The checked host matches one wildcard label in a SAN entry. | Usually acceptable for that single label depth, but not for deeper subdomains. |
| CN-only coverage | No SAN match is present, but the Common Name matches. | Useful diagnostic evidence, not a clean modern public TLS result. |
| Name mismatch | No SAN or Common Name match covers the checked host. | The wrong certificate may be served, or the certificate needs to be reissued with the missing name. |
Public TLS Lifetime Context:
Certificate lifetime is different from days remaining. Lifetime is the full span between Not Before and Not After, while days remaining is measured from the check time to expiry. Publicly trusted TLS certificates are subject to CA/Browser Forum rules, and maximum lifetimes are being reduced over several years. This checker reports the observed lifetime and expiry evidence, but policy compliance also depends on the certificate type, issuance date, and applicable root program rules.
| Period beginning | Maximum public TLS validity | Operational implication |
|---|---|---|
| 15 March 2026 | 200 days | Renewal checks become more frequent for many public certificates. |
| 15 March 2027 | 100 days | Automation and post-deployment verification become harder to skip. |
| 15 March 2029 | 47 days | Expiry monitoring needs to be treated as recurring operational evidence. |
Accuracy Notes:
The result is a live network observation, so DNS, routing, load balancing, SNI behavior, timeout length, and edge selection can change what certificate is seen.
- The host, port, optional SNI name, and timeout are sent to a remote probe so the TLS handshake can be performed outside the browser.
- The check records the presented certificate even if it is expired or otherwise untrusted. That is useful for troubleshooting, but it is not a full trust-chain or revocation decision.
- For multi-region or CDN deployments, repeat the check from other monitoring locations or compare deployment inventories when every edge must be proven.
Worked Examples:
Renewal did not reach the live listener
portal.example.com was renewed in a certificate authority account, but Certificate Facts still shows the old serial number and a Days to expiry value of 12. The useful conclusion is not that issuance failed. It is that the listener being tested is still serving the older certificate.
Shared listener needs SNI
A check against gateway.example.net:8443 returns Name mismatch and a Common Name for another tenant. Repeating the check with SNI override set to api.example.net changes Name Coverage to SAN match, confirming that certificate selection depended on the requested name.
Final week is already urgent
With a 30-day renewal lead window, a result of 6 in Days remaining falls into Final week, not just a normal lead-window reminder. Renewal Actions should be treated as immediate work, and Valid to (UTC) gives the exact deadline for the ticket.
FAQ:
Does this check the certificate file on my server?
No. It checks the certificate presented by the live host and port you enter, which is usually the evidence needed after a load balancer, CDN, proxy, or gateway deployment.
Why does one day left still feel urgent?
The day count rounds upward. Open Certificate Facts and read Valid to (UTC) when the result is inside the final week or shows 1d.
Why would the Common Name not be enough?
Modern hostname validation relies on Subject Alternative Name entries. A Common Name match can help diagnosis, but CN-only coverage should be fixed before relying on the certificate for public TLS traffic.
What should I do after deploying a renewed certificate?
Run the check again and compare Valid to (UTC), Serial number, and SHA-256 fingerprint. Those fields show whether the live listener changed, not just whether a new certificate exists elsewhere.
Can this confirm revocation or full chain trust?
No. It reports expiry, names, and certificate facts from the live handshake. Use certificate-chain and revocation checks when you need a complete TLS trust review.
Glossary:
- Not After
- The certificate timestamp after which clients should no longer treat the certificate as valid.
- SNI
- Server Name Indication, the hostname sent during TLS negotiation so shared listeners can select the right certificate.
- SAN
- Subject Alternative Name, the certificate extension that lists DNS names and other identities covered by the certificate.
- Common Name
- A legacy subject field that can still help diagnosis but should not replace SAN coverage.
- Fingerprint
- A hash of the certificate bytes, useful for proving whether the served certificate changed after renewal.
- Renewal lead time
- The number of days before expiry that should trigger planned renewal work.
References:
- RFC 5280: Internet X.509 Public Key Infrastructure Certificate and CRL Profile, IETF, May 2008.
- RFC 6066: Transport Layer Security Extensions, IETF, January 2011.
- Baseline Requirements for Publicly-Trusted TLS Server Certificates, CA/Browser Forum, version 2.2.7, May 2026.
- Ballot SC081v3: Introduce Schedule of Reducing Validity and Data Reuse Periods, CA/Browser Forum, 11 April 2025.