What certificate transparency is

Certificate Transparency is a framework, defined in RFC 6962 and updated in RFC 9162, under which publicly trusted certificate authorities submit every certificate they issue to append-only public logs. Browsers require this for certificates to be trusted without warning, which means almost every certificate used on a public HTTPS website is recorded somewhere searchable. Services such as crt.sh provide a free interface to search these logs by domain name.

What a search can reveal

Searching a domain in certificate transparency logs returns every certificate issued for it and its subdomains, including the issuance date, the certificate authority and the exact hostnames covered. This is often the fastest way to discover related hostnames an investigator did not already know about, for example a separate login, payment or staging subdomain prepared ahead of a campaign, because the certificate had to be issued before HTTPS could be enabled on that name.

The earliest certificate issuance date for a name can corroborate or contradict a domain's claimed age: a domain with a registration date years in the past but a first certificate issued only last week suggests the site was dormant or repurposed recently, which is a useful cross-check against RDAP alone.

What it does not show

Certificate transparency only covers certificates actually issued to a name; a domain can exist and resolve without ever having a certificate, for example if it only serves plain HTTP or has never been put into active use. The logs also do not show the content of a website, its hosting location or its current DNS configuration, and a certificate being revoked or expired does not remove it from the historical log. Wildcard certificates can also obscure which specific subdomains are actually in use.

Using the evidence responsibly

Record the exact log entries returned, including issuance and expiry dates and the certificate authority, rather than only a summary. Present related hostnames discovered this way as leads for further checking, such as DNS resolution and content review, not as confirmed evidence of a single campaign.

  • Search both the apex domain and known brand-style prefixes.
  • Record issuance dates, issuing CA and covered hostnames.
  • Cross-check the earliest certificate date against RDAP creation date.
  • Treat newly discovered subdomains as leads requiring further checks.

Sources and further reading

RFC 6962, Certificate TransparencyRFC 9162, Certificate Transparency Version 2.0crt.sh, Certificate transparency search
This resource supports investigative triage. It is not legal advice, an attribution finding or a certification that a website is safe.