Certificate Transparency: A Practical Guide for Defenders

In early October 2026, Google's Chrome team published a short post that every domain owner should read twice. Attackers had compromised three country-code top-level domains, .gh (Ghana), .sl (Sierra Leone) and .as (American Samoa), changed authoritative DNS records, and used that control to obtain real HTTPS certificates for several Google domains and for domains belonging to other organizations. Google says it has no reason to believe the certificate authorities that issued them did anything wrong. The DNS said the attackers controlled the names, so the CAs issued.

Certificate transparency is what widened the response beyond Google. Google does not say how it first spotted the certificates for its own domains. It says that after Chrome blocked those, CT log data revealed additional organizations believed to have been impacted by the same attacks, including "several leading global brands and widely used online services."

Certificate transparency (CT) is a public, append-only record of TLS certificates. Before Chrome, Safari or desktop Firefox will trust a certificate from a public certificate authority, the certificate must come with proof, in the form of signed timestamps, that it was submitted to independent CT logs. That means anyone can look up the publicly trusted certificates issued for any domain. CT does not stop a bad certificate from being issued. It makes sure the issuance cannot stay secret.

This guide is for defenders and threat intelligence analysts. It covers how CT works in plain terms, how to set up monitoring for your own domains, how to use CT to catch lookalike and phishing domains early and to pivot on actor infrastructure, and the limits that trip people up. The tool notes reflect what I checked on 16 October 2026, because several well-known CT tools have changed or gone quiet in the last year.

Why Certificate Transparency Exists

The web's trust model has a structural weakness: any publicly trusted CA can issue a certificate for any domain. For most of the web's history, nobody except the CA knew what it had issued.

That weakness became a crisis in July 2011, when an attacker compromised DigiNotar, a Dutch CA, and issued rogue certificates for numerous domains. More than 500 fake certificates were eventually found, according to the CT project's own history, and they were used to intercept traffic from Iran. Engineers at Google answered with a public ledger. Google launched the first CT logs in March 2013, and the IETF published the protocol as RFC 6962 in June 2013. A version 2.0, RFC 9162, followed in December 2021, but the browser rules in force today are still written around RFC 6962 logs and a newer static API covered below.

The first big payoff came in 2015. After a misissued google.com certificate surfaced, Symantec disclosed 23 test certificates issued without the domain owners' knowledge. Google then found more questionable certificates "using only the Certificate Transparency logs and a few minutes of work," and Symantec's second audit turned up 164 more certificates over 76 domains, plus 2,458 certificates for domains that were never registered. The CT project's timeline records that CT exposed thousands more misissued Symantec certificates in 2017 and that all major platforms eventually distrusted Symantec.

Browsers then made logging mandatory. Chrome 68 began enforcing CT for all TLS server certificates issued after April 30, 2018. Apple's policy requires CT for certificates to be trusted on its platforms, and Mozilla's wiki records that Firefox enforces CT by default on desktop from version 135. A publicly trusted certificate that was never logged now simply fails in the browsers most people use.

How Certificate Transparency Works

You do not need the cryptography to use CT well, but you do need the moving parts, because each one explains a quirk you will see in the data.

Figure 1: The issuance path (grey) ends at the browser, which only checks that a certificate was logged. Deciding whether the certificate should exist happens on the monitoring path (blue), which is the domain owner's job. Diagram: CTI Academy, based on RFC 6962, certificate.transparency.dev and the Chrome CT Policy.

Here is the sequence, following the CT project's explainer:

