Certificate Inventory Expiry Checker

Introduction

Certificate expiry is an operational risk as much as a security detail. A TLS certificate that reaches its notAfter date can break browsers, APIs, load balancers, identity providers, and automated jobs even when the protected service is otherwise healthy. The practical question for a certificate inventory is which entries need action now, which need renewal planning soon, and which rows are missing the owner data needed to finish the work.

A useful inventory has more than hostnames and expiry dates. Renewal work depends on the service owner, operating team, environment, certificate authority, deployment system, automation evidence, and any ticket or note that proves a plan exists. A row with 40 days left and a working ACME flow is very different from a row with 40 days left, no owner, and a manual spreadsheet note.

Publicly trusted TLS certificates also have policy pressure behind them. Public certificate validity limits have shortened over time, and the 2026 public TLS schedule makes 200-day lifetimes a normal planning constraint. Internal PKI, staging, and private service certificates may follow different rules, but they still fail in production when nobody owns the replacement path.

An inventory check is not a live scan and does not prove that a deployed endpoint is serving the same certificate shown in a spreadsheet. It helps turn an export, CMDB slice, or renewal worksheet into a review queue. After a risky row is found, the deployed certificate, chain, owner, and change record still need confirmation in the systems that run the service.

Technical Details:

X.509 certificates carry a validity interval bounded by notBefore and notAfter. For expiry planning, the relevant value is the number of whole days from the chosen reference date to notAfter. Negative days mean the certificate is already expired against that reference date. Missing or unparseable expiry values become an invalid-date finding because the row cannot support a renewal decision.

The review uses policy windows to sort each row into status lanes. The critical window marks urgent work, the renewal lead window marks rows that should already have a renewal plan, and the watch window keeps upcoming certificates visible before they become urgent. These windows can come from an operating profile or from the advanced controls, and the logic raises the renewal window to at least the critical window and the watch window to at least the renewal window when needed.

Rule Core

Risk scoring starts with the status lane and then adds context. Expired and invalid rows begin at the highest score, critical rows begin near the top, renewal rows begin high, watch rows begin medium, and current rows begin low. Missing owner or team data can add risk, manual or unknown renewal evidence can add risk inside the watch window, public certificate validity above the selected cap can add review pressure, and production environment text adds a small increase.

The profile choice changes the default windows and validity cap. Mixed TLS inventory uses 14 critical days, 45 renewal days, 90 watch days, and a 398-day public cap. Public TLS 2026+ keeps the same critical and renewal windows, narrows watch to 75 days, and uses a 200-day public cap. Short-lived ACME uses 7, 30, 45, and 100 days. Internal PKI uses 21, 60, 120, and 825 days.

Input parsing is intentionally spreadsheet-friendly. Header aliases normalize common names such as endpoint, host, domain, expires, valid until, owner, team, issuer, renewal method, service, serial, ticket, and notes. If no header row is detected, rows are read in the legacy order of endpoint, expiry, owner, team, environment, lifecycle, issuer, automation, system, and notes. Date cells accept ISO dates, month/day/year dates, and other dates the browser can parse.

Everyday Use & Decision Guide:

Start with the profile that matches the inventory slice. Use Mixed TLS inventory for a broad export, Public TLS 2026+ when the rows are public certificates issued under the newer lifetime schedule, Short-lived ACME for automation-heavy short certificates, and Internal PKI for private trust stores with longer renewal cycles.

Set Reference date to the day the review should represent. Today is useful for active triage. A planned handoff date is better when the renewal queue is going into an audit, maintenance window, or future change freeze. Keep the same reference date when comparing repeated reports, or the days-left counts and status lanes will move simply because time moved.

• Paste a CSV with endpoint and expiry columns at minimum; add owner, team, environment, lifecycle, issuer, automation, system, ticket, and notes when available.
• Use Raise missing owners when missing owner or team values should block renewal handoff inside the watch window.
• Keep Highlight manual renewals enabled when spreadsheet, ticket, email, calendar, or unknown renewal evidence should be visible in the queue.
• Adjust Public validity cap only when the selected inventory uses a different public TLS policy or a legacy review needs a wider cap.
• Use Ledger row limit to keep visible tables manageable; the structured JSON still keeps the full normalized result.

Read Inventory Snapshot first to confirm row count, reference date, urgent count, renewal queue size, ownership gaps, public validity reviews, and earliest expiry. Then move to Renewal Queue for action order and Ownership Gaps for missing accountable teams, systems, or automation evidence. The Certificate Ledger is the broad row-by-row audit view, while Expiry Risk Map groups status counts by lifecycle mode.

