Certificate Inventory Expiry Checker

Introduction:

A certificate expiry incident rarely begins on the day a browser starts rejecting the connection. The visible outage is usually the last symptom of missing inventory ownership, a stale renewal reminder, an unmanaged public certificate, or a spreadsheet row that nobody trusted enough to act on. For Transport Layer Security (TLS) services, the printed validity dates matter, but the renewal handoff also needs a service owner, a deployment path, and enough context to decide which rows deserve attention first.

Certificate inventory review turns scattered certificate rows into an operations queue. A useful review does not only sort by date. It asks whether the expiry date is parseable, whether the certificate is public or private, whether the service is production-facing, whether renewal is automated, and whether a named owner can take the row from warning to replacement.

The X.509 validity interval uses two fields. notBefore marks when the certificate begins to be valid, and notAfter marks when that validity period ends. Renewal triage usually starts with the number of days from a chosen reference date to notAfter, then adds operational signals that decide whether the row is ready for assignment or still needs source-data repair.

Publicly trusted TLS subscriber certificates have a separate policy context. The current CA/Browser Forum Baseline Requirements, version 2.2.7 dated May 19, 2026, set a 200-day maximum validity period for subscriber certificates issued on or after March 15, 2026 and before March 15, 2027. The same schedule reduces the maximum to 100 days on March 15, 2027 and 47 days on March 15, 2029. Private PKI and internal lab certificates can follow local policy, but long internal lifetimes still deserve visible ownership and monitoring.

Good inventory review keeps date urgency and data quality together. A certificate expiring in five days needs immediate action, but a certificate with 60 days left and no owner may still block a clean renewal. A public row with an unusually long validity period may need policy review even when it is not close to expiry. Those distinctions keep renewal work from becoming only a date sort.

How to Use This Tool:

Use the checker for a certificate spreadsheet, configuration management database (CMDB) export, or renewal handoff list that needs priority ranking before owners start work.

1. Choose Renewal policy. Mixed TLS inventory uses 14 critical days, 45 renewal lead days, 90 watch days, and a 398-day public validity cap; the public, short-lived ACME, and internal profiles adjust those defaults for narrower programs.
2. Set Reference date to the day the report should represent. Use today for a live review, or use a past audit date when matching evidence from an earlier inventory export.
3. Paste rows into Certificate inventory, drop a CSV or text file, or use Browse CSV. Endpoint and expiry are the minimum useful fields; owner, team, environment, lifecycle, issuer, automation, system, serial, not_before, ticket, and notes make the queue more actionable.
   Files larger than 2 MiB are rejected, so trim very large exports or paste the service slice that needs review.
4. Use Risk sample or Clean sample only to learn the output shape. Replace sample rows before relying on the summary, tables, or JSON handoff.
5. Open Advanced when a runbook needs custom Critical window, Renewal lead window, Watch window, Public validity cap, Ledger row limit, Raise missing owners, or Highlight manual renewals settings.
   If the renewal window is lower than the critical window, or the watch window is lower than the renewal window, the later window is raised and reported in Parser notes.
6. Fix Review certificate inventory input and Parser notes before sharing results. These messages flag empty input, unreadable rows, legacy column-order fallback, or adjusted thresholds.
7. Read Inventory Snapshot first, then assign work from Renewal Queue, clean routing problems in Ownership Gaps, verify row evidence in Certificate Ledger, compare lifecycle shape in Expiry Risk Map, and use JSON when another system needs structured output.

Interpreting Results:

The urgent count includes expired, critical, and invalid-date rows. Invalid dates are urgent because a row with no parseable notAfter value cannot prove that a deployed certificate is still safe.

• Clear means the supplied rows did not produce urgent expiry or queued action under the selected settings. It does not prove every deployed endpoint was discovered.
• Renewal Queue sorts by risk score first and days left second. Read Evidence and Next action before assigning work, because missing owners, manual renewal wording, production environment text, and public validity findings can raise a row above a simple date sort.
• Escalate by shows Now for expired rows or rows that have already passed the renewal-by date. Otherwise it uses the expiry date minus the selected renewal lead window.
• Ownership Gaps can include rows that are not close to expiry. Missing owner, team, or system values, manual renewal evidence, invalid dates, and public validity review findings are data-quality problems that can block renewal later.
• Expiry Risk Map groups rows by lifecycle such as public, private/internal, staging/lab, or unknown. Use the chart to see portfolio shape, then verify the individual certificate rows in the queue or ledger.