1. The CA validates domain control and builds a precertificate. It holds everything the final certificate will hold, plus a "poison" extension so no browser will accept it as a real certificate.
2. The CA submits the precertificate to several logs. Each log answers with a signed certificate timestamp (SCT), a signed promise to add the entry within the log's maximum merge delay. The project calls 24 hours usual; in Chrome's 15 October log list, the classic logs declare 24 hours and the static-ct-api logs 60 seconds.
3. The CA embeds the SCTs in the real certificate and issues it.
4. The browser checks the SCTs during the TLS handshake. Under the Chrome CT Policy, a certificate valid for 180 days or less needs embedded SCTs from at least two distinct logs, a longer one needs three, and at least two of the SCTs must come from different log operators. Apple's policy uses the same counts but still requires at least one SCT from an RFC 6962 log.
5. Monitors read every new log entry and match it against watch lists. Because logs are Merkle trees, a log cannot quietly delete or rewrite an entry without monitors being able to prove it.

The important point is what the browser does not check. It never asks whether the certificate was wanted, only whether it was published. If you take one idea from this article, take that one.

Reading a Certificate Transparency Search Result

Here is what this looks like in practice. I searched crt.sh, the free CT search engine launched in 2015 and now run by Sectigo, for example.com, the domain reserved for documentation.

Figure 2: A crt.sh identity search for example.com. The first two rows share one serial number: they are the precertificate and the final certificate of the same certificate, logged as separate entries. On 29 July the same issuing CA family produced both ECC and RSA certificates, each again appearing twice. Every certificate covers *.example.com, so no individual subdomain is visible, and validity runs about 90 days. The Common Name column was hidden to fit the column width. Source: crt.sh, captured 16 October 2026.

Three habits come out of that one screen. Expect duplicates, because precertificates and final certificates are separate log entries. Expect several certificates per renewal, because many providers issue ECC and RSA versions side by side. And notice the wildcard, because it hides hostnames, which matters later. Clicking into the first certificate shows its two embedded SCTs, one from a DigiCert log and one from Cloudflare's Nimbus log: two operators, exactly what Chrome's policy demands for a 90-day certificate.

How CT Logs Are Changing

As of 15 October 2026, Chrome's log list contained 43 usable logs run by eight operators: Cloudflare, DigiCert, Geomys, Google, IPng Networks, Let's Encrypt, Sectigo and TrustAsia. Twenty-two of them use the newer static CT API, often called tiled logs, which serve log data as plain files that, as Let's Encrypt explains, can be cached by a CDN.

The shift has practical consequences for anyone running their own tooling. Let's Encrypt announced that its classic RFC 6962 logs would go read-only on November 30, 2025 and shut down on February 28, 2026. And Chrome announced that as of April 15, 2026, TLS connections may use SCTs exclusively from static-ct-api logs, a change its current policy page reflects. So a certificate can now satisfy Chrome while appearing only in tiled logs (Apple's published policy still requires one RFC 6962 SCT, so a certificate meant to work on Apple devices cannot rely on tiled logs alone). A home-grown monitor that polls classic logs alone will miss it. Before you trust any CT tool, check that it reads both kinds.

What the ccTLD Hijacks Teach About CT

Go back to the October case, because it shows exactly where CT sits in the defense chain.

Figure 3: Google's post names the three affected ccTLDs, says the attackers modified authoritative DNS records, says Google has no reason to believe the issuing CAs did anything wrong, and says that after its initial mitigation CT log data revealed additional organizations believed to have been impacted. Source: Google, "Chrome's Response to Recent ccTLD Registry Hijacks", 6 October 2026, captured 16 October 2026.

Four lessons stand out.

Domain validation trusts DNS. If an attacker controls the authoritative DNS for a name, they can pass a CA's domain control check. Nothing in the issuance chain failed. CT was the control that made the issuance visible to anyone outside the CAs.

CT widened the response. Google first blocked the certificates for its own properties. Then, following that initial mitigation, CT log data "revealed additional organizations" believed to have been impacted by the same attacks, and Google blocked those certificates too. Google does not say how it searched the logs. Our reading is that this second step is a pivot, the same technique this guide teaches below.

Browsers are not your safety net. Google is blunt: it "cannot guarantee that our analysis identified every affected domain," and Chrome's interventions do not reliably protect users of other browsers. Revocation by the CAs covers some of that gap, but you cannot outsource the job of noticing.

