Certificate Inventory Expiry Checker

Certificate inventory:

Common spreadsheet and CMDB header aliases are normalized locally in your browser.

Renewal policy:

Choose the operating model that best matches the inventory.

Reference date:

Use today for a live review or set the date represented by an audit export.

Additional warning lead:

Use this only when a change freeze or long deployment path requires earlier action.

days

Public validity cap override:

Keep zero unless a documented public TLS policy period requires another cap.

days

Endpoint	Not after	Days left	Status	Owner / team	Next action	Copy
{{ row.endpoint }}	{{ row.notAfter }}	{{ row.daysLeft }}	{{ row.status }}	{{ row.ownerTeam }}	{{ row.action }}

Finding	Endpoint	Severity	Evidence	Action	Copy
{{ row.finding }}	{{ row.endpoint }}	{{ row.severity }}	{{ row.evidence }}	{{ row.action }}
No audit findings The current sample has no owner, automation, date, or public validity findings.

An expired certificate is usually the last visible event in a much longer process failure. The certificate may have been missing from inventory, assigned to no owner, renewed but not deployed, tied to a manual ticket, or left on a listener that monitoring never reached.

A useful certificate inventory connects validity dates to operational responsibility. The notAfter date says when the certificate stops being valid. Owner, team, system, environment, lifecycle, and renewal method explain who must replace it, where it is deployed, and how much lead time the change needs.

Certificate inventory facts and the decisions they support
Inventory fact	Decision it supports	Important limit
Expiry date	How many calendar days remain and when escalation should begin	A row can be stale even when the date parses correctly
Validity period	Whether a public certificate's issued lifetime fits current policy	Requires both `notBefore` and `notAfter`
Owner and team	Who receives renewal work and escalation	A name in a spreadsheet does not prove current accountability
Automation evidence	Whether renewal should flow without a manual request	Renewal is incomplete until deployment and verification succeed

Renewal lead times should match the operating environment. A short-lived ACME certificate can use a smaller window because automation is expected to replace it frequently. An internal certificate behind a change freeze may need more notice. The goal is not to make every certificate share one threshold, but to start work early enough for issuance, deployment, rollback, and post-change checks.

Publicly trusted TLS lifetime limits are separate from local renewal policy. Under the CA/Browser Forum Baseline Requirements, subscriber certificates issued from March 15, 2026 through March 14, 2027 have a maximum validity period of 200 days. Later scheduled limits become shorter. Private PKI and staging certificates may follow different policies.

Expiry review also needs a stable reference date. A live operational review normally uses today; an audit export should use the date represented by that export. Re-running old inventory against today's date changes the question from “what was due then?” to “what would be overdue now?”

Inventory triage prioritizes renewal work; it does not connect to endpoints, inspect deployed chains, test hostname coverage, verify trust, or prove that a replacement certificate reached every listener.

How to Use This Tool:

Review one inventory snapshot against the policy and date that governed that snapshot.

Paste or load Certificate inventory CSV. Include endpoint and expiry; add owner, team, system, lifecycle, environment, automation, and not_before where available.
Choose the Renewal policy that matches the inventory. Split mixed operational populations into separate runs when one profile would hide their different lead times.
Set the Reference date. Use today for a live queue or the export date for a historical audit.
Add Additional warning lead only when a documented freeze or deployment path needs earlier action. Leave Public validity cap override at 0 unless a known policy period requires another cap.
Start with Renewal queue ledger, then resolve owner, system, automation, invalid-date, and public-validity findings. Verify the deployed certificate after every replacement.

Interpreting Results:

Invalid date means the expiry value is not a real YYYY-MM-DD or M/D/YYYY date. Repair the source before trusting that row.
Expired means fewer than 0 days remain; Critical includes 0 through the profile's critical day.
Renew now extends above the critical boundary through the renewal lead day. Watch extends above that boundary through the watch day.
Current means the expiry lies beyond the watch window. Missing system data or excessive public validity can still put a current row into the action queue. Owner and team gaps remain findings, while they become queue risks only inside the watch window or for a non-current status; manual renewal evidence is queued only inside the watch window.

Rows are ranked by an operational priority score, then by the nearest valid expiry. Use that order to triage, but do not let a lower-ranked production listener skip deployment verification.

Technical Details:

Dates are parsed as Gregorian calendar days without local-time or daylight-saving conversion. This makes the result a date-based inventory comparison rather than a timestamp countdown.

Formula Core:

Days left compares the certificate's ending date with the selected reference date. Issued validity can be calculated only when both endpoints are present.

\begin{array}{rcl} D_{left} & = & D_{notAfter} - D_{reference} \\ D_{validity} & = & D_{notAfter} - D_{notBefore} \\ D_{renewBy} & = & D_{notAfter} - D_{renewalLead} \end{array}

All quantities are whole calendar days. A renewal-by date at or before the reference date is reported as Now. A certificate ending on the reference date has 0 days left and is Critical, not expired; expiry begins when days left is below 0.

Triage Rule Core:

Certificate inventory policy windows
Policy profile	Critical	Renew now	Watch	Public validity cap
Mixed TLS inventory	14 days	45 days	90 days	398 days
Public TLS 2026+	14 days	45 days	75 days	200 days
Short-lived ACME	7 days	30 days	45 days	100 days
Internal PKI	21 days	60 days	120 days	825 days

Additional warning lead adds the same whole number of days to the critical, renewal, and watch boundaries. It does not alter the validity cap. A positive override replaces only that cap.

Public validity is flagged when the row is classified as public, both validity dates are present, and calculated validity is greater than the selected cap plus one day. That one-day tolerance matches the shipped review rule; the active CA/Browser Forum requirement remains the authority for public issuance.

Priority Formula:

Status supplies the base score. Operational gaps then add fixed increments before the result is capped at 100.

R = \min (100, B + 12 I (O) + 8 I (M \land W) + 8 I (V) + 4 I (P))

B is the status base: Invalid date or Expired 100, Critical 90, Renew now 72, Watch 42, and Current 10. O means owner or team is missing while action is due, M means manual or unknown renewal evidence, W means the row is inside the watch window, V means public validity is flagged, and P means the environment is marked production. The score is an operational prioritization heuristic, not part of X.509 or CA/Browser Forum policy.

The parser accepts a header with common spreadsheet and CMDB aliases or a preserved ten-column legacy order. Runs are limited to 1,000 data rows and 2 MiB of text. Lifecycle and automation labels are classified from ordinary inventory wording, so ambiguous rows should be corrected at the source.

Privacy and Accuracy Notes:

Certificate inventory text and files are parsed locally in the browser. No endpoint is contacted and no inventory row is sent to a server.

The result reflects the inventory snapshot, not the certificate currently served by a load balancer, CDN, proxy, appliance, or application.
Expiry dates do not reveal trust-chain problems, hostname mismatches, revocation, weak algorithms, missing intermediates, or a failed renewal deployment.
Inventory rows can expose internal hostnames, owners, teams, systems, tickets, and notes. Remove sensitive fields before sharing exported evidence.
Recheck current public TLS lifetime requirements before changing the validity cap; scheduled policy dates and private-PKI rules differ.

References:

RFC 5280, Section 4.1.2.5: Validity, RFC Editor, May 2008.
NIST SP 1800-16: Securing Web Transactions, TLS Server Certificate Management, National Institute of Standards and Technology, June 2020.
Baseline Requirements, Section 6.3.2: Certificate Operational Periods, CA/Browser Forum.
How to check certificate expiry using OpenSSL, Simplified Guide.
How to check SSL certificate expiration with cURL, Simplified Guide.