Global public logs · Minute-level · Free trial queries

Certificate transparency

Give it a domain and it returns which certificates that domain had issued, by which CA, and when.

Every publicly trusted HTTPS certificate must be written to a public certificate transparency log when it is issued. Which means a domain that wants HTTPS has to leave a public record first — before it actually goes live.

Key-free trial: 10 lookups per IP per day, and signing in does not raise it. This box calls the endpoint in the Access section below. It returns the certificate start time only — there is no expiry, see the Not before row above.

Why it is usually the earliest signal

Phishing sites, look-alike sites and fraud infrastructure almost all need HTTPS (nobody trusts a site the browser refuses to give a padlock). So a certificate being issued is earlier than the domain resolving, earlier than content going up, and earlier than anyone reporting it.

Passive DNS then tells you which machine the domain landed on. CT answers when a certificate was issued, who issued it, and which other domains sit on that same certificate — that last one is the expansion: domains sharing a certificate usually belong to the same operator or the same infrastructure, and the relationship is already in the public log, so nothing is inferred.

What comes back, and what it is not

Responses from this API contain no Chinese. Issuers, domains and statuses come back as standard names or stable codes.

Field	What it means
`data[]`	The certificates. An empty array is an answer, not an error — `"data": []` means no matching records. Invalid input returns 400 and says which parameter was wrong, so automation can branch on status code.
Issuer and certificate fingerprint	Which CA issued it, and the certificate fingerprint. `fingerprint` uniquely identifies this certificate, so you can align, de-duplicate or retain it as evidence in your own systems.
Issuance time	When the certificate became valid (`not_before`). ⚠️ The API returns the start time only, not an expiry time — so there is no "valid until" here, and it cannot be used to decide whether the certificate is still valid today. Deriving an expiry date from CA conventions would introduce errors, so this page gives no such conclusion. For whether a certificate is still in use, go by an actual handshake or your own certificate inventory.
Log time	When we recorded this certificate (`ts`). Use it to tell "just happened" from "been around a while".
`wildcard` / `risk_tld`	Whether this is a wildcard certificate, and whether the domain's TLD is on our high-risk list. Read-only markers carried in the response, so you can filter with your own rules — they are not conclusions.
`has_more` / `next_offset`	Kept for contract consistency with the IP side, which uses the same names. CT returns every matching record for a domain in one response, so there is no pagination: measured `has_more` is always `false` and `next_offset` is always `null`. `count` is simply how many records came back — do not compare it against a total.

Times are UTC, not Beijing time

Every time field is UTC. Add 8 hours yourself before aggregating by day. Getting this wrong yields an empty result on small windows and then looks like the feature is broken.

CT does not cover self-signed certificates or private PKI

Only certificates written to a public CT log are here. Not finding a certificate does not mean the domain has no HTTPS — internally self-signed certificates and those from a corporate private CA never appear. Make that distinction explicit to whoever reads the report.

Where it gets used

Certificate rotation and unusual issuance

A domain that re-issues certificates repeatedly in a short window, or that suddenly uses a CA it has never used before, is worth a look.

Is it on HTTPS at all

No records at all in the public logs means the domain is not using a publicly trusted certificate — it may still be plain HTTP, or only serve a self-signed certificate internally.

Cross-referenced with resolution history

CT tells you when a certificate was issued; passive DNS tells you where the domain pointed at the time. For incident attribution, read both timelines together.

The other domains on the same certificate

Click other domains in any result to see who else that certificate was issued to. A wildcard (*.example.com) and the bare domain often share one certificate — the firmest kind of expansion, because the relationship comes from the public log itself.

Integration

Free trial queries, callable without an account. Response fields, quotas and error formats are in the API documentation; resolution history is at passive DNS.

GEThttps://ip99.com/v1/domain/certs/{domain}

# Call it directly, no key required (anonymous quota)
curl https://ip99.com/v1/domain/certs/example.com

Lower-case the domain, strip the trailing dot, and use punycode for non-ASCII names. You get every record for the domain in the current window, so there is no pagination; a malformed parameter returns 400.

GEThttps://ip99.com/v1/domain/fingerprint/{fingerprint}

# Which other domains share this certificate (fingerprint from the call above)
curl https://ip99.com/v1/domain/fingerprint/85ca6ab068e9bcce88b6c4aa3c47f7d17228134a457f870d3800e6223a0df07a

The fingerprint is a 64-character hex string with no colons. The 3f:8a:1c:… form seen in some documentation is rejected here with 400, so a malformed request never leaves and never costs you a trial lookup. Each entry in data[] is one domain: domain, wildcard, first_seen, last_seen. If there is more than a page, read has_more; the envelope is the same as the certificate endpoint.

Coverage and freshness

Continuous ingestion of public CT logs; new certs within minutes

We ingest from the major public logs continuously. For scale: roughly 6.69 million certificates a day (measured 2026-10-08). Let's Encrypt dominates the issuers, with Sectigo, GoDaddy, Google Trust Services and others also present. A newly issued certificate is usually queryable within minutes.

Counts are certificates, not domains

This is commonly misread: one record in a log is a certificate, not a domain registration. One certificate can cover many domains, and one domain can be re-issued many times — so the counting basis is not the same as "how many domains are there".

⚠️ The corpus is a rolling recent window, not CT's full history

We hold certificates recently written to the logs. So a large brand's apex domain will often return nothing — not because it has no certificate, but because its certificate is long-lived and has not been re-issued inside this window.

Measured on 2026-10-09: apple.com, microsoft.com, amazon.com, cloudflare.com, github.com and baidu.com all return an empty result for the apex, while domains that are re-issued often do have records (google.com has 4, spanning 2026-09-10 to 2026-10-07).

An empty result means "nothing new was issued in this window", not "this domain has never had a certificate". For complete historical issuance, use the official CT log search. Please pass that sentence on to whoever reads your reports — otherwise an empty result gets read as "this domain has no HTTPS".

Subdomain enumeration: not in the trial scope

Enumerating subdomains by suffix is not open yet

This is a capability we have deliberately not opened, not one that is still being built. Pulling every subdomain under a suffix hands over a complete asset graph — for someone doing reconnaissance, it does the work for them.

Please do not wire it into a pipeline. Nothing else described on this page is affected.

Note that this is a different thing from "look up one domain's own certificates": querying a single domain works today; what is not open is "give me every subdomain under this suffix".

The boundary

Content	Public?	Why
One domain's certificate issuance history	Yes	CT logs are public data; we just organise them so they can be queried.
The issuer, time and fingerprint of a certificate	Yes	All of that is already written in the public logs; we just organise it so it can be queried.
Which domains share a given certificate	Yes	The fingerprint and the domains it covers are already written in the public logs — one query returns them. We just organise it so it can be queried.
Pulling newly issued certificates across a time window	Not in the free trial	That is continuous scanning rather than a single query; it needs standing quota and a push channel. Please contact sales.
The specific log names and shard composition behind the data	Never	Source composition is commercial information and is not disclosed to any customer.

A public log only proves a certificate was issued

It does not prove the certificate is still in use right now, and it does not prove the domain is currently malicious. Issuance is a fact about a moment in time; use and intent need other evidence. Treat CT as a source of asset discovery and leads, not as a verdict on a domain's current state.

Contact sales

For bulk certificate sweeps, scanning across a time window, or delivering this data into your own network, tell us the use case and roughly what volume you expect.

Fill in the contact form →