Google asks owners to do two things. Monitor CT for every domain you own, "including parked or regional ccTLD properties," and publish restrictive CAA records with ACME account bindings. A CAA record (RFC 8659) lists which CAs may issue for your domain, and the RFC 8657 extensions let you restrict issuance to a specific ACME account (accounturi) and validation method (validationmethods). Google is clear that CAA cannot stop issuance during an active DNS hijack, since the attacker controls DNS. Its value comes afterwards: CAs may reuse a completed domain validation for later certificates, and a restored, restrictive CAA policy stops an attacker from minting new certificates on that cached validation.

Google's longer-term answer is to shrink certificate lifetimes and validation reuse. That schedule is already written into the CA/Browser Forum's rules.

Figure 4: Maximum certificate validity and maximum reuse of domain validation data, by issuance date. The 200-day limit applies today; from 15 March 2029 certificates are capped at 47 days and validation data at 10 days. Shorter reuse narrows the window in which a validation captured during a hijack stays usable; shorter lifetimes also mean more renewals, so more entries in the logs. Diagram: CTI Academy, data from the CA/Browser Forum Baseline Requirements v2.3.1 (ballot SC-081v3).

For CT users the schedule cuts both ways. A validation obtained during a DNS hijack goes stale faster. But every certificate gets renewed more often, so the logs fill faster and your alert volume rises. Plan the triage now, before the 100-day rule lands in March 2027.

How to Monitor Certificate Transparency for Your Own Domains

Owner-side monitoring answers one narrow question: has a certificate been issued for a name I own that I did not ask for? Here is the setup I would build for a small team.

1. Inventory every domain you hold. Include parked domains, regional ccTLDs, campaign microsites and anything inherited in an acquisition. This is the same discovery work described in our attack surface management guide, and CT is one of its best sources, because your own certificates reveal hostnames people forgot. That inventory is also the exposure input to vulnerability prioritization: you cannot rank a flaw on a host you do not know you run.

2. Write down who is allowed to issue. List the CAs and the services that legitimately obtain certificates for you: your CDN, your email marketing platform, the SaaS help desk on support. and so on. That list becomes your CAA record and your alert baseline. A certificate from anyone else is an alert.

3. Pick a monitor. These are the options I would consider, with what I could verify on 16 October 2026:

A few notes behind that table. Cert Spotter's open-source edition watches both classic and static-ct-api logs, and its watch list syntax is simple: a leading dot, as in .example.com, covers the domain and every subdomain. SSLMate's hosted version starts at $15 a month for 20 endpoints with a 30-day trial. Cloudflare's feature filters out certificates Cloudflare issues for you, so every alert it sends deserves a look. Censys said in February that its Legacy Search would be deprecated in September 2026, so older tutorials written for Legacy Search are out of date.

Two tools I would not build a program on today. Meta's free CT monitoring tool, launched in December 2016 according to the CT project's timeline, returned "page not found" for both its tool page and its documentation when I checked logged out on 16 October 2026, so it may have moved or been retired. And Calidog's public CertStream feed, the firehose many phishing-hunting scripts were written against, accepted my websocket connection that day but delivered no certificates in 25 seconds, or in a 40-second re-test later that morning, on a feed designed to stream every new certificate. If you want a stream, run certstream-server-go yourself; it describes itself as a drop-in replacement for Calidog's server. It added static-ct log support in version 1.9.0 in April 2026, when its maintainer wrote that the feature had not been tested as thoroughly as they wished, and version 1.10.0 in September 2026 fixed static CT tile-fetching bugs.

4. Triage alerts the same way every time. Cloudflare's documentation gives a good three-point check: is it your domain, did you or a service you use request it (check the issuer), and do the DNS names and validity dates look reasonable? Most alerts are routine renewals by a vendor someone forgot to tell you about. Fix the baseline when that happens, so the next alert means something.

