A Certificate Log Is a Permanent Public Inventory of Your Subdomains

A certificate transparency log is a permanent, public, append-only record of every hostname you have ever asked a certificate authority to vouch for — including the names you never finished issuing a certificate for, and the names you deleted from DNS years ago. It is not a bug in the logs. It is the point of the logs. And it means your subdomain inventory is not a private document, no matter how carefully you have kept it private.

Here is the scene that makes this concrete. A platform engineer runs a routine DNS query against their own apex domain on a Monday morning — not a security scan, just a check on a certificate that is about to expire. The answer includes a hostname nobody on the current team recognises: something like staging-2023, still resolving, still answering on port 443, still presenting a certificate. It is running an old version of the internal admin tool, the one that was retired when the new one shipped. It has been reachable from the public internet for two and a half years, and it was found by accident.

The question worth asking is not "how did we miss this in the inventory". It is "how did the inventory miss this when the answer was published, in a public log, at the moment the first certificate was requested". Every public TLS certificate — and, as the next section explains, every certificate that was about to be issued — is written into a set of logs that anyone can read, and that nobody can edit or delete. The reconnaissance work is already done for anyone who wants it. What is left is the part people skip: reading it on purpose.

A Log Entry Is Not a Certificate

The mistake almost everyone makes is assuming that a name appears in the transparency logs because a certificate was issued for it. That is not the mechanism, and the difference is where the most useful names hide.

Certificate Transparency was standardised as RFC 6962 in June 2013, and the design deliberately separates the act of logging an intention from the act of issuing a certificate. The certificate authority does not submit the finished certificate. It constructs something the RFC calls a pre-certificate: the exact body of the certificate it is about to sign, plus one extra field bolted on — a critical extension whose only job is to make the object impossible to validate as a real certificate. RFC 6962 assigns that extension the object identifier 1.3.6.1.4.1.11129.2.4.3 and carries ASN.1 NULL data, and it is explicitly marked critical so that a standards-compliant X.509 client will refuse the pre-certificate rather than treat it as a usable credential.

The authority submits the pre-certificate to one or more logs. Each log validates the signature chain and returns a signed certificate timestamp — an SCT — which is the log's promise to merge that entry into its Merkle tree within a fixed delay. The authority then embeds those SCTs into the final certificate, in an extension with its own identifier, and only then does the finished certificate exist.

The ordering matters, and RFC 6962 is explicit about why. The signature on the pre-certificate is treated as a binding statement of the authority's intent to issue: a mis-issued pre-certificate counts the same as a mis-issued certificate. Logging first, issuing second, is how the system makes the record complete. It also means the record is created before anything can go wrong, stop, or be cancelled.

So a name can appear in the log in at least four situations where no usable certificate ever shipped to the public:

• The validation challenge failed after the pre-certificate was submitted, and the order was abandoned.
• The certificate was issued but the deployment job never completed, so nothing was ever served.
• The certificate was issued, served, and then revoked; revocation changes the certificate's validity, not the log's contents.
• The certificate was for a test, a staging name, or an internal service that was never intended to be public at all.

Two technical footnotes are worth stating accurately, because a lot of writing about this topic gets them wrong. First, the poison extension above is the CT 1.0 mechanism. When the protocol was revised as RFC 9162 in December 2021 — which obsoletes RFC 6962 — the pre-certificate signing certificate and the poison extension were both removed, and the pre-certificate became a CMS signed-data object whose certificate body simply omits the transparency information extension. The "logging precedes issuance" property survives the revision; the specific extension does not. Second, the log record is the pre-certificate's name fields, which is why the phenomenon below exists at all: an entry is a statement about names, and it lives forever.

The practical consequence is a list you have never seen. Certificate authorities do not log a hostname because it is important. They log it because someone, at some point, ran a command that asked for a certificate for it.

What the Logs Actually Contain Right Now

It is tempting to treat transparency logs as a niche audit trail with a manageable volume. The live counters say otherwise. The following figures are a snapshot of public CT logs taken on 4 November 2026 at 02:13 UTC from an independent statistics collector:

Three ratios are worth computing from those figures, because they describe the shape of the exposure rather than its size.

October's monthly total divided by 31 days is roughly 233 million entries per day; September's, divided by 30, is roughly 225 million. That is a little over three percent month-over-month growth on a number already in the billions — and it is the raw entry count, before the duplicate suppression that produces the "unique certificates" estimate. The 316,660,156 entries recorded on 3 November work out to about 3,665 entries per second.

