--- name: cert-expiry-audit description: Paste a list of certificates (or a scan output) and get a prioritised renewal backlog with owner assignments, risk scoring, and ready-to-send comms. version: 1.0.0 author: VantagePoint Networks audience: PKI Administrators, Platform Engineers, Security Engineers, SREs output_format: Markdown report — expiry timeline, P0/P1/P2/P3 buckets, per-cert action, owner prompt, comms drafts. license: MIT --- # Certificate Expiry Audit A Claude Code skill that turns a raw cert inventory into an actionable renewal backlog. Consumes output from `testssl.sh`, `openssl` scripts, AWS ACM list, Azure Key Vault list, GCP Certificate Manager, or a hand-maintained CSV. ## How to use this skill 1. Download this `SKILL.md` file. 2. Place it in `~/.claude/commands/` (macOS/Linux) or `%USERPROFILE%\.claude\commands\` (Windows). 3. In Claude Code, run `/cert-expiry-audit`. Paste your cert list, CSV, or scanner output. ## When to use this - Quarterly or monthly cert review is due. - A new engineer has taken over PKI and wants a "what's out there" picture. - You've just been bitten by an expired cert and are building a proper inventory. - Audit is asking for a dated cert inventory and renewal plan. ## What you'll get A Markdown audit report with: 1. **Inventory summary** — total certs, internal vs public, algorithm mix, average lifetime. 2. **Expiry timeline** — 0–7 days, 8–30 days, 31–90 days, 91–365 days, beyond. 3. **Priority-bucketed renewal list** (P0 / P1 / P2 / P3). 4. **Weak / non-compliant certs** — RSA < 2048, expired root/intermediate in chain, SHA-1. 5. **Missing metadata** — certs without owner, without automation path, without deployment location. 6. **Per-cert recommended action** — renew via ACME, rotate manually, decommission. 7. **Comms drafts** — Slack/Teams ping to owners, management brief if there are P0s. ## Clarifying questions I will ask you 1. **Source of the inventory** — scanner output (which tool), cloud list, hand-maintained, or mix. 2. **Your renewal automation baseline** — ACME, Venafi, Keyfactor, HashiCorp Vault, ACM, manual. 3. **Criticality rules** — any tagging convention for prod vs non-prod, customer-facing vs internal? 4. **Owner map** — can you provide a list of known cert owners (team or individual)? If not, I'll prompt for each. 5. **What's the date today** — so "days to expiry" is accurate. ## Priority buckets - **P0 — Expired or expires within 7 days.** Replace immediately, emergency change path. - **P1 — Expires within 8–30 days.** Renew in the next regular window. - **P2 — Expires within 31–90 days.** Scheduled renewal; verify automation is armed. - **P3 — Expires 90+ days out.** Inventory sanity check; confirm owner, automation path. Certs with **weak algorithms or chain issues** are bumped one priority tier irrespective of expiry. ## Example output ```markdown # Certificate Expiry Audit — 2026-04-17 ## Inventory summary - **342 certs** across the estate. - 218 public-facing (ACME-managed 202, manual 16). - 124 internal (private CA 98, self-signed 26). - Algorithm mix: ECDSA P-256 (41%), RSA 2048 (53%), RSA 4096 (5%), RSA 1024 (1%) ← flagged. ## Expiry timeline - 0–7 days: 2 certs ← P0 - 8–30 days: 14 certs ← P1 - 31–90 days: 46 certs ← P2 - 91–365 days: 219 certs - Expired: 3 certs ← P0 (critical — see below) ## P0 — Immediate (3 certs) ### `api.example.com` — expired 2026-04-15 (2 days ago) - **Deployment:** edge-lb-prod-01/02, CDN origin - **Owner:** Platform team (@oncall-platform) - **Automation:** ACM (auto-renewal failed; DNS validation record missing) - **Action:** fix DNS validation record, re-request in ACM, bind to LB listeners. - **Rollback:** not applicable; cert was already expired. - **Incident link:** INC-20260415-001 (if open) ### `internal-ca-intermediate` — expires in 3 days - **Deployment:** root of trust for 84 internal certs. - **Owner:** Security Engineering (@secops-lead) - **Action:** issue new intermediate from offline root, cross-sign, distribute, then retire old. - **Risk if missed:** 84 downstream certs become untrusted overnight. [... per cert ...] ## P1 — This week (14 certs) [...] ## Weak / non-compliant certs (5) ### `legacy.internal.example.com` — RSA 1024 - Weak algorithm. Schedule replacement with ECDSA P-256 in the next window. [...] ## Missing metadata (12 certs) 12 certs lack an assigned owner. I've grouped them by deployment location so you can reach out: - **edge-lb-prod-01 certs (4):** prompt @platform - **internal kubernetes cert-manager (6):** prompt @sre - **dc-backup-01 (2):** prompt @infra ## Comms drafts **Slack — #platform:** > Heads up — 2 certs on edge LBs expiring in <7 days: api.example.com (expired!), status.example.com (5 days). Tracking in OPS-5521. Pairing needed for the ACM auto-renew config. cc @oncall-platform **Management brief:** > Of 342 certificates in the estate, 5 require emergency action today: 3 expired and 2 within 3 days of expiry. None currently customer-impacting but api.example.com is degraded. Root cause for api.example.com is a broken ACM DNS validation record pre-dating the PKI migration; fix in flight. Post-mortem will cover why monitoring missed the 30-day alert. ## Metrics for the monthly report - Certs auto-renewed: 198 / 218 public (90.8%) - Expired-in-production incidents this period: 1 - Mean time to rotate: not calculable (need more data) - Weak-crypto certs remaining: 5 (down from 11 last month) ``` ## What I won't do - I won't claim certs are safe based on a single scan; I'll note scope limitations. - I won't invent owners for unassigned certs; I'll prompt you. - I won't push cert rotation on weekends without flagging the SLO risk. - I won't replace a cert without confirming the new one's chain is valid downstream. ## Reference - NIST SP 800-52 Rev 2 — TLS Implementations - RFC 5280 — X.509 PKI Certificate and CRL Profile - Certificate Transparency logs — monitoring mis-issuance - CA/B Forum Baseline Requirements ## Attribution Built by **Hak** at **VantagePoint Networks**. MIT licensed.