5. Know what to do with a bad one. Only the issuing CA can revoke a certificate, so contact it first. crt.sh links each certificate to a "report a problem" route for its CA. Then work the cause: check your registrar account, your DNS provider's audit log and your nameserver records, because an unauthorized certificate usually means someone could change your DNS or answer a validation challenge. Once you have control back, restore a CAA record bound to your own ACME account, for the reason Google gave.

One more owner-side effect: CT works against you too. A 2023 study by researchers at UC Santa Barbara, TU Delft and the Max Planck Institute for Informatics, presented at IEEE EuroS&P, found that adding a certificate to a CT log leads to incoming network probes "just seconds after publishing the entry". Their IPv6 honeypot received 2,700 packets after its certificate was logged, against zero in the control group. Every hostname you put in a public certificate is announced to scanners. Keep internal names out of publicly trusted certificates and use a private CA for them.

Finding Lookalike and Phishing Domains in CT Logs

Owner-side monitors do not catch lookalikes. Cloudflare says so directly: for cloudflare.com, "an alert would not trigger if a certificate was issued for cloudf1are.com or cloud-flare.com." Catching impersonation needs a different watch, one that matches your brand string anywhere in a name.

Speed is the reason to bother. In a September 2026 report on passkey-themed social engineering, Microsoft Threat Intelligence described actors who register generic domains and embed the target organization's name as a subdomain, in the pattern contoso[.]add-passkey[.]com. Those domains were "operational within hours, giving defenders little opportunity to identify and block the infrastructure before employees encounter it." Microsoft assesses that this initial access activity is used by several actors, including Storm-3121, whose access leads to ShinyHunters and Falcon extortion. When the window is hours, a log entry that appears when the certificate is issued is one of the few early signals you get.

What I put in a brand watch list:

• The brand string in any position: as a subdomain label, inside a longer word, before or after a hyphen.
• Common typos, swapped or doubled letters, and digit swaps like 0 for o and 1 for l.
• Punycode (xn--) names, decoded and compared for characters that look like your brand.
• Your brand next to identity words: sso, login, passkey, okta, helpdesk, vpn, payroll.

For ad hoc hunting, crt.sh accepts % as a wildcard, so a search like %contoso% returns logged certificates with that string in a name. Big brands hit its limits fast: a %keyword% search for a major payment brand, restricted to unexpired certificates, came back with the warning "Sorry, your search results have been truncated." For continuous coverage you need a stream or a commercial brand protection service that matches every new entry as it arrives.

Treat every hit as a lead, not a verdict. Before you file a takedown, check registration data, current DNS, hosting, and the page itself in a sandbox or a scanning service. Expect false positives from your own agencies and partners, resellers, fan sites and security vendors. A certificate proves that someone controlled the name at issuance time. It does not prove intent.

There is also a structural blind spot here. If the actor in Microsoft's example buys one wildcard certificate for the base domain, the per-victim subdomains never appear in any log. Your brand string then shows up only in the URL that reaches your users, which is why CT watching complements, and never replaces, email and web telemetry.

Pivoting on Actor Infrastructure With Certificates

The ccTLD case showed the analyst's use of CT: after Google blocked the certificates for its own properties, CT log data revealed other organizations believed to have been hit. Google does not describe its queries, but the move we read into it, starting from known-bad certificates and searching the logs for more, works on attacker infrastructure too. You start from one seed, usually a phishing URL or a hostname from a report, and walk outward through certificate data.

Figure 5: Three pivots from one seed. The SAN sibling and, on a dedicated server, a certificate seen on the same IP are strong links; a name that only matches the naming pattern stays an unconfirmed lead until a second pivot connects it. All names are fictional (reserved .test names and the 192.0.2.0/24 documentation range); the naming pattern follows Microsoft's September 2026 report. Diagram: CTI Academy.

