Skip to main content

Discovery inventory

The inventory is the union of every certificate discovered across your configured sources, de-duplicated by SHA-256 fingerprint. Filter, sort, cross-reference with managed certs, and export — the inventory is where you answer "what certs do we actually have?"

note

Scan results are persisted as they arrive, so during a long-running scan the inventory fills in progressively rather than in one burst when the scan finishes (refresh the page to see new rows). Anything that needs the whole scan still lands only when the run completes: run counters, disappearance detection, the findings refresh, new-certificate / certificate-changed notifications, and the cipher-suite enumeration pass — so a row discovered mid-scan shows an empty Accepted (weak) column until the run ends.

Default columns​

  • Subject CN and first two SANs (the rest show on hover).
  • Issuer (CN of the issuing CA).
  • Valid from / to.
  • Days remaining — colour-coded (red < 7, amber < 30, green otherwise).
  • PQC status — vulnerable, transition, ready, or unknown. See PQC readiness.
  • Endpoints — count of host:port tuples where the cert was seen.
  • Managed — linked to a managed certificate, or shadow.

Deprecated TLS on the Endpoints tab​

Next to the negotiated TLS version each endpoint shows whether the server also accepts the deprecated TLS 1.0 / 1.1 — the two are different questions, and an endpoint that negotiates TLS 1.3 with you can still let a downgrade-capable client negotiate TLS 1.0.

  • also 1.0, 1.1 (red) — the server completed a handshake on that deprecated version. This is what raises the corresponding finding.
  • no legacy (green) — no acceptance of either version was recorded. Normally that means both were refused, but the probe runs once per host and is not retried, so a host whose single probe could not complete its handshake also reads this way.

Answering this needs its own handshake, so it is probed once per host:port rather than once per name: TLS version support is a property of the listener, not of the server name you ask for. The measured answer is then shared with every endpoint row of that host, so all rows of one host agree. Rows discovered before this became the behaviour keep their old value until the next scan of that source.

Edge and origin on the Endpoints tab​

A name behind a Cloudflare proxy (orange cloud) is discovered on both sides of the proxy by a Cloud DNS Provider source, and the Endpoints tab tags each row: Edge is the Cloudflare edge address the name resolves to on public resolvers — the certificate visitors see — and Origin is the address in the DNS record, the certificate the origin server itself presents. Rows from records that are not proxied, and rows from every other source type, carry no tag.

Filters​

  • Expiry window — <7, <30, <90, <365 days, expired.
  • PQC status.
  • Issuer — pick one or multiple.
  • Key algorithm — RSA-2048 / RSA-3072 / RSA-4096 / ECDSA-P256 / ECDSA-P384 / ECDSA-P521 / unknown.
  • Managed status — managed, shadow, imported.
  • Source — restrict to a specific discovery source.
  • Free-text search — matches CN, SANs, issuer CN, endpoint.

Cert detail​

Clicking a row opens the detail panel:

  • Full subject + SANs + issuer chain.
  • PEM export (public material only — private keys are not in inventory).
  • Endpoint list with per-endpoint last-seen timestamps and cipher-suite observations.
  • Change history — if the same endpoint previously served a different cert, the transitions are recorded.
  • Findings — any open security findings tied to this cert.
  • Manage action — promotes the cert to a managed certificate via Manage wizard.

Managed vs shadow​

  • Managed: the cert is also in certificates — CertAutoPilot issued or explicitly imported it. You don't have to run the Manage wizard for a cert CertAutoPilot already issued: after a complete scan, discovery automatically links a discovered cert to the managed certificate with the same fingerprint, so a cert you issued here and then rediscovered flips from unmanaged to managed on its own. Deleting the managed certificate unlinks it again (the discovered record stays, as unmanaged). The reverse view lives on the managed certificate itself: its detail page has a Discovery tab listing every live endpoint discovery has seen serving that certificate (its current leaf or a retained version), flagging any endpoint still on an older version after a renewal.
  • Shadow: the cert exists in the wild but CertAutoPilot doesn't own its lifecycle. Shadow certs are the top candidates for Manage import or for a conversation with the team that owns them.
  • Imported: a previously-shadow cert has been adopted via the Manage wizard. From now on, renewal and distribution flow through CertAutoPilot.

Stats widget​

At the top of the inventory, summary tiles show:

  • Total discovered certs.
  • Split by PQC status — a pie chart of vulnerable / transition / ready.
  • Split by issuer — top 5 CAs.
  • Expiring this month / this quarter.

These are the same data the 47-day readiness dashboard consumes, so inventory and dashboard always agree.

Export​

Click Export on any filtered view:

  • CSV — flat columns, ready for spreadsheet or BI tools.
  • JSON — full structure with endpoint list and chain.

Exports stream server-side; no buffer → no memory blow-up on a 50 k-cert inventory.

API​

GET /api/v1/projects/{projectId}/discovery/certificates
    ?expiry_within_days=30
    &pqc_status=vulnerable
    &managed=false
    &limit=200
    &cursor=...

Returns cursor-paginated discovered certs. next_cursor points to the next page. See API reference.

Retention​

Discovered certs are not kept forever: after a scan that fully covered its source, a certificate no longer served by any active endpoint is deleted as an orphan (a grace window protects one a concurrent scan just re-upserted). So the inventory tracks what is currently out there, not a historical archive — export anything you need to keep for compliance before it stops being served.

See also​