What a certificate log entry proves
A Certificate Transparency entry — an entry in a public, append-only log of issued TLS certificates — proves that a publicly trusted certificate covering a particular hostname was issued by a particular certificate authority and logged at a particular time. Read precisely, it is evidence that somebody demonstrated control of that name to a CA on that date. It does not say who.
That narrow fact is often exactly the fact in issue. Control is what changes in a hijacking. Control is what a respondent claims to have had, and when. Control is what a complainant says was taken. A certificate log gives a dated, independently held, cryptographically structured record bearing on that question, produced by parties with no interest in the dispute, and it is one of the few records in this field that a party cannot quietly edit after the fact.
The related terms: a certificate authority is the organization that issues certificates after checking that an applicant controls the name; domain control validation is that check; and a Subject Alternative Name list is the set of hostnames a single certificate covers.
How Certificate Transparency works
The standard describes CT as a framework for publicly logging TLS server certificates as they are issued or observed, so that anyone can audit certificate authority activity and notice the issuance of suspect certificates (RFC 9162, which supersedes RFC 6962). Each log entry carries a timestamp in milliseconds, a hash binding the issuing CA to the entry, and the encoded certificate data from the submission.
Two structural features matter for evidence. First, a Signed Certificate Timestamp is the log's signed cryptographic promise to append an entry, carrying the log's identity, a timestamp and a signature; the log must fulfill that promise within a defined maximum merge delay. Second, logs are built as binary Merkle trees, in which each node hashes its children, enabling efficient proofs that the log is append-only and preventing retroactive insertion of entries.
Browsers are what make logging near-universal. Chrome requires all publicly trusted TLS certificates issued after April 30, 2018 to support CT in order to be recognized as valid, with a minimum number of timestamps from distinct logs and operators; Apple's policy sets a comparable requirement.
Building the timeline
The working product is a chronology of issuance for the name and its subdomains. For each certificate I record the issuing CA; the notBefore and notAfter dates; the complete Subject Alternative Name list; the serial number; the SHA-256 fingerprint; every signed timestamp with its log identity; and whether the entry is a precertificate (a placeholder logged before the final certificate issues) or the final certificate.
That last distinction is not pedantry. Both entries commonly appear for the same certificate, and counting them as two issuances overstates activity — a mistake that is easy to make and embarrassing to have corrected.
In practice the retrieval happens through a CT monitor: software that watches logs and makes them searchable, publicly listed by the Certificate Transparency project and including services operated by certificate authorities, security vendors and infrastructure providers. The monitor is a convenience layer. The evidence is the log entry, and the report should preserve the entry and its fingerprint rather than a rendering of a search results page.
Where the identity question is actually answered
The log records that validation succeeded. It does not record how, or by whom. The CA holds that: which validation method was used, against which DNS record or which path on the web server, from which requester account, and from which address. Those validation records are the place the identity question is genuinely answered, and they are obtained through legal process rather than lookup.
There is usually a second custodian. Where certificates were issued automatically — by a hosting control panel, a content delivery network, or an automated certificate management client — the account that requested issuance belongs to the hosting or CDN provider rather than to the person who registered the domain. A certificate obtained automatically by a hosting platform on a customer's behalf tells you the platform was in the path, and the platform's account records tell you who the customer was.
The useful framing for a retaining attorney is that CT identifies the CA and the date, precisely and publicly, and thereby identifies exactly whose records to ask for and for which window. That is often its highest practical value.
What certificate records cannot establish
Certificate Transparency is unusually strong evidence of one narrow fact and no evidence at all of the fact people most want from it. A log entry establishes that a certificate covering a name was issued and logged at a time, which means someone satisfied a CA's control check. It does not name that person, and it was never designed to. The standard is explicit that the framework does not itself prevent misissuance; it makes issuance detectable by interested parties.
Coverage before April 30, 2018 is incomplete. Chrome's requirement applies to certificates issued after that date; before it, logging was largely voluntary, with extended validation certificates covered from January 1, 2015. An empty certificate history for 2012 says nothing whatever about whether a site had a certificate.
Four further gaps belong in the report. Certificates that were never publicly trusted — internal authorities, self-signed certificates — never enter the logs at all. Validation data may be reused for a defined period, so control could have been demonstrated meaningfully earlier than the issuance date. A wildcard certificate covering all first-level subdomains conceals which subdomains actually existed. And a shared or CDN-issued certificate can carry many unrelated domains in one name list, creating an apparent association that reflects only a shared provider. Logs also retire, after which continued availability of historical entries depends on the operator rather than on any guarantee.
Certificate logs cut both ways
Because the framework publicly logs certificates as they are issued, every hostname appearing on a logged certificate becomes public information. That includes internal, staging and unreleased subdomains that were never linked from anywhere and never appeared in a search index.
For an investigator this is a source of leads: a certificate issued in 2019 covering a subdomain nobody has thought about since is a dated, public record that the subdomain existed and that someone controlled it. For a party, it is a disclosure surface. Both sides of a dispute are equally exposed, and a party that assumes its unlinked hosts are private is usually mistaken. It is worth knowing which of those two positions a client is in before the analysis begins.
Authenticating certificate records (US federal rules)
What follows describes United States federal rules only; other jurisdictions and US state courts differ, and application is for counsel.
Rule 901(a) requires evidence sufficient to support a finding that an item is what its proponent claims it is (FRE 901). Certificate records sit unusually well with 901(b)(9), evidence describing a process or system showing that it produces an accurate result, because the process description is published in the standard itself and the record carries its own proof structure — inclusion and consistency proofs derived from the log's Merkle tree. A certificate's SHA-256 fingerprint is a distinctive characteristic of the kind contemplated by 901(b)(4).
Rules 902(13) and 902(14) address certified records generated by an electronic process and certified data copied from a file authenticated by digital identification, each requiring a qualified person's certification and Rule 902(11) notice; CA-produced records are ordinarily considered under Rule 803(6). One caution worth stating in any report: the standard itself warns that auditing mechanisms can be circumvented by a misbehaving log presenting inconsistent views to different clients, which is a reason to corroborate an entry across more than one log or monitor.
What this looks like in an expert report
The exhibit is a table of certificates in date order, each row carrying CA, validity dates, full name list, serial, fingerprint and the logs that recorded it, with the preserved certificate file and its hash produced alongside. The narrative describes what the pattern shows: when certificates for the name first appear, when the issuing CA changes, when a name list expands or contracts, and how those dates sit against the registration and DNS timelines.
Every such statement is framed as demonstrated control rather than ownership, and the pre-2018 coverage limitation is stated in the report rather than conceded later. Where the identity of the requester matters, the report identifies the CA and the window and stops there, because that is where the public record stops.