Certificate Transparency: Catch Rogue Certificates
2026-10-13 · 8 min read · By the DomainGuard team
The short version
Certificate Transparency (CT) logs are public, append-only records of every TLS certificate issued by publicly trusted certificate authorities. Because CAs must log every certificate, issuance for your domain is, in principle, fully visible to you. Monitoring those logs means watching for certificates issued for your domains (and your lookalike domains) that you didn't authorize. It is the earliest public signal that someone is building phishing infrastructure against you, and in October 2026 Google publicly told every domain owner to do it after attackers forged valid certificates for Google domains via registry hijacks.
Why it matters right now: the October 2026 registry hijacks
On October 6, 2026, Google's Chrome security team disclosed that attackers had compromised the operators of three country-code registries, .gh (Ghana), .sl (Sierra Leone), and .as (American Samoa), modified authoritative DNS records, and obtained unauthorized but technically valid HTTPS certificates covering several Google domains. Google was explicit: its own systems were not breached, and it had no reason to believe the certificate authorities did anything wrong. The CAs followed their validation rules. The attackers simply controlled the DNS layer the validation depended on.
Security researchers found 12 of the forged certificates across the three registries, 11 issued by Let's Encrypt, one by ZeroSSL, covering Google and YouTube names, with CT data pointing to other well-known brands hit by the same campaign. Google blocked the known certificates in Chrome and pushed revocations, while warning that undiscovered ones could still be out there.
The part that matters for you: Google's published guidance to domain owners after the incident named two defenses, monitor Certificate Transparency logs and publish restrictive CAA records. Not new products. Not a vendor pitch. Two free, open mechanisms. If the operators of Google's domains need CT monitoring to catch forged certificates, a domain without a security team needs it more.
How Certificate Transparency actually works
The mechanics are worth understanding, because they explain both the power and the limits of monitoring. When a CA issues a certificate, it first submits a precertificate, a binding commitment to issue, to one or more public CT logs. The log returns a Signed Certificate Timestamp (SCT), a cryptographic promise that the certificate will appear in the log within the Maximum Merge Delay (MMD), currently 24 hours. The SCT gets embedded in the final certificate, and browsers like Chrome require it: no SCT, no trust.
What this means in practice: a certificate issued for your domain shows up in public logs within hours, usually minutes, of issuance. The log entry includes the exact domain names on the certificate, the issuing CA, and the validity window. It does not include the private key and doesn't tell you why it was issued, but "a certificate for a subdomain you never created, from a CA you never used" is a finding regardless of intent.
CT was created after the 2011 DigiNotar breach, in which a compromised CA issued hundreds of fraudulent certificates — a case that ended the company entirely. The lesson of DigiNotar was that secret issuance is the danger. CT's answer: make all issuance public, so the domain owner is always the last line of detection.
What rogue issuance looks like
Picture your Monday morning alert queue. A new certificate appears in the logs for secure-portal.yourdomain.com, a subdomain that doesn't exist in your DNS, issued by a CA your company has never used, valid for 90 days starting yesterday. The attacker now runs a pixel-perfect HTTPS phishing site: the padlock is real, the certificate is real, only the operator is a criminal. Without CT monitoring, you learn about it when a victim forwards you the phishing email, or when your helpdesk tickets spike.
The subtler variant is the lookalike certificate. Attackers increasingly obtain certificates for typosquat domains before weaponizing them, the certificate is part of the infrastructure build-out, like registering the domain and setting up MX records. A monitor that only watches your exact domain misses this entirely. Watching your generated lookalike set in CT catches phishing infrastructure at issuance, pre-attack, when the only thing the attacker has done so far is paperwork.
How to monitor: the tools and a walkthrough
You don't need a product to start. The raw material is free:
crt.sh, run by Sectigo, is the reference CT search engine. Open it and search %.yourdomain.com, the % is a wildcard matching all subdomains. You'll see every certificate ever logged for your domain and its subdomains: issuers, dates, and the exact names covered. During the October 2026 incident, researchers used CT search services (crt.sh-style tooling, plus ctlogs.dev and Cert Spotter) to find the forged Google certificates within a day of disclosure. That's the workflow: query, baseline, watch for deltas.
Cert Spotter (by SSLMate) and ctlogs.dev are solid alternatives with APIs, useful if you want to script the checks. Facebook once ran a popular CT monitor; today the practical options are these independent search engines plus commercial monitoring.
The monitoring loop that actually works has three parts. First, baseline. Record everything already issued for your domains — your certs, your CDN's certs, your SaaS vendors' certs. Expect surprises here; most companies discover certificates they forgot about on the first run. Second, alert on deltas. Any new certificate after the baseline is a finding until proven otherwise. Third, include the lookalikes. Generate your typosquat variant set (see our typosquatting guide) and watch those names in CT too. An attacker getting a certificate for a lookalike is the single clearest pre-attack signal in this entire space.
Found a rogue certificate, now what
Don't panic, but don't sit on it either. Work this sequence:
1. Verify it's actually rogue. Check with your infrastructure team, your CDN, and your SaaS vendors before escalating. CT logs show issuance, not intent, the most common "rogue" certificate is one your own marketing team authorized through a vendor you forgot about. Every alert should show the issuer and the exact names so this triage takes minutes.
2. Report to the issuing CA. Every publicly trusted CA is required to maintain a problem-reporting channel for suspected mis-issuance. File with the certificate's serial number and the CT log entry. The CA investigates and revokes.
3. Publish or tighten CAA records. CAA (Certification Authority Authorization) DNS records declare which CAs may issue for your domain. Two lines of DNS close the "any CA on earth" hole, see our CAA guide for the exact records. One honest caveat from the October 2026 incident: CAA is enforced by CAs checking your DNS, so it doesn't stop an attacker who has compromised your DNS or registry itself. It stops CA-shopping and mis-issuance, which is the far more common case.
4. Treat the validity window as exposure. Browser revocation is uneven, a revoked certificate may still be trusted by some clients for a while. Assume the certificate could have been used for interception during its validity window and investigate accordingly: check for phishing reports, look at your own logs for anomalies, and warn your users if there's evidence of active abuse.
The honest limits
CT monitoring is detection, not prevention — it tells you a certificate exists, it doesn't stop issuance. There's a delay of minutes to hours between issuance and log visibility (the MMD), and a sophisticated attacker can use a certificate within that window. Logs also don't cover every corner: certificates from non-publicly-trusted CAs (internal enterprise CAs, for example) aren't logged, though those aren't the ones your customers' browsers trust anyway.
And the October 2026 incident exposed the deepest limit: CT showed the forged certificates after the registry compromise had already happened. Monitoring caught the symptom quickly, researchers found the certs within a day, but nothing in CT prevents the DNS-layer attack itself. That's why Google's guidance paired CT monitoring with restrictive CAA records and, implicitly, with watching the registries your domains depend on. Layers, not silver bullets.
FAQ
Is Certificate Transparency monitoring free?
The logs and search engines (crt.sh, ctlogs.dev, Cert Spotter) are free and public. What costs money, or engineering time, is the continuous part: baselining, alerting on deltas, triaging false positives, and watching lookalike domains alongside your real ones. Manual checks work for a snapshot; automation is what makes it monitoring.
How fast do new certificates appear in CT logs?
Usually within minutes to a few hours of issuance. The Maximum Merge Delay is 24 hours, but in practice major logs merge far faster. If you're checking daily, you'll catch effectively everything.
Does CT monitoring replace CAA records?
No, they're complementary. CAA prevents unauthorized issuance (by telling CAs who's allowed to issue); CT monitoring detects issuance that happened anyway. Google's October 2026 guidance recommended both, together.
What about certificates for typosquat domains?
They appear in CT logs like any other certificate, which is exactly why your monitoring should cover your lookalike variant set, not just your exact domain. A fresh certificate on a lookalike is often the first observable step of a phishing campaign.