SSL Expiry Checker

Host or URL:

Enter one host, URL, or host:port, such as example.com or api.example.com:8443.

Port:

Use 443 for normal HTTPS, or enter 1-65535 for ports such as 8443.

SNI override:

Leave blank to use the host name; enter a DNS name for shared or staging endpoints.

Renewal lead time:

Pick how many days before Not After should count as renewal work.

Timeout:

Range: 1000-15000 ms; raise it for distant or slow TLS endpoints.

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.

Embed:

Customize

Include current inputs

Size

Advanced

Width

Height

Aspect ratio

Max height

Collapsible embed

Allow fullscreen

Referrer policy

Sandbox tokens

A certificate can expire while every visible part of a site still looks healthy. DNS can resolve, the web server can answer, and the load balancer can keep accepting connections, but browsers and API clients may stop before any application code runs because the TLS certificate is outside its allowed validity window.

Expiry checks are most useful when they inspect the certificate a real connection receives. Certificate inventories, hosting dashboards, and certificate authority accounts show what was issued or stored. A live TLS handshake shows what a client gets from a specific host, port, and requested name. That distinction matters after renewals, CDN changes, load balancer rotations, staging cutovers, and multi-tenant gateway work.

The date is not the only certificate fact worth checking. A renewed certificate still has to cover the hostname the client requested, and shared servers often choose a certificate based on Server Name Indication, or SNI. A missing SAN entry, a default certificate on the wrong port, or a stale edge node can create the same user-visible failure as a forgotten renewal.

Validity window: The span from Not Before to Not After. Expiry decisions come from the end timestamp.
SAN coverage: The Subject Alternative Name entries that modern clients use to decide whether a certificate covers the requested DNS name.
SNI: The hostname sent during the TLS handshake so a shared listener can choose the right certificate.

Renewal work should start before the client-breaking expiry instant, and deployment should be proven on the live listener.

Shorter public certificate lifetimes make this operational gap harder to ignore. Many public TLS certificates that once renewed annually now need more frequent issuance, deployment, reload, and verification. Automation helps, but the last mile still needs evidence from the served certificate, not just a successful issuance event.

A clean expiry result remains a point-in-time observation. DNS answers, regional edges, SNI defaults, IPv4 versus IPv6 paths, and load balancer pools can all change which certificate appears. Treat the live result as strong evidence for the path checked, then repeat from other monitoring locations when every edge must be proven.

How to Use This Tool:

Check the same listener that real clients use, 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:port value in Host or URL. Use a value such as api.example.com:8443 when the certificate is served on a nonstandard listener.
Open Advanced when you need a specific Port, an SNI override, a different Renewal lead time, or a longer Timeout.
Leave SNI override blank for normal hostname checks. Set it when a gateway or staging listener must receive a different requested name than the network host.
Choose the Renewal lead time that matches your ticketing or monitoring policy. The result uses that setting to show an action-by date and a lead-window badge.
Run the check and wait for the summary to leave the checking state. If the page reports an invalid host, DNS failure, timeout, missing certificate, connection failure, or TLS handshake failure, fix reachability before treating the result as an expiry finding.
The Timeout range is 1000 to 15000 ms. Raise it for distant or slow TLS endpoints, but keep repeated monitoring strict enough to catch real delays.
Read the summary day count, Valid to (UTC), Expires (local), Name coverage, and the checked port together. Timing is not complete if the host is not covered by SAN or wildcard SAN.
Use Renewal Brief, Certificate Facts, Name Coverage, and Renewal Actions together when a renewal ticket needs evidence that the live certificate changed after deployment.

Interpreting Results:

The day count is rounded upward to the next whole day. A result of 1d can mean only a few hours remain, so use Valid to (UTC) when the deadline is close. A negative count means the listener is already past the certificate end time.

The renewal stage combines the selected lead window with a fixed final-week rule. Final week is urgent even when your lead setting is shorter. Lead window means the configured action-by date has arrived. Healthy means the selected policy still has runway, not that the whole TLS configuration is trusted.

SAN match and Wildcard SAN are the clean hostname coverage outcomes for normal public TLS use.
CN-only coverage and SAN mismatch should be treated as remediation findings because modern service identity checking relies on Subject Alternative Name entries.
Name mismatch usually means the wrong host, port, SNI value, or certificate was checked.
After renewal, compare Serial number, SHA-256 fingerprint, and expiry time. A later calendar date alone does not prove every live listener changed.

Technical Details:

X.509 TLS certificates carry a validity interval with Not Before and Not After timestamps. Expiry checking compares the current time with the end timestamp from the leaf certificate presented by the live TLS listener. Full trust decisions also depend on the chain, revocation status, accepted algorithms, key usage, and whether the service identity matches the requested name.