Technical Details:

X.509 validity is a certificate property, while renewal readiness is an operations property. The certificate validity interval answers whether the certificate can still be accepted at a given time. Inventory triage adds owner, environment, lifecycle, and automation evidence so near-term dates become assignable work instead of isolated warnings.

Calendar-day normalization keeps rows comparable across mixed spreadsheet formats. ISO dates such as 2026-05-29 are the most reliable input. Slash dates such as 05/29/2026 are accepted, and other parseable date strings may depend on browser parsing. A blank or unparseable expiry becomes Invalid date.

Formula Core:

Days left is calculated from the selected reference date to notAfter. Validity duration uses both notBefore and notAfter, so rows without an issue date can still be ranked for expiry but cannot be checked against a public validity cap.

For a reference date of 2026-05-29, a certificate expiring on 2026-06-03 has 5 days left. Under the default 14-day critical window, that row is Critical. A public certificate with notBefore 2026-03-20 and notAfter 2027-01-05 has 291 validity days; with a 200-day cap, that row receives a public validity review finding because the duration is more than the cap plus the one-day tolerance.

Rule Core:

Final risk bands use the capped score: >= 90 is Critical, >= 70 is High, >= 40 is Medium, and lower values are Low. The queue then sorts by score and uses days left as the tie-breaker.

Input Normalization:

The visible ledger row limit controls table display after sorting. Structured output keeps the normalized inventory and selected settings, so a compact screenshot run can still be repeated later with a larger ledger limit for handoff.

Privacy and Accuracy Notes:

CSV files and pasted inventory rows are parsed in the browser. The checker does not contact listed endpoints, fetch live certificate chains, inspect private keys, check revocation, or submit inventory rows to a server. The page may load its chart library from a public content delivery network, but the pasted inventory text is analyzed locally.

• Use the result as renewal triage, not proof that production has already been updated.
• Confirm high-risk rows against live endpoint checks, deployment records, and certificate-management systems before closing renewal work.
• Review public validity findings as policy prompts. They depend on the supplied notBefore, notAfter, lifecycle wording, selected cap, and current public TLS rules.

Advanced Tips:

• Keep the selected Renewal policy and Reference date with any exported evidence so another reviewer can reproduce the urgency labels.
• Use the Public TLS 2026+ profile for newly issued public TLS rows during the 200-day validity period, then adjust the cap when later CA/Browser Forum dates take effect.
• Leave Raise missing owners enabled during handoff reviews. A date can be comfortable while a missing team value still prevents assignment.
• Leave Highlight manual renewals enabled for production and edge services, where calendar or ticket reminders are more likely to fail during staffing changes.
• Use Ledger row limit for display size only. Increase it before exporting a large handoff so row-level evidence is visible without changing the underlying scoring.
• Pair the queue with a live certificate check when the inventory came from an old scan or a manually maintained spreadsheet.

Worked Examples:

FAQ:

Glossary:

notBefore

The start of the certificate validity interval.

notAfter

The end of the certificate validity interval and the date used for days-left scoring.

Renewal lead window

The planning window before expiry when renewal, deployment, and verification work should already be active.

Watch window

The outer planning window used to keep upcoming certificates visible before they become active renewal work.

Owner gap

A missing owner or team value that can prevent renewal work from being assigned cleanly.

Manual renewal risk

Inventory wording that suggests replacement depends on a person, ticket, spreadsheet, or reminder rather than a managed renewal process.

Public validity cap

The selected maximum validity duration used to flag public TLS rows for policy review.

References:

• RFC 5280: Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List Profile, IETF, May 2008.
• NIST SP 1800-16B: Securing Web Transactions: TLS Server Certificate Management, NIST National Cybersecurity Center of Excellence, June 2020.
• Latest Baseline Requirements, CA/Browser Forum, May 19, 2026.
• Ballot SC081v3: Introduce Schedule of Reducing Validity and Data Reuse Periods, CA/Browser Forum, April 11, 2025.
• How to check SSL certificate expiration with cURL, Simplified Guide.