The most useful ratio is the one nobody quotes: 1,707,725,644 names spread across 354,794,229 registrable domains is roughly 4.8 distinct DNS names per domain. Note that this is arithmetic performed on the collector's published figures, not a figure the collector states. It is still the number that should reframe the problem, because it means the median organisation's public hostname count is not one or two. It is a handful, scattered across services and subdomains and years of project names — exactly the conditions under which one gets forgotten.

The collector also reports coverage health, which is worth reading as a caution about the completeness of any single view: of 85 configured logs, 33 were processing a backlog, with roughly 606,000 entries still pending, and the slowest — Cloudflare Nimbus 2027 — was falling behind by about as many entries as it had remaining. A log that is behind is not a log that has stopped. It means the answer to "what has been logged for my domain" is eventually complete, not instantly complete.

Why the Disclosure Only Gets Larger

Two structural properties guarantee that this problem gets worse rather than better, and neither is under your control.

The first is append-only. A transparency log is a Merkle tree. Entries can be added; they cannot be removed, and if anyone tampered with history, the tree's published hashes would not match and monitors would notice. There is no opt-out, no takedown, and no expiration. A hostname logged in 2018 for a certificate that expired in 2019 is still in the log today, and will still be there in 2036. Decommissioning the host, deleting the DNS record, and letting the domain lapse does nothing to the entry. The only thing that changes is whether the hostname still resolves — which is a different question from whether it is still published.

The second is that certificate lifetimes are being deliberately shortened, and shorter lifetimes mean more logging events. The CA/Browser Forum approved Ballot SC-081v3 in April 2025, establishing a phased reduction in the maximum validity period for publicly trusted certificates, from 398 days to 47 days:

Certificates issued before each deadline keep the longer validity they were issued with, so the change applies to newly issued certificates only. Let's Encrypt, whose certificates were already at 90 days and therefore unaffected by the first phase, has published its own tighter schedule: 64 days from 10 February 2027, then 45 days from 16 February 2028.

Put the two properties together. A single staging hostname at 90-day validity generates about four certificates a year. As validity drops toward 47 days, the same hostname generates about 7.8 — and if your issuance tooling submits to multiple logs per certificate, the entry count multiplies again by the number of logs. The name is not becoming more secret with time. It is becoming more frequently published, in more places, by an automatic process that will keep running whether or not anyone remembers what the hostname is for.

What an Attacker Does With the List

None of this is exotic tradecraft. The list is the first step of a workflow that is scripted, cheap, and largely automated, and it is worth walking through in the order it actually happens, because understanding the sequence is what tells you where to intervene.

Step one is enumeration. Query the logs for the apex domain. The result is a complete set of names anyone has ever requested a certificate for, including the ones that predate your current team. Because the query is against public, keyless endpoints, there is no authentication event to alert on and no rate limit that matters. You will not see this step in any log of your own, because it does not touch your infrastructure.

Step two is resolution. Resolve every returned name. This splits the list into two very different piles. Names that no longer resolve tell the attacker about your history and your naming conventions — useful for guessing what else exists. Names that do resolve are live targets, and the interesting subset is the one that resolves but does not appear in your public documentation or your marketing site.

Step three is fingerprinting. For each live name, take the response headers, the certificate subject, the error page, and the server banner. This is where the names from the log outperform anything a scanner would find by brute force: a name like staging-2023 is not in any wordlist, but it is in the log, and it very often answers with a framework default page, a debug toolbar, or an unauthenticated admin panel.

Step four is the exploit. The log-derived names are disproportionately likely to be the ones that were never hardened, because hardening attention follows production. Two outcomes dominate. The first is subdomain takeover: the name still has a DNS record pointing at a third-party service — an object-storage bucket, a static-site host, a retired platform — whose registration lapsed. The record is dangling, the platform will hand the name to whoever registers it next, and the attacker now serves content from a hostname inside your domain. The second is simply an unauthenticated or default-credential interface on a host that was stood up for a two-week test and never taken down.

There is a variation of the first outcome that is worse than a defaced page. If the name appears in a cookie scope or a CORS allowlist, a takeover on a subdomain can be used to read or set cookies for the parent domain, or to satisfy an origin check. At that point the forgotten staging host is not a staging problem. It is a session-integrity problem for production.

Two counterpoints belong here, because the honest version of this argument is not "every log-derived name is a hole". First, the transparency logs themselves make takeovers detectable in advance: an unexpected certificate for a name you own is precisely the kind of signal the logs were designed to surface, and it is available to you at the same moment it is available to the attacker. Second, a name appearing in the log is not proof that anyone owns it, that it is currently in use, or that it is authorised by the domain owner — the collector that publishes these statistics says so explicitly. The log tells you a name was asserted. Resolution and response tell you whether it is still real.