SNI changes certificate selection before the certificate is inspected. A shared IP address and port can serve different certificates for different requested names, so a check without the expected SNI value may measure a default certificate instead of the certificate clients receive for the intended hostname.

Formula Core:

The expiry runway is a time difference measured against the served certificate's Not After timestamp. Whole-day display uses upward rounding so any positive fraction of a day appears as at least one remaining day.

days_left = ceil (\frac{T_{notAfter} - T_{now}}{86400000})

action_by = T_{notAfter} - L 86400000

For a certificate that expires 9.3 days from now with a 30-day lead setting, days_left displays as 10 while the action-by date is already in the past. That combination correctly lands in the renewal lead window.

SSL expiry formula symbols
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 day count, final-week state, lead-window state, and overdue state.
`L`	The selected renewal lead time in days.	The action-by date and lead-window badge.

Renewal Stage Rules:

SSL renewal stage boundary rules
Stage	Boundary rule	How to read it
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 has opened.
Healthy	`days_left > renewal lead time`	The selected policy still has buffer.

Name Coverage Rules:

Hostname coverage is checked against SAN entries before the Common Name. Exact SAN matches pass. A wildcard SAN covers only one left-most label, so *.example.com covers api.example.com but not deep.api.example.com.

TLS certificate hostname coverage rules
Coverage result	Condition	Practical meaning
Covered by SAN	The checked host appears directly in the SAN list.	The served certificate covers the requested DNS name.
Covered by wildcard SAN	The checked host matches one wildcard label in a SAN entry.	Acceptable for that single label depth, but not for deeper subdomains.
CN-only fallback	SAN entries exist, but only the Common Name matches.	Useful troubleshooting evidence, not a clean modern service-identity result.
CN-only coverage	No SAN entries are present, and the Common Name matches.	Legacy coverage that should be replaced with explicit SAN coverage.
Name mismatch	No SAN or Common Name match covers the checked host.	The wrong certificate may be served, or the certificate needs the missing name added.

Public TLS Lifetime Context:

Certificate lifetime is the full span from Not Before to Not After. Days remaining is measured from the check time to the end of that span. Publicly trusted TLS server certificates are also subject to CA/Browser Forum lifetime limits that now shorten renewal cycles over several years.

Public TLS certificate maximum validity schedule
Issued on or after	Issued before	Maximum validity	Operational implication
15 March 2026	15 March 2027	200 days	Renewal checks become more frequent for many public certificates.
15 March 2027	15 March 2029	100 days	Automation and post-deployment verification become harder to skip.
15 March 2029	later	47 days	Expiry monitoring needs to behave like 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 server-side TLS probe so the certificate can be read outside the browser.
The check records the presented certificate even when it is expired or otherwise untrusted. That is useful for troubleshooting, but it is not a full chain, revocation, or policy compliance decision.
For CDN, multi-region, dual-stack, or active-passive deployments, repeat the check from other monitoring paths before claiming every listener is renewed.

Advanced Tips:

Set SNI override when the certificate should be selected for a tenant name that differs from the host used to reach the listener.
Use a shorter Renewal lead time only when another monitoring system already owns the earlier warning window.
Compare SHA-256 fingerprint after renewal when several certificates share similar subjects, issuers, or expiry dates.
Review the full SAN list when one certificate carries many names, because renewal or reissue work can accidentally drop a rarely tested alias.
Keep a command-line check, monitoring probe, or external region check as a second view for critical public endpoints.

Worked Examples:

Renewal did not reach the live listener

A certificate authority account shows a renewed certificate for portal.example.com, but Certificate Facts still shows the old serial number and Days remaining is 12. The useful conclusion is that issuance happened somewhere, while 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. 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 need the exact timestamp?

The day count rounds upward. Read Valid to (UTC) when the result is inside the final week or shows 1d, because only a small fraction of that day may remain.

Why is Common Name coverage not enough?

Modern service identity checking relies on Subject Alternative Name entries. A Common Name match can help diagnosis, but CN-only coverage or SAN mismatch should be fixed before relying on the certificate for public TLS traffic.

What should I compare after a renewed certificate is deployed?

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 complete chain trust?

No. It reports expiry, names, and certificate facts from the live handshake. Use full chain, revocation, and policy 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.
RFC 9525: Service Identity in TLS, IETF, November 2023.
Baseline Requirements for Publicly-Trusted TLS Server Certificates, CA/Browser Forum, version 2.2.7, 19 May 2026.
How to check SSL certificate expiration with cURL, Simplified Guide.
How to configure Let's Encrypt SSL in Apache, Simplified Guide.