A clean result does not mean every certificate is installed correctly or trusted by clients. It means the inventory rows supplied to the tool did not trigger date, ownership, manual-renewal, or public-validity findings under the selected settings. Verify the live endpoint or deployment record before closing a renewal ticket.

Step-by-Step Guide:

Use one pass to normalize the inventory, then use the result tabs to separate urgent expiry work from data cleanup.

1. Choose Renewal policy; the advanced window values will update to the profile's critical, renewal, watch, and public validity defaults.
2. Set Reference date; the summary line will later report how many certificate rows were checked against that date.
3. Paste the certificate inventory or use Browse CSV; if the alert says to paste at least one row, add rows with at least endpoint and expiry values.
4. Use Risk sample or Clean sample only for orientation, then replace the sample rows with the real inventory before trusting results.
5. Open Advanced when policy windows, public validity cap, row limit, missing-owner priority, or manual-renewal highlighting need to match the review runbook.
6. Resolve parser notes before handoff. A missing header note means the legacy column order was used; window warnings mean renewal or watch values were raised to keep the thresholds in order.
7. Check the summary badges for urgent rows, queue count, owner gaps, and selected profile, then open Inventory Snapshot to confirm the parsed count and earliest expiry.
8. Use Renewal Queue, Ownership Gaps, Certificate Ledger, Expiry Risk Map, and JSON for the evidence needed by the renewal owner or audit record.

Interpreting Results:

Start with the urgent count. It combines expired, critical, and invalid-date rows because all three need immediate attention, either by replacing a certificate or fixing source data before renewal planning continues. A row with an invalid date should not be ignored just because it is not confirmed expired; without a parseable expiry date, the inventory cannot prove it is safe.

• Risk band: Use the band to sort work, but read the evidence cell before assigning action. A High row may be high because of expiry pressure, missing ownership, manual renewal evidence, or more than one signal.
• Escalate by: Now means the row is already expired or has passed the calculated renewal-by date. A date value is the expiry date minus the renewal lead window.
• Public validity review: This is a policy cue, not proof of misissuance. Confirm the actual issue date, certificate type, CA policy, and trust context before treating it as a compliance finding.
• Owner gaps: Missing owner or team values matter most when the row is inside the watch window or already outside the current lane.

Do not close a certificate review from the snapshot alone. Match the queue row to the ledger evidence, then verify the owner, deployment target, and certificate currently served by the system. The inventory can prioritize renewal work; it cannot confirm that a load balancer, application server, or appliance has already been updated.

Worked Examples:

A production VPN inside the critical window. With Mixed TLS inventory, a reference date of 2026-05-06, and a row for vpn.example.com expiring on 2026-05-11, the certificate has 5 days left. The row lands in Critical, the Renewal Queue shows a Critical risk band, Escalate by is Now, and the next action calls for urgent renewal and deployment validation.

A public certificate with a long validity period. Under Public TLS 2026+, a public row with not_before 2026-03-20 and not_after 2027-01-05 has about 291 days of validity. Because that exceeds the 200-day cap plus the tool's one-day tolerance, Ownership Gaps can include a Public validity review finding and Certificate Ledger records the validity evidence for follow-up.

A current internal service with missing metadata. An internal PKI row that expires in 110 days may stay in Watch under the 120-day internal profile. If owner is present but team or system is blank, the row can appear in Ownership Gaps even though the expiry date is not urgent. The corrective path is to attach the operating team and service record before the renewal lead window opens.

A malformed export that should stop the review. If the first data row says legacy-api.example.net,not-a-date,Payments, the status becomes Invalid date. The summary counts it as urgent, the queue evidence names the unparseable expiry value, and the next action is to fix the source date before relying on the report.

FAQ:

Glossary:

notAfter

The certificate validity end date used to calculate days left and expiry status.

notBefore

The certificate validity start date used with notAfter to calculate public validity duration when present.

Renewal lead window

The number of days before expiry when a certificate should already have owner action, issuance, deployment, and verification underway.

Watch window

The outer planning window that keeps upcoming certificates visible before they become renewal work.

Owner gap

A missing owner or team value that can block renewal assignment and notification.

Manual renewal evidence

Inventory wording such as manual, ticket, spreadsheet, email, calendar, unknown, or blank automation that suggests renewal may depend on human follow-up.

References:

• RFC 5280: Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List Profile, Internet Engineering Task Force, May 2008.
• NIST SP 1800-16B: Securing Web Transactions: TLS Server Certificate Management, NIST National Cybersecurity Center of Excellence, June 2020.
• TLS Baseline Requirements, CA/Browser Forum.