Five Things People Blame Instead of Their Inventory

The reason this problem persists inside organisations that do run security tooling is that the tooling is aimed at the wrong artifact. A vulnerability scanner recurses over the hostnames it is given. A web application firewall defends the hostnames in front of it. Neither discovers a name that nobody has added to either list. The following table is the set of substitutions that get made, and why each one leaves the log-derived name untouched.

Notice the common structure. Four of the five controls derive their scope from a list that was written down inside the organisation. Transparency logs are the one source of scope that is written down outside it, by a third party, at a moment when someone definitely knew the name existed. That is why the log is the right starting point even though it feels like the least official one.

The Three Lists Worth Monitoring

Log data is only useful once it is sorted into questions that have answers. There are three, and they are different enough that a single query will not produce them.

Names you own and had forgotten

Query the log for your apex domain, resolve every result, and compare the resolving set against your documented inventory. Everything in the difference is a finding by definition — not necessarily a vulnerability, but an unknown. This is the list that produces the staging-2023 moment. The first time it is run it is uncomfortable, which is the correct outcome.

Names that should not exist at all

This is the reverse query, and it catches something different: certificates issued for names that resemble yours but are not yours. Lookalike registrations, typosquats, and names that borrow your brand but are not on your domains. Because the log makes every public issuance visible, a phishing domain that bothers to obtain a certificate — which it must, to get a browser to present a padlock — announces itself. A certificate log entry is not an accusation; it is a lead. The follow-up is to check whether the name is yours, and if it is not, whether it is impersonating you.

Names that are in the log but not in your DNS

The third list is the quiet one. A name that appears in the log, appears in no DNS zone you control, and still resolves is pointing at something with a dangling record. That is the exact precondition for subdomain takeover, and unlike the other two lists it is a small, concrete, immediately actionable set. If you monitor only one of the three, monitor this one — and revisit it, because a dangling record can appear long after the certificate was issued.

Reading the Log Yourself in Twenty Minutes

None of this requires a commercial platform. The public endpoints are open, the queries are one line each, and the whole procedure is short enough to run before a decision meeting rather than after it. Seven steps, in order.

1. Enumerate. Query the public log search interface for your apex domain, and separately for any brand terms you use as hostnames. Take the union of both result sets, not the intersection.
2. Deduplicate. Collapse the results to a set of distinct hostnames. The same name will appear many times, once per renewal per log, and the count of appearances is itself a signal: a name with dozens of entries renewed continuously for years is a name something has been actively running on.
3. Resolve. Resolve every distinct name and record the outcome as one of three states: resolves, does not resolve, or resolves with a CNAME pointing at a third-party platform. Keep the third state separate; it is the takeover-candidate list.
4. Compare against your inventory. Set difference, both directions. Names you know but the log does not is usually harmless and means you issue from another authority or another domain. Names the log knows but you do not is the finding.
5. Fingerprint the unknown names. For each, fetch the HTTP response and the certificate subject. Record the server banner, the status code, and the page title. Do not log in to anything; the point of this pass is classification, not testing.
6. Sort by consequence, not by count. A forgotten name that returns a static 404 is noise. A forgotten name that returns an admin interface, a debug endpoint, a file listing, or a database console is not. A forgotten name inside a cookie scope or a CORS allowlist is a production finding wearing a staging hostname.
7. Schedule it. The list is not static in either direction: new names enter it every time someone issues a certificate, and entries never leave it. A monthly sweep catches the plus side. A separate, continuous alert on new log entries for your domains catches the names you did not choose.

The one measurement to carry forward is the size of the difference between the log set and the inventory set. It is a better exposure metric than a count of open ports, because it measures how much of your public surface is unknown to you — and unlike a vulnerability count, it has a floor of zero that is actually reachable.

Where This Turns Into an Infrastructure Decision

Reading the log produces a list. Acting on it produces a different requirement, and this is the part that is genuinely an infrastructure question rather than a monitoring question.

The reason forgotten names are dangerous is not that they exist. It is that they share an address space with production. A staging host that lives on the same flat network as the database, answers on the same domain, and inherits cookies for the apex is a production risk the moment it is forgotten. A staging host that lives on its own isolated network, with its own addressing, shares nothing but a hostname. The second one is an inventory item. The first one is an incident waiting for a trigger.

That is the constraint that makes an isolated, disposable environment necessary rather than convenient: you cannot audit exposure you never separated, and you cannot separate it on a host that is already serving production. Which is the case a programmatically provisioned, network-isolated instance is built for.

