DEV Community

IP99
IP99

Posted on

Certificate Transparency Before the Phish Goes Live: Looking Up Domains on IP99

#security #api #devops #cybersecurity

Phishing and lookalike sites almost always need HTTPS. Browsers will not give them a padlock without a publicly trusted certificate — and every such certificate must be written to a Certificate Transparency (CT) log when it is issued. That means the domain leaves a public record before it resolves, before content goes up, and before anyone reports it.

IP99 (built by ThreatHunter) exposes a free trial CT lookup for that early signal, plus a same-certificate expansion that comes from the public log itself. This post walks through what CT is good for, what it is not, and how to call the endpoints today.

Why CT is usually the earliest signal

CT (RFC 6962 / RFC 9162) is an append-only, publicly auditable log of certificates. Chrome and Apple platforms require new publicly trusted certificates to satisfy CT policy. Operators of the logs include Google, Cloudflare, DigiCert, Sectigo, Let's Encrypt and others.

For fraud and brand protection that has one practical consequence: a lookalike domain that wants HTTPS has to show up in a CT log first. By the time passive DNS sees an A record, or a user hits the page, the certificate row is often already there.

Useful workflows:

  1. Brand / typosquat watch — new certificates whose names contain your brand, a near miss, or punycode (xn--) IDN lookalikes.
  2. Same-certificate expansion — domains that share one certificate usually share an operator or a piece of infrastructure. The relationship is already in the log; you are not inferring it.
  3. Hatching signal — a domain that was just registered and just got a certificate is infrastructure being built, often before abuse starts.

Pair CT with passive DNS when you can: CT answers when a certificate was issued and who else sat on it; pDNS answers which machine the name landed on and who else was on that machine.

Free trial: certificates for a domain

No key for the trial quota (10 lookups per public IP per day; signing in does not raise that particular limit):

curl https://ip99.com/v1/domain/certs/google.com
Enter fullscreen mode Exit fullscreen mode

Live shape (12 Oct 2026). Truncated:

{
  "count": 4,
  "data": [
    {
      "fingerprint": "83a9b0a9a6289449bf116d52df971a83c02b3ff7debf0e4da2ff2f5f0c8bc3e6",
      "issuer_org": "Google Trust Services",
      "log_source": "sectigo-tiger2027h1",
      "not_before": "2026-10-07 12:36:38",
      "risk_tld": false,
      "ts": "2026-10-07 16:05:40",
      "wildcard": false
    }
  ],
  "elapsed_ms": 42.2,
  "has_more": false,
  "offset": 0
}
Enter fullscreen mode Exit fullscreen mode

Field notes:

Field Meaning
fingerprint SHA-256 of the certificate, 64 hex chars, no colons — pass this to the expansion endpoint
issuer_org Who issued it (here Google Trust Services)
log_source Which CT log recorded it (cf-nimbus2026, sectigo-tiger2027h1, …)
not_before Certificate start time. IP99 returns start only — no expiry
ts When IP99 ingested the row
wildcard / risk_tld Wildcard cert flag; high-risk TLD flag

An empty data array is an answer, not an error. Invalid input returns HTTP 400. Responses contain no Chinese text.

Same-certificate expansion

Take a fingerprint from the first call:

curl https://ip99.com/v1/domain/fingerprint/83a9b0a9a6289449bf116d52df971a83c02b3ff7debf0e4da2ff2f5f0c8bc3e6
Enter fullscreen mode Exit fullscreen mode

Live result for that Google Trust Services cert (12 Oct 2026): 65 domains on the same certificate — wildcards and brand properties such as *.google.com, *.cloud.google.com, *.android.com, country TLDs, and related properties. That is the expansion step: one cert, many names, relationship taken from the public log.

On a phishing cluster the same call often surfaces sibling lookalikes that have not hit your blocklist yet.

Honest limits (read these before you automate)

IP99 is clear about the corpus:

  • It is a rolling recent window, not the full CT history. Large brand apexes can return empty (apple.com, microsoft.com and similar were empty in earlier checks; google.com still had a handful of recent rows). For complete history use the official logs or crt.sh.
  • Issuance proves a point in time. It does not prove the cert is still in use, and it does not prove malice.
  • Self-signed and private-PKI certificates never appear.
  • Bulk subdomain enumeration by suffix is deliberately not offered — that would finish the recon work for an attacker.
  • Ingest volume is large (on the order of millions of certificates per day into the corpus); counts are certificates, not unique domains. New certs are usually queryable within minutes of issuance.

Treat CT as an early lead, then enrich with pDNS, hosting, and your own brand rules.

Bonus: free IP risk + geo on the same product

When a CT hit resolves to an address, the free no-key IP endpoint is the next hop:

curl https://ip99.com/v1/ip/8.8.8.8
Enter fullscreen mode Exit fullscreen mode

Live (12 Oct 2026):

{
  "ip": "8.8.8.8",
  "evidence_state": "none",
  "risk": {
    "score": 0,
    "level": "none",
    "signals": ["hosting"]
  },
  "network": {
    "asn": 15169,
    "usage_type": "IDC"
  },
  "geo": {
    "country": "US",
    "region": "California",
    "city": "Mountain View"
  }
}
Enter fullscreen mode Exit fullscreen mode

No signup: 500 requests/day per public IP. A free account raises that to 5,000/day. "hosting" here describes the network type; score 0 with evidence_state: none is not a fraud verdict. For consumer exits, mask real home and mobile addresses in public write-ups and look them up yourself.

Try it

If you are watching brand abuse, start with CT for the earliest public row, expand by fingerprint for siblings, then land on the IP with the free risk profile. That chain is usually enough to decide whether a new name is noise or worth waking someone up.

Top comments (0)