Certificate Transparency is not a certificate inventory
CT logs are one of the best starting points for public certificate discovery. They are not the same thing as an operational inventory: they do not show every deployed endpoint, every internal certificate, or the team responsible for renewal.
What CT is good at
Certificate Transparency makes public certificate issuance visible. RFC 9162 describes CT as a protocol for public logging of TLS server certificates, so certificate authorities, site operators, browsers, and monitors can inspect issued certificates and detect suspicious issuance.
Chrome has required publicly trusted TLS certificates issued after April 30, 2018 to support CT in order to be recognized as valid. That makes CT a useful public discovery feed for names your organization controls.
CT can show
- Public certificates issued for names you monitor.
- Unexpected or unauthorized public issuance for your domains.
- Historical evidence that a name appeared in a public certificate.
CT does not prove
- Private PKI, self-signed, lab, appliance, and internal-only certificates.
- Whether a logged certificate is actually deployed on a live endpoint.
- The team that owns the service, the renewal method, and the alert route.
- Every hostname served behind wildcard certificates, SNI routing, or non-standard ports.
The inventory gap
CT is issuer-side evidence. It can tell you that a public certificate was logged for a name. It does not prove that the certificate is still deployed, that the service is reachable from your users, or that the right team will receive a renewal alert.
The CA/Browser Forum Baseline Requirements are scoped to publicly trusted server certificates and explicitly exclude enterprise PKI used only for internal purposes. Those internal certificates often matter during outages and audits, but they do not appear just because you watch public CT logs.
A useful inventory has four fields CT cannot supply
Source
Was the certificate found in CT, DNS, a live scan, an agent scan, or a manual import?
Endpoint
Which host, port, protocol, and SNI name presents it today?
Owner
Which team can renew, replace, or intentionally retire it?
Renewal path
Is issuance automated, delegated to a vendor, or still dependent on a ticket and manual change?
Practical checklist
- Seed public discovery from CT logs for domains you control.
- Confirm live deployment with endpoint scans, including SNI-aware checks and non-standard ports.
- Import DNS zones or known host lists so the inventory is not limited to what CAs have issued.
- Scan approved internal ranges from inside the network for private certificates that will never appear in CT.
- Attach ownership, renewal method, environment, and alert destination before the first renewal warning fires.
- Keep CT monitoring enabled for unexpected public issuance, but treat it as one discovery source.
Where Nocert fits
Nocert does not currently ingest CT certificates. It derives candidate hostnames from public datasets, scans reachable TLS endpoints, and adds internal discovery through Sentinel agents. CT remains a useful separate control for unexpected public issuance; Nocert focuses on observed public and private inventory.
Primary sources
This note is based on RFC 9162, the Chrome Certificate Transparency policy, the CA/Browser Forum Baseline Requirements, and Let's Encrypt's Certificate Transparency documentation.