crt.sh vs SecurityTrails vs Censys: Three Different Ways to Read Infrastructure

crt.sh, SecurityTrails and Censys often appear in the same domain-recon workflow.

That does not make them interchangeable.

All three can produce infrastructure clues.

But they observe different things:

• crt.sh is centered on publicly logged certificate data;
• SecurityTrails is centered on DNS, domain and historical infrastructure context;
• Censys builds a structured view of internet-facing hosts, web properties, services and certificates from its own internet measurement systems.

The right question is therefore not:

Which infrastructure tool is best?

It is:

Which layer of infrastructure evidence do I need at this point in the investigation?

A strong workflow may use all three.

The important part is understanding what each observation actually represents.

---

The short answer

Use crt.sh first when the problem is:

Which names or certificate relationships have appeared in public Certificate Transparency data?

Use SecurityTrails first when the problem is:

How has this domain's DNS or related domain infrastructure changed over time?

Use Censys first when the problem is:

What broader current internet-facing host, web, service or certificate observations are relevant to this target?

That distinction immediately reduces a large amount of tool confusion.

---

Comparison at a glance

The tools overlap.

The meaning of the underlying observation is what differs.

---

Start by asking which layer you need

Infrastructure research becomes clearer when you separate layers.

Certificate layer

Question:

Which public TLS certificate names or certificate relationships have been logged?

Tool:

crt.sh

DNS history layer

Question:

Which addresses, nameservers, mail systems or TXT configurations were observed for this domain over time?

Tool:

SecurityTrails

Internet measurement layer

Question:

Which internet-facing hosts, services, web properties or certificates does a broad scanning dataset currently describe?

Tool:

Censys

These questions can refer to the same organization and still produce different datasets.

That is expected.

---

crt.sh: start with what Certificate Transparency actually records

Certificate Transparency exists to create publicly auditable records of TLS certificate issuance or observation.

RFC 9162 describes Certificate Transparency as a mechanism for publicly logging TLS server certificates so that certificate-authority activity and suspicious issuance can be audited.

That has an important consequence for OSINT:

certificate logs can expose DNS names that appeared in certificate material.

crt.sh provides a practical certificate-search interface over this ecosystem.

Its official project organization describes crt.sh simply as:

Certificate Search.

That narrow description is useful.

crt.sh should be understood first as a certificate-data search tool, not as a general infrastructure scanner.

---

What crt.sh is good at

Suppose you know:

example.com

Certificate records may expose names such as:

www.example.com
api.example.com
portal.example.com
old.example.com
*.example.com

Those names can generate useful hypotheses.

crt.sh is especially valuable when you need:

• early passive hostname discovery;
• certificate issuer context;
• certificate date ranges;
• Subject Alternative Names;
• historical certificate clues;
• certificate-ID inspection.

It can reveal naming patterns that are no longer visible in current DNS.

That makes it particularly useful near the beginning of a domain investigation.

---

What a crt.sh result actually proves

A precise observation is:

DNS name X appeared in certificate data returned by crt.sh.

Depending on the record, you may also be able to state:

• certificate validity period;
• issuer;
• certificate identifier;
• logged timestamp;
• other certificate names.

Do not silently upgrade that into:

X is a current active asset of the target organization.

The certificate may be:

• expired;
• historical;
• replaced;
• no longer used;
• associated with a service that has been retired.

Certificate evidence is excellent for discovery and history.

Current-state verification requires another layer.

---

Certificate validity and service activity are different

Suppose a certificate was valid from:

2024-01-01

to:

2024-04-01

and contained:

staging.example.com

That can support:

The hostname appeared in publicly logged certificate material associated with that certificate period.

It cannot support:

The staging service is active today.

Always separate:

• certificate state;
• DNS state;
• HTTP/service state.

---

Wildcards create another common mistake

A certificate containing:

*.example.com

does not enumerate every subdomain.

It means the certificate contains a wildcard DNS name according to certificate naming rules.

Do not invent:

admin.example.com
dev.example.com
vpn.example.com

just because a wildcard exists.

Use wildcard evidence as context.

Not as automatic subdomain generation.

---

crt.sh is strongest as a candidate generator

A disciplined crt.sh workflow looks like:

known domain
↓
certificate search
↓
extract relevant names
↓
deduplicate
↓
label as candidates
↓
validate only the candidates relevant to the research question

This is better than:

