Catching Rogue Certificates Before They Hurt You: A Practical Guide to CT Log Monitoring

What Certificate Transparency Actually Is

Certificate Transparency (CT) is one of the quietest, most important security upgrades the web has ever shipped. Every public TLS certificate issued by a trusted Certificate Authority must be published to a public, append-only log within seconds of issuance. Browsers refuse to trust certificates that are not in CT logs.

That requirement, originally driven by Google after the DigiNotar breach in 2011, turned the global TLS ecosystem into something inspectable. Today there are dozens of CT logs operated by Google, Cloudflare, Let's Encrypt, Sectigo, and others, all collectively recording roughly 40 million new certificates per day. Anyone can subscribe to that firehose. Including you. Including attackers.

Why Watching the Logs Matters

Most teams know about CT in the abstract but never read their own log entries. That is a mistake, because CT is the single best place to learn about certificates issued in your name that you did not request. Three real categories:

• Shadow IT. Marketing spun up a landing page on a new subdomain via a SaaS. Engineering provisioned analytics.example.com via a vendor. Neither told security. CT shows you the cert was issued.
• Subdomain takeover preparation. An attacker who controls an abandoned subdomain (dangling CNAME to a deprovisioned Heroku app) can request a valid TLS certificate for it. CT shows you the issuance hours before the attacker uses it for phishing.
• Misissued certificates. Rare, but it happens. A CA issues a cert for your domain because of a validation bug, a social-engineered support ticket, or an account compromise on the requester's side.

In each case, the certificate is valid by the rules of the public web — browsers will accept it. The only defence is detecting it quickly, getting it revoked, and shutting down whatever surface it was about to be used against.

What You Actually See in a CT Stream

A CT log entry contains the certificate itself, the issuing CA, the timestamp, and the log it was submitted to. When GuardHound subscribes to CT for your domain, the raw stream looks something like this:

That single record tells you enough to triage: the issuer (is it the CA you actually use?), the subject and SAN list (are these names you recognise?), the validity window (typical 90-day Let's Encrypt or something unusual?), and the serial (so you can request revocation if needed).

What you do not get from a basic CT subscription is the rest of the picture: who the requester was, what IP issued the validation challenge, whether the cert was ever actually used. That is why the most useful CT monitoring layers in your private CA records, your CAA policy, and your subdomain inventory.

Four Patterns Worth Alerting On

Raw CT is a firehose. The art is choosing which entries deserve a page. Four patterns are almost always worth alerting on:

CAA: The Other Half of the Story

CT tells you what was issued. CAA — Certification Authority Authorization — controls who is allowed to issue. A CAA DNS record is a one-line policy that says, for example, "only Let's Encrypt may issue certificates for example.com." Compliant CAs check CAA before issuance and refuse if their name is not on the list.

CAA is preventative; CT is detective. Together they are the modern minimum:

Setting Up CT Monitoring Without the Noise

Anyone can write a script that polls crt.sh for new entries matching their domain. The hard part is making the alerts useful. Three rules of thumb:

Group expected re-issuances by issuer + name pattern. If app.example.com renews via Let's Encrypt every 60 days, that is not an alert — it is a heartbeat. If the same name suddenly renews via a different issuer or a different ACME account, that is an alert.

Alert on the SAN list, not just the CN. An attacker who chains your name onto a multi-name cert (often as a hidden SAN) hopes you will only look at the CN. Modern CT alerting compares every SAN against your known inventory.

Cross-reference with your subdomain explorer. A CT entry for a subdomain that does not exist in your DNS is a signal of a takeover-in-progress. A CT entry for a subdomain that exists but you do not recognise is a signal of shadow IT. Both are worth knowing.

How GuardHound Folds CT Into the Risk Score

CT monitoring lives inside the Certificates dimension of the eight-dimension risk score, alongside SSL expiry checks, weak protocol detection, and chain validation. Pro, Business, and Agency plans get the full CT-log subscription with grouping, deduplication, and alerting on the four patterns above. Starter plans get expiry-only certificate monitoring without the CT firehose.

When a CT alert fires, it does three things at once: it shows up on the certificates pillar, it pulls the risk score down (severity-weighted), and it appears in the daily snapshot's "top contributors" list so the score drop is explained. If you also have uptime monitoring on the same domain, the SSL-handshake check will pick up the new cert the next time it polls — so you get the issuance event from CT and the deployment event from your monitor as two correlated points on the same dashboard.

Because GuardHound also runs subdomain discovery, every CT entry is automatically cross-referenced against your known subdomain inventory. Names that do not resolve, names you have never seen before, and names that were recently deprovisioned all get flagged.