SurferCloud's UHost trial plan is one way to get that environment without committing to a permanent footprint: a 3-day or 7-day instance of the same product, with the same console and API as the full service, sized small enough to stand up specifically to resolve this list and then disappear. Three-day access starts at $1.9 for a 2-core, 2 GB instance with 5/10 Mbps and unmetered traffic; the 7-day option at the same size is $3.9. Larger trial sizes run to 8 cores and 16 GB at $14.9 for three days. If you need to model a real staging topology rather than a single host, the network side is what matters more than the CPU: the offer includes full network isolation with self-managed VPC subnets, so a test environment can be given its own address space instead of sharing production's.

Two operational notes, because they affect whether this is the right vehicle for a one-off audit. The trial is limited to one participation per user and one instance per purchase, and it does not support changing regions or availability zones, nor scaling the configuration after the fact — so size it before you order, not after. Instances use data-centre IPs and port 25 is blocked by default. All four trial tiers carry unmetered traffic, and the São Paulo and Dubai nodes come with a 20 GB system disk while other regions default to 40 GB, expandable to 500 GB. Renewing before the trial expires preserves the data; letting it lapse does not.

For an audit like the one described above the point is narrow and worth keeping narrow: you need somewhere to point the staging names that is not production, and you need it to be cheap enough to delete. The promotion details and the current trial tiers are on the 3-day and 7-day UHost trial page.

Where This Fits With the Rest of Your Exposure

Subdomain discovery from the logs is one input to a larger question, and it connects directly to work that has already been written up on this blog.

The first connection is to the exposure window between turning a server on and closing password authentication. That piece is about time: how long a host is reachable before it is hardened. The log-derived name is the same problem in a different dimension, because a forgotten host is one that never entered the hardening window at all — its exposure did not start late, it never ended.

The second is to why ingress filtering does not stop data from leaving. That analysis is about auditing the outbound direction, where most controls have no natural threshold. The forgotten subdomain is where the outbound path usually starts, because it is the host with the oldest code and the least restrictive configuration.

The third is to the difference between a snapshot and a backup. The lesson there is that a recovery copy sharing a failure domain with the original is not a recovery copy. The same reasoning applies to the names on your public surface: a hostname that shares an address space and a cookie scope with production is not isolated just because it is labelled staging.

And the fourth is the economics of abusing a verification endpoint. That piece makes the general point that attackers go where the cost of entry is lowest. A hostname that was published in a public log and then forgotten is close to the floor of that curve.

Frequently Asked Questions

Does a name appear in the log only if a certificate was actually issued? No. A pre-certificate is submitted and logged before the final certificate is signed, and the entry persists even if issuance is abandoned afterwards. Names for which validation failed are in the log.

Can I have an entry removed? No. The logs are append-only by design, and tamper-evidence is the property they exist to provide. There is no takedown process. The entry stays; what changes is only whether the hostname still resolves.

Is this only for publicly trusted certificates? The public logs cover publicly trusted certificates. An internal certificate authority issuing from a private trust root is not required to log, and the name will not appear. So the log tells you about your public surface, which is also the surface an attacker can reach.

Does the log tell me whether the name is still in use? No. It tells you the name was asserted. Whether it resolves, what it serves, and whether anyone still owns it are separate questions answered by separate queries — which is why the procedure above resolves every name before drawing conclusions.

Is a name in the log a vulnerability? Not by itself. The log says a certificate was requested. The finding is the combination of a name you did not know about, still resolving, serving something that was never meant to be public. Two of those three facts are needed.

What is the single highest-value thing to check first? Names in the log that do not appear in any DNS zone you control but still resolve. That intersection is the takeover-candidate set, and it is usually small enough to work through in one sitting.

How often should this be run? A monthly manual sweep for the historical set, plus continuous alerts on newly logged entries for your domains. The historical set changes slowly; the new-entry stream does not.

The Record Is Already Written

The uncomfortable version of this argument is the accurate one: the reconnaissance has already been done, by a process designed to be transparent, and the results are available to anyone who asks. Nothing in this article describes an attack that requires skill. It describes a query, a resolution loop, and a set difference — the same operations the defender can run in an afternoon.

So the asymmetry is not in access to the data. It is in who reads it. A careful operator reads the log once, finds the twelve names they had forgotten, resolves them, and closes the ones that should never have been reachable. The other outcome is that the same list sits published and unread until someone else resolves it with a different intent.

The list is not private and never was. The only question is whether you have read it yet.