certificate name
↓
confirmed infrastructure

State transitions matter.

---

SecurityTrails: current and historical DNS context

SecurityTrails operates at a different layer.

Its current API documentation describes access to:

• IP information;
• DNS information;
• WHOIS information;
• company-related data.

Its DNS history endpoint supports historical records including:

• A;
• AAAA;
• MX;
• NS;
• SOA;
• TXT.

That makes SecurityTrails particularly useful when change over time matters.

---

What SecurityTrails is good at

SecurityTrails becomes useful when your question is no longer only:

What names appeared in certificates?

and becomes:

How did this domain's technical configuration change?

Examples:

• Which A records were previously observed?
• Did the domain change nameservers?
• Did mail infrastructure change?
• Did TXT records change?
• Was a hostname previously pointed somewhere else?
• Does a historical provider transition corroborate a migration hypothesis?

This is a timeline-oriented use case.

---

Historical DNS is powerful because it preserves old states

Current DNS can tell you:

what resolves now.

Historical DNS can tell you:

what was observed before.

That distinction is crucial during:

• hosting migrations;
• rebrands;
• mail-provider changes;
• CDN adoption;
• infrastructure consolidation;
• incident reconstruction.

Suppose:

2024 → IP A
2025 → IP B
2026 → CDN address

That sequence is much more informative than a flat list:

IP A
IP B
CDN address

Time gives the observations meaning.

---

Historical does not mean current

This is the biggest SecurityTrails interpretation error.

A historical DNS record may be completely valid for an older period and completely irrelevant to the current service.

Do not write:

The site's origin IP is X.

when your actual evidence is:

SecurityTrails recorded X as an A record during a historical period.

Historical records should be labelled:

historical

until current evidence supports a present-state relationship.

---

Historical IP does not automatically mean hidden origin

SecurityTrails documentation gives examples of using DNS history to find where a domain previously pointed, including in contexts involving proxy services.

That can be useful.

But be careful with the interpretation.

A historical IP may have been:

• previous hosting;
• shared hosting;
• a temporary service;
• a legitimate old origin;
• unrelated to the current deployment.

Finding a previous IP is not automatically equivalent to:

bypass the current CDN.

OSINT analysis should remain focused on the research question.

---

SecurityTrails can be broader than DNS history

The API is not only a historical-record service.

SecurityTrails also provides other domain, IP, WHOIS and search functions.

So the simplistic comparison:

SecurityTrails = old DNS

would be incomplete.

The better statement is:

historical DNS is one of SecurityTrails' most distinctive roles inside an infrastructure-research workflow.

That is why it often complements crt.sh and Censys particularly well.

---

Censys: a structured map of the public internet

Censys operates from a broader internet-measurement perspective.

Its current Platform documentation describes datasets for:

• hosts;
• web properties;
• certificates.

Censys says it scans the public internet to discover reachable IPs, services, certificates and other internet-facing assets, then structures those observations for search and correlation.

This means a Censys host record belongs to a different evidence family than:

• a certificate log entry;
• a historical DNS record.

It is an observation produced by a broad internet scanning and enrichment system.

---

What Censys hosts tell you

The current host dataset is organized around internet-facing IPv4 and IPv6 hosts.

Host records can contain information about exposed services such as:

• ports;
• protocols;
• software;
• DNS names;
• certificates;
• other structured service context.

This makes Censys useful when your question expands to:

What does this internet-facing host expose according to Censys' current dataset?

That is significantly broader than certificate discovery.

---

What Censys web properties add

Censys also models web properties.

Its documentation describes web properties as web-facing assets identified by:

• hostname;
• port.

They can contain HTTP-oriented observations and endpoint information.

This can help when your investigation is about:

• application behavior;
• exposed web endpoints;
• reused content;
• hostname/port combinations;
• relationships between web-facing assets.

Again, this is not the same thing as historical DNS.

---

Censys also contains certificate data

Censys has its own certificate dataset.

Its Platform documentation describes a very large X.509 certificate collection that grows as certificates are identified on the public internet.

This creates overlap with crt.sh.

But the analytical orientation is different.

crt.sh is a focused certificate-search interface strongly associated with Certificate Transparency.

Censys certificates are integrated into a wider asset model where certificates can relate to:

• hosts;
• web properties;
• services.

So the same certificate can serve different investigative purposes in the two tools.

---

"Current" Censys data is not instantaneous truth

Censys refers to its host dataset as current records of internet-facing hosts.

That should not be interpreted as:

I personally measured this service one second ago.

The observation comes from Censys' measurement and indexing system.

Infrastructure can change between scans.

Hosts can:

• go offline;
• close ports;
• move;
• change certificates;
• rotate services.

Write:

Censys currently records service X on host Y.

rather than:

Service X is definitely live right now.

If the exact present state matters, collect appropriate current evidence separately and within authorization.

---

Data availability can depend on plan and product

Current Censys documentation explicitly notes that access to datasets, actions and API endpoints depends on the user's plan.

For example, free API users have more limited lookup functionality than higher tiers.

This matters when documenting reproducibility.

Two analysts using different plans may not have identical search capabilities.

Record:

• tool;
• product tier when relevant;
• query;
• retrieval time.

Do not assume every reader can reproduce the same UI/API query with a free account.

---

Three tools, three different time models

A particularly useful way to compare the tools is by time.

crt.sh

Certificate-oriented historical evidence.

A certificate record has dates and log history.

SecurityTrails

Historical and current domain/DNS context.

Especially useful for transitions across periods.

Censys

A current structured internet-measurement view, supplemented by whatever historical or related features are available for the chosen product.

This means a layered timeline can look like:

2024 — crt.sh certificate name appears
2024 — SecurityTrails historical A record points to IP A
2025 — SecurityTrails records nameserver change
2026 — Censys current host record shows service B
2026 — live DNS resolves through provider C

No single tool gives the complete timeline.

---

Three tools, three different discovery models

crt.sh discovery

Starts from certificate identities and names.

Good for:

• certificate-linked hostname candidates.

SecurityTrails discovery

Starts from domain/DNS relationships and historical observations.

Good for:

• infrastructure change and DNS pivots.

Censys discovery

Starts from internet-facing asset observations and structured search.

Good for:

• wider service/host/web-property context.

The discovery model should match the question.

---

When crt.sh should come first

Choose crt.sh first when:

• you know a domain;
• you want certificate-linked names;
• you want a passive, focused expansion;
• certificate dates matter;
• you want an early candidate list before broader research.

Example question:

Which hostnames have appeared in public certificate data for this domain?

crt.sh is an excellent fit.

---

When SecurityTrails should come first

Choose SecurityTrails first when:

• DNS history is the question;
• provider change matters;
• old mail infrastructure matters;
• historical nameservers matter;
• you already have a hostname and need its timeline.

Example:

When did this hostname stop pointing to its old hosting provider?

Historical DNS is closer to the question than certificate search.

---

When Censys should come first

Choose Censys first when:

• you have a known IP or web property;
• the question concerns internet-facing services;
• broader exposure context is necessary;
• you need structured host/service search;
• certificate-to-host relationships matter.

Example:

What services does Censys currently record on this known public host?

That is a Censys-style question.

---

Do not always follow the same tool order

A generic playbook might say:

crt.sh → SecurityTrails → Censys

That is often useful.

It should not become ritual.

Suppose the investigation starts from:

known IP address

Then crt.sh may not be the natural first tool.

Suppose the question is:

When did MX change?

Start with SecurityTrails.

Suppose the question is:

Which names appeared in certificates?

Start with crt.sh.

Methods should follow uncertainty.

Not memorized tool sequences.

---

Worked example 1 — hostname discovered in a certificate

You search crt.sh for:

example.com

and find:

legacy-api.example.com

crt.sh observation

legacy-api.example.com appeared in certificate data.

State:

candidate

Do not call it current yet.

SecurityTrails

Historical DNS shows:

2024 → IP A
2025 → IP B

and no recent record in the period you review.

Now you can say:

Historical DNS records support past use of the hostname.

Censys

Current search produces no relevant host/web observation for the name.

Do not write:

The hostname no longer exists.

The correct conclusion is narrower:

Certificate and historical DNS evidence support past use, while no relevant current Censys observation was found under the search conditions used.

That preserves the scope of each source.

---

Worked example 2 — migration to a CDN

Research question:

Did this site move behind a managed edge provider?

SecurityTrails

Historical A records show:

old direct hosting IP
→ later edge-network addresses

This creates a migration hypothesis.

crt.sh

Certificate history shows additional legacy hostnames during the earlier period.

Useful for reconstructing old naming patterns.

Censys

Current data describes the public internet-facing layer and certificates associated with the current host/web property.

Conclusion

A calibrated statement might be:

Historical DNS, certificate history and current internet-facing observations are consistent with a migration from the earlier hosting configuration to the current edge-delivered public service.

That is stronger than any one dataset alone.

---

Worked example 3 — current known IP

You have:

203.0.113.10

from a current authoritative source and want public service context.

Censys is likely the best of these three to start.

It may expose:

• services;
• ports;
• software-related observations;
• certificates;
• DNS names.

If one certificate contains:

example.com

you can then move into certificate and domain history.

The order becomes:

Censys
→ certificate/domain clue
→ crt.sh / SecurityTrails

The workflow follows the evidence.

---

Worked example 4 — stale historical IP

SecurityTrails shows:

example.com → 203.0.113.10

in 2022.

Censys today shows unrelated services on:

203.0.113.10

Do not connect the current services to the company automatically.

IP reuse happens.

The historical DNS relationship belongs to 2022.

The Censys observation belongs to the present dataset.

A responsible finding is:

The domain was historically observed at IP X; current observations of X represent a later state and should not be attributed to the historical domain without additional evidence.

---

Current and historical data should never share an unlabeled column

Avoid a spreadsheet like:

asset
example.com
api.example.com
203.0.113.10
old.example.com

Instead preserve:

value
type
source
observed_period
state
evidence

Example:

This structure prevents accidental temporal collapse.

---

Coverage is not completeness

None of these sources should be treated as omniscient.

crt.sh reflects certificate data available through its certificate-search model.

SecurityTrails reflects the DNS/domain data it has collected and made available.

Censys reflects its own internet measurement and indexed datasets.

Missing data can have several meanings:

• source never observed it;
• source does not expose it;
• plan limits access;
• data aged out;
• service was not reachable;
• query was too narrow;
• asset changed;
• record did not exist.

A zero-result search is not proof of nonexistence.

---

Source independence matters

Suppose:

• crt.sh shows a certificate;
• Censys certificate search shows the same certificate.

That is useful corroboration that two systems expose the certificate.

But the underlying certificate may still ultimately derive from the same public issuance/logging event.

Independent evidence layers are stronger than repeated representations of one artifact.

For example:

certificate record
+ historical DNS
+ current host observation
+ current live HTTP behavior

is more informative than four certificate-search interfaces returning the same SAN.

---

Asset ownership remains a separate question

This is the major analytical warning for all three platforms.

A result can show:

• hostname;
• IP;
• service;
• certificate;
• DNS record.

It does not automatically prove:

• legal ownership;
• operational control;
• corporate affiliation.

Examples of low-specificity relationships include:

• same CDN IP;
• same nameserver provider;
• same certificate authority;
• same cloud ASN.

Do not build company-ownership conclusions from generic infrastructure overlap.

---

Censys breadth can create premature expansion

Censys is powerful precisely because it is broad.

That breadth can be a weakness when the research question is immature.

Starting from one hostname, you may quickly see:

• related IPs;
• services;
• certificates;
• web properties;
• DNS names.

Every new object can become another pivot.

Set a rule:

expand only when the new object can answer or materially refine the research question.

Do not turn a question about one domain migration into an unrestricted internet asset hunt.

---

SecurityTrails history can create "origin hunting" bias

Historical DNS often reveals older IP addresses.

This can tempt analysts to search for a supposedly "real" host behind a current CDN or proxy.

That may be irrelevant, stale or operationally sensitive.

Ask first:

Does identifying the historical infrastructure actually help answer the research question?

If the question is:

When did the migration occur?

historical DNS is relevant.

If the question has already been answered, further expansion may not be necessary.

---

crt.sh naming clues can create enumeration bias

Certificate hostnames often contain interesting labels:

admin
dev
staging
internal
vpn

The label is not permission to investigate the host.

The safest workflow is:

1. record the certificate observation;
2. ask whether the hostname matters to the research question;
3. use passive/current verification only when justified;
4. stop if the candidate is irrelevant.

Interesting names are not automatically important evidence.

---

A practical decision matrix

This matrix describes first-tool fit.

It does not mean the other tools become irrelevant afterward.

---

Best layered workflows

Workflow A — domain migration

current DNS
→ SecurityTrails history
→ crt.sh certificate history
→ current HTTP
→ Censys current host/web context
→ timeline

Workflow B — unknown certificate hostname

crt.sh
→ candidate hostname
→ current DNS
→ SecurityTrails history
→ Censys if broader service context is relevant

Workflow C — known current IP

Censys
→ DNS/certificate clues
→ SecurityTrails for domain history
→ crt.sh for certificate history

No fixed order works for every investigation.

---

Common mistakes

Mistake 1 — Calling all three "subdomain tools"

They observe different data layers.

Mistake 2 — Treating crt.sh names as current assets

Certificate history is not current service validation.

Mistake 3 — Treating SecurityTrails historical IPs as current origins

Historical state needs time labels.

Mistake 4 — Treating Censys as a live scanner you personally just ran

Its records come from Censys' collection/indexing system.

Mistake 5 — Treating no result as nonexistence

Coverage and access differ.

Mistake 6 — Treating repeated certificate data as independent corroboration

The same underlying certificate can appear in several systems.

Mistake 7 — Treating shared provider infrastructure as ownership linkage

CDNs and cloud infrastructure are highly shared.

Mistake 8 — Expanding because the tool makes expansion easy

Breadth must serve the question.

Mistake 9 — Mixing historical and current observations

Always preserve time/state.

Mistake 10 — Ignoring plan/access differences

Reproducibility can depend on product tier.

---

A repeatable three-tool workflow

If you genuinely need all three:

1. Define the question

Example:

How did this domain's public infrastructure change between 2024 and 2026?

2. Establish current DNS independently

Do not make historical tools your only current-state source.

3. Search crt.sh

Capture:

• relevant names;
• certificate dates;
• issuer context;
• certificate IDs.

Label names as candidates/historical observations.

4. Query SecurityTrails

Capture relevant:

• A/AAAA history;
• MX;
• NS;
• TXT;
• periods.

Build a DNS timeline.

5. Query Censys

Use the current known:

• hostname;
• IP;
• certificate;

to obtain broader current asset/service/web-property context where relevant.

6. Normalize states

Use labels:

certificate_observed
historical_dns
current_dns
censys_observed
candidate
verified
rejected

7. Corroborate

Use live HTTP, archives or other independent layers when the conclusion requires them.

8. Stop

Do not pivot further merely because another related asset exists.

---

Related OSINT.dev tools

crt.sh

Best for:

• Certificate Transparency search;
• certificate-linked hostname candidates;
• certificate history.

SecurityTrails

Best for:

• DNS/domain context;
• historical DNS;
• infrastructure change over time.

Censys

Best for:

• structured current internet-facing hosts;
• services;
• web properties;
• certificates;
• broader exposure context.

A Practical Method for Domain and Infrastructure Recon

Use the broader OSINT.dev workflow guide when you need to combine these tools with:

• current DNS;
• redirects;
• technology fingerprinting;
• Wayback Machine;
• urlscan.io;
• evidence states;
• timeline construction.

This comparison answers:

which of these three infrastructure datasets fits the current question?

The recon guide answers:

how do all the layers fit into one defensible investigation?

---

The core principle

crt.sh, SecurityTrails and Censys are not three competing views of one universal asset inventory.

They answer different questions:

crt.sh — what certificate-related names and records have been publicly logged?

SecurityTrails — how has DNS/domain infrastructure been observed over time?

Censys — what internet-facing hosts, web properties, services and certificates does its measurement platform currently describe?

A strong investigation keeps those observation types separate.

Then it joins them through:

• identifiers;
• time;
• provenance;
• relevance;
• corroboration.

The best tool is the one that answers the next unresolved question without expanding the investigation further than necessary.

---

References

Primary standards and official product documentation used in this comparison:

• RFC 9162 — Certificate Transparency Version 2.0
  https://www.rfc-editor.org/rfc/rfc9162.html

• crt.sh — Official project organization
  https://github.com/crtsh

• SecurityTrails — API Overview
  https://docs.securitytrails.com/docs/overview

• SecurityTrails — DNS History by Record Type
  https://docs.securitytrails.com/reference/dns-history-by-record-type-old-1

• SecurityTrails — API Examples
  https://docs.securitytrails.com/docs/examples

• Censys — Platform Quick Start Guide
  https://docs.censys.com/docs/platform-quickstart-guide

• Censys — Platform Data
  https://docs.censys.com/docs/platform-datasets

• Censys — Platform API
  https://docs.censys.com/reference/get-started