OSINT Jet · Domain evidence

Certificate Transparency OSINT: Turn Certificate Names into a Useful Research List

A certificate search returns hundreds of rows. Some repeat the same name, some contain a wildcard, and some merely resemble the domain you meant to investigate. Before counting “discovered websites,” turn those rows into a list that says exactly what was observed.

What the record actually represents

Certificate Transparency, usually shortened to CT, makes certificate information available in public logs. Logs can contain certificates and precertificates; the latter are part of the issuance process. The CT project’s explanation describes how the system makes these records auditable. It is a record of certificate-related activity, not a directory of working websites.

The Let’s Encrypt documentation confirms that it submits its issued certificates to CT logs. A search service such as crt.sh makes this material easier to look through. The service’s search coverage and availability are separate from the underlying records. A blank result or temporary search error is not proof that a name never appeared.

Your output should distinguish three things: a certificate record, a name written in it, and any separate evidence about that name’s present use. Mixing them produces inflated inventories and weak ownership claims.

Read the name field, then preserve the record

A certificate may carry several names in the Subject Alternative Name extension, commonly called SAN. DNS names are one type of SAN entry; RFC 5280 defines this field. Keep the raw entry, certificate identifier or fingerprint when available, source URL, issuer, displayed validity dates and retrieval time. Do not copy just the first name visible in a result row.

Make one working row per DNS name, linked back to its certificate record. Lowercase the working name for comparison while retaining the original text. Keep wildcard entries visibly marked. If you encounter an unfamiliar internationalized name, preserve both the displayed spelling and its encoded form when available; visual resemblance is a reason to inspect, not a reason to merge.

Separate name deduplication from certificate deduplication. Five distinct certificates mentioning one hostname are five records about one name. Conversely, one certificate listing five names is not five independent confirmations that the same business currently operates them.

Use an exact domain boundary

Suppose the authorized research scope is example.com. For this inventory, a concrete name belongs to that domain when it equals example.com or ends with .example.com. The dot matters: notexample.com does not pass this test. Nor does example.com.other.example.

This is a name-filtering rule, not proof of organizational control. It also assumes you already established the exact domain in scope. Do not guess a company’s registrable domain by taking the last two labels of every address; suffix structures differ. Use the known domain from the brief and keep lookalikes in a separate list only when they are relevant.

Work through six rows without inventing six websites

Synthetic exercise: the following entries are invented for training using example domains. They are not reported results from a live certificate search.

The cleaned list contains two distinct concrete names and one wildcard pattern. It establishes zero currently reachable services because reachability was not tested. That does not mean there are no services; it means this dataset cannot answer that question.

A wildcard is not a hidden list waiting to be expanded. RFC 9525’s matching rules constrain a wildcard to a complete leftmost label and a single label match. A pattern such as *.example.com does not itself enumerate mail, shop or any other real host. Record the pattern you saw instead of generating names and calling them discoveries.

Ask a different source for each remaining question

For present DNS, consult a current public DNS record and record the query type and observation time. For a claimed company relationship, look for independently attributable official material. For an old website’s content, inspect an archived page. These checks answer different questions; none should silently replace the certificate observation.

Even a resolving name may point to shared infrastructure. An expired certificate can remain useful historical evidence without showing current activity. Validity dates describe the certificate’s validity interval, not the service’s launch or shutdown. The separate website history guide covers building a timeline from those different events.

Keep this research passive and within your scope. The appearance of an administrative-sounding hostname is not permission to sign in, scan it or test its security. You can complete a careful certificate inventory without contacting those services at all.

A compact handoff that another researcher can use

Exact domain in scope:
Raw name / normalized name:
Concrete hostname or wildcard pattern:
Certificate record URL / identifier:
Issuer and validity interval as displayed:
Retrieval time:
Separate DNS or official-source observation:
Supported conclusion / unresolved question:

A good handoff might say: “These two names appear in the preserved certificate records. One wildcard pattern is recorded separately. Current operation and company attribution have not been established.” It is modest, but it is usable. A list titled “all company servers” would promise evidence you do not have.

If your next question concerns the business behind a domain, take the cleaned list into the domain investigation workflow. For an OSINT Jet investigation, include the exact domain, relevant records and the decision you need to make. The structured investigation offering is a way to organize related clues for review; do not assume it automatically verifies every CT name or supports a particular certificate-search tool.