Skip to content

Discovery sources

The certificates that cause outages are the ones nobody wrote down. NextPKI therefore treats discovery as a fusion problem: several independent sources report what they see, and the platform merges them.

Source Finds Status
Discovery sensor Anything serving TLS in your own network, including internal-only and self-signed Available
Certificate Transparency Every publicly-trusted certificate issued for your domains, by anyone Available
CA account sync What you already manage in your CA accounts Planned - see below
Cloud providers AWS ACM, Azure Key Vault, GCP Certificate Manager, Cloudflare Planned
AD CS Internal Microsoft PKI estates Planned
Manual upload Edge cases and one-offs Available
Domain probing Common names on verified domains (www., mail., …) Available

The two that are live cover the two blind spots that matter most: the sensor finds what is inside your network and invisible from outside, and CT finds what was issued for your domains without you.

Certificates are identified by SHA-256 fingerprint, not serial number. Two CAs can legitimately issue the same serial; a fingerprint collision is a different class of problem entirely.

So the same certificate found by three sources is one row with three observations, not three rows. An observation records where and when it was seen - IP, port, hostname, SNI, protocol, timestamp - or, for a CT observation, which log it appeared in.

This is why the inventory is worth more than a list of expiry dates:

  • A certificate with no recent observation is a candidate for cleanup, not renewal. Nothing is serving it.
  • A certificate seen by CT but never by a sensor was issued for your domain and is not deployed in the network you scan. Shadow IT, an external vendor, or something worse.
  • A certificate on three IPs needs three deployments when you renew it, which is exactly the thing people forget.

Why expiry dates are the least interesting field

Section titled “Why expiry dates are the least interesting field”

Every certificate tool can tell you not_after. That is arithmetic. The hard questions are which hosts serve this certificate, who issued it, whether anyone still uses it, and whether it was ordered by someone authorised to order it. Those are all observation questions.

This is the source most customers ask for first: import the certificates you already manage in your DigiCert, Sectigo or GlobalSign account, so day one shows a complete picture rather than only what a scan finds.

The plumbing is designed - providers carry an inventory-sync capability flag, and 13 of the 15 in the registry set it - but the synchronisation is not running yet. Until it does, certificates from those accounts arrive through Certificate Transparency, which finds every publicly trusted certificate anyway; what CT cannot tell you is the order metadata, the account it belongs to and what you paid.