Your names, read from the certificate record

The problem

The asset inventory is wrong, and it is wrong in one direction. Things are added to the external surface by people who are shipping — a staging host, a vendor subdomain, a marketing microsite, a demo that got a certificate and then got forgotten. Nothing is added to the inventory by the same act.

Certificate transparency is useful here precisely because you do not maintain it. Every publicly trusted certificate is logged, so the log holds the names that were provisioned whether or not anyone wrote them down. It is the one record of your external estate that nobody on your side curates.

What this actually does

You give it a domain. It reads the certificate transparency record for the names beneath it, resolves them, and runs four checks over what it found.

1. 01

   Enumerate from the certificate log

   Every name under the domain that appears on a publicly logged certificate, capped at 500. Each becomes an external asset record, which is what lets a later scan report that a name has disappeared.

2. 02

   Resolve and probe, narrowly

   IPv4 resolution of the first 100 names, public addresses only, up to 20 of them. TCP connect to 80, 443, 8080, 8443, 22, 21, 25, 3306, 5432, 6379 and 27017, with a passive banner read. SSH, FTP, SMTP and MySQL speak first and so identify themselves; HTTP, Postgres, Redis and MongoDB do not, and stay unidentified.

3. 03

   Check where CNAMEs point

   A CNAME whose target returns NXDOMAIN or no data is a takeover candidate, reported high. A CNAME pointing at an S3 endpoint is fetched as well, and a NoSuchBucket response is reported critical: that name is claimable by whoever creates the bucket. Other providers are not fingerprinted.

4. 04

   Check the certificates themselves

   Expiry, and the issuer chain against the compromised-CA blocklist. That second check is why this and the ACM transparency audit share one module: the question after a CA incident is not whether you are on a list, it is whether anything you own chains through the wrong issuer.

All of it lands as signals on the same bus as the cloud engines, which is the point of running it here rather than as a standalone scanner. A dangling CNAME with no other context is a hygiene ticket. The same name with a certificate chaining through a distrusted root, or an open database port on an address that also appears in an attack path, is a different conversation — and the correlation rules are what hold the two observations together.

What this is not

This is a certificate-transparency-led view of your external names. It is not a full-surface scanner, and the gap is wide enough to belong on the page rather than in a footnote.

• It does not discover your domains. You supply the domain, through a scan request or the integration's configuration. Connecting a cloud account does not teach it your apex names, and there is no WHOIS, ASN, netblock, passive DNS or search-engine discovery.
• It sees only what the certificate log sees. A host that never received a publicly trusted certificate — an internal name, something behind a wildcard, anything on a private CA — does not appear, and there is no DNS brute force to fill that gap.
• It does not fingerprint web applications. No HTTP request is made to your hosts, no TLS handshake, no headers, no page titles, no technology detection, no exposed-admin-panel checks, no CVE matching. The only version strings it reads come from services that announce themselves on connect.
• The port probe is crude, and errs quiet. Open means the TCP connection was established; a host that silently drops packets reads as closed, so a filtered port is indistinguishable from an absent one. One probe, one timeout, no retry, so a slow or rate-limited host can be missed.
• Takeover coverage is DNS plus S3 only. A dangling CNAME is caught by resolution, and a CNAME at an S3 endpoint is checked for the unclaimed-bucket response. There are no provider fingerprints beyond S3 — Azure, GitHub Pages, Heroku, Fastly and the rest are not checked — so the absence of a takeover finding is not the absence of a takeover.
• Expiry is checked for the apex, from the log. Certificate transparency records what was issued, not what your server presents today.
• IPv4 only, five domains per scheduled run, and the scheduled path requires a Growth or Enterprise plan.

Where it fits

Run it as external corroboration of a cloud inventory you already have, not as the inventory. The cloud engines know what is in the accounts you connected. This knows what the public record says exists under your names — which is how you find the things that are in neither place: the vendor subdomain, the certificate a team requested without telling anyone, the CNAME left behind by a migration two years ago.