The pivots I use most, roughly from strongest to weakest:

• SAN siblings. Look up the seed's certificate and read every name in its Subject Alternative Name list. A CA must validate control of each name before issuing, which is why Infoblox's research team argues that "domains appearing together in SAN fields often indicate shared operational control." Infoblox also gives the caveat: CDNs and domain resellers put unrelated customers on one certificate, so check who issued it and how many names it carries.
• Shared hosting seen in scans. Resolve the seed, then ask a scan dataset what else that IP presents. Censys documents that its certificate data comes from syncing CT logs and from certificates observed in TLS handshakes during its internet scans. A shared IP is strong evidence on a dedicated server and close to meaningless on shared hosting or a CDN edge, so check what else lives there. The scan source matters because self-signed certificates, which many command-and-control servers present, never appear in CT at all. Our C2 explainer covers that infrastructure in more depth.
• Naming patterns. Search CT for the actor's habits: a theme word (passkey, sso), a structure (victim.theme-word.tld), a favored registrar or TLD. This finds new domains fast, and it also finds lookalikes registered by somebody else entirely.
• Issuance timing. Certificates issued minutes apart, from the same CA, with the same validity period, suggest one operator working through a list. Timing supports other links. It rarely stands alone, because the logs carry a constant flow of unrelated certificates.

Whatever you find, record why each link exists and how strong it is. A shared issuer like Let's Encrypt means nothing on its own. A shared certificate on a non-CDN host means a lot. If the graph ends up in a report, say which links are confirmed and which are leads (more on expressing that in our threat intelligence report writing guide). CT is one of many free sources an OSINT analyst should know; our OSINT guide puts it alongside the rest.

What Certificate Transparency Cannot Tell You

CT is excellent at one thing and silent about many others. These are the limits I see people forget:

• It records issuance, not use. A logged certificate does not mean a site went live, served phishing or was ever visited.
• It starts at issuance, not registration. A domain can be registered and left untouched for months before anyone requests a certificate. Newly registered domain feeds and registration data see it first.
• No certificate, no record. Phishing over plain HTTP and pages on shared platforms covered by the platform's own wildcard certificate never create an entry that names them.
• Wildcards hide hostnames. *.example.com tells you the domain, not which subdomains exist.
• Private and self-signed certificates are not logged. Internal PKI and many C2 servers sit outside CT; for those you need scan data.
• The data is noisy and getting noisier. Precertificate and certificate pairs, ECC and RSA twins, and renewals every few months multiply entries, and shorter lifetimes will multiply them again.
• Logging is fast, not instant. An SCT is a promise to log within the merge delay (24 hours for the classic logs in Chrome's list, 60 seconds for the static-ct-api logs), and every search tool adds its own indexing lag on top.
• Tools fail quietly. crt.sh returned a 502 error when I first loaded it on 16 October, it truncates large result sets, and an unfiltered JSON query for a busy Google ccTLD hostname returned thousands of rows with nothing newer than January 2025, while the same query restricted to unexpired certificates showed entries from September 2026. Always check the newest date in your results before you conclude that nothing was issued.
• CT does not revoke anything. It tells you. The CA revokes, the browser blocks, and you fix DNS.

A CT Workflow You Can Run This Week

1. List every domain you own, including parked and regional ones, and the services allowed to obtain certificates for them.
2. Turn on owner-side monitoring with Cert Spotter or your CDN's CT alerts, and confirm the tool reads static-ct-api logs.
3. Publish CAA records naming only your CAs, bound to your ACME account where your CA supports it.
4. Start a brand watch with crt.sh wildcard searches each week, then move to a stream once you know what your noise looks like.
5. Write a two-line playbook for an unexpected certificate: contact the issuing CA, then check registrar, DNS and validation paths.
6. Practice one pivot from a public phishing report: seed, SAN list, IP, scan data, with each link graded.
7. Review quarterly, especially as validity drops to 100 days in March 2027.

Reading about pivots gets you the vocabulary. Grading a SAN sibling against a CDN certificate, or deciding that a naming match is still only a lead, takes repetition on real cases. Our Open Source Intelligence (OSINT) learning path covers domain, DNS and certificate research alongside the rest of the OSINT toolkit, and its five case-based investigations make you practice those calls before you make them at work.

Frequently Asked Questions

What is certificate transparency in simple terms?

Certificate transparency is a public logging system for TLS certificates. Publicly trusted certificate authorities submit every certificate to independent, append-only logs, and browsers such as Chrome and Safari refuse certificates that lack proof of logging. Anyone can then search the logs to see which certificates exist for a domain.

How do I check certificate transparency logs for my domain?

For a one-off check, search your domain on crt.sh or in Censys and look at the issuers and names in the results. For ongoing coverage, set up a monitor such as Cert Spotter or your CDN's CT alerts so you get notified whenever a new certificate names your domain.

What is the difference between a precertificate and a certificate?

A precertificate is a copy of the certificate a CA is about to issue, with a poison extension that stops browsers from accepting it. The CA logs the precertificate, collects signed certificate timestamps (SCTs) from the logs, and embeds them in the real certificate. That is why CT search tools often show two entries for one certificate.

Can certificate transparency detect phishing domains?

Partly. CT shows certificates issued for lookalike names, often before a phishing campaign is in full swing, but only if you watch for your brand string anywhere in new names. Owner-side monitors do not do this, and phishing sites that use HTTP, shared platform certificates or wildcards never appear by name.

Does certificate transparency prevent fake certificates?

No. CT makes issuance visible but does not block it. In the ccTLD hijacks Google disclosed in October 2026, CAs issued real certificates because attackers controlled DNS. CT log data then helped Google find more affected organizations and block their certificates in Chrome, and CAA records, prompt revocation and DNS security are the controls that limit damage.

Do wildcard certificates hide subdomains from CT logs?

Yes. A wildcard certificate such as *.example.com is logged with the wildcard name only, so the individual subdomains it serves never appear in CT. Attackers can use this to keep per-target hostnames out of the logs, and defenders can use it to avoid exposing internal names.

Does certificate transparency expose my internal hostnames?

It can. Any hostname in a publicly trusted certificate is published in the logs, and research presented at IEEE EuroS&P in 2023 found that scanners probe new hosts within seconds of their certificates being logged. Use a private CA or a wildcard certificate for names you do not want announced.

Sources

• Google: Chrome's Response to Recent ccTLD Registry Hijacks (6 October 2026)
• Certificate Transparency project: How CT works and community history
• RFC 6962: Certificate Transparency and RFC 9162: Certificate Transparency Version 2.0
• Chrome Certificate Transparency Policy and Chrome CT log list
• Chrome ct-policy: removal of the one-RFC 6962 log requirement
• Apple's Certificate Transparency policy
• Mozilla: Certificate Transparency in Firefox
• Google Security Blog: Sustaining Digital Certificate Security (2015)
• Let's Encrypt: End of Life Plan for RFC 6962 CT Logs and Reflections on a Year of Sunlight
• CA/Browser Forum Baseline Requirements and ballot SC-081v3
• RFC 8659: CAA and RFC 8657: CAA account and method binding
• Cloudflare: Certificate Transparency Monitoring
• SSLMate Cert Spotter (open source) and hosted plans
• certstream-server-go
• Censys: Legacy Search deprecation and Platform certificate dataset
• Microsoft Security: Passkey-themed social engineering leads to identity and cloud compromise (9 September 2026)
• Infoblox: Using SSL Certificates and Graph Theory to Uncover Threat Actors
• UC Santa Barbara, TU Delft and MPI Informatics: Certifiably Vulnerable, Using Certificate Transparency Logs for Target Reconnaissance (IEEE EuroS&P 2023)
• crt.sh certificate search