Certificate Transparency monitoring

Every publicly trusted certificate is logged to Certificate Transparency. Browsers require it, so a CA cannot issue a usable certificate for your domain without it appearing in a public, append-only log.

That makes CT the one discovery source that cannot be evaded by shadow IT: if someone in marketing bought a certificate for your domain on a corporate card, CT knows.

What you get

• Certificates you did not order. Every CT match for a verified domain lands in your inventory, and one with no NextPKI ordering record raises an unauthorized_issuance alert - shadow IT, a forgotten vendor, or mis-issuance. Certificates issued before you verified the domain are not alerted one by one; they are summarised once, because at onboarding everything predates us and a flood of warnings would tell you nothing.
• Coverage beyond your network. CT sees certificates on infrastructure your sensors cannot reach - a CDN, a SaaS vendor’s vanity domain, a subsidiary.
• Early warning. A certificate is logged at issuance, not at deployment.

Domain ownership comes first

You cannot simply add a domain and start watching it. A domain has to pass a DNS TXT ownership check before NextPKI will monitor it.

This is deliberate, and not merely bureaucratic: without it, NextPKI would be a free reconnaissance service for anyone who wanted a report on someone else’s certificate estate. The gate also anchors the per-tenant domain quota.

Domains are managed in the Console under Settings → Domains. States are pending, verified, failed and revoked, and only verified domains are watched.

Verification is all it takes: once a domain is verified and CT watching is on, it is polled on the normal schedule. Nothing else has to be configured. If the challenge record later disappears the domain falls back to failed and watching stops, so leave the TXT record in place.

There is no domain-management API in v1 - see what is missing.

How the monitoring runs

Two mechanisms exist:

• A CT log monitor that reads logs directly, keeping a per-log cursor so it resumes where it stopped, matches entries against your verified domains and imports only hits.
• A crt.sh watcher that polls the aggregator.

The direct monitor is the strategic path - it does not depend on a third-party aggregator staying available and fast. Support for the newer tiled/static CT log format is not finished, so the RFC 6962 path is what runs.

Matching, and its limits

Matching is against your verified domains and their subdomains. Two things follow:

• A wildcard certificate for *.example.com matches example.com if that is verified.
• A certificate for a domain you have not verified will not be found, even if it obviously belongs to you. Verify every domain you care about, including the ones you think are unused - those are exactly where forgotten certificates live.

CT also cannot see certificates that were never publicly logged: internal CA issuance, self-signed certificates, and private PKI. Those are what the sensor is for. Neither source is sufficient alone, which is the whole argument for fusion.