Here is a failure your monitoring is built to miss. Somebody — an attacker who briefly controlled your DNS, a subdomain you forgot you delegated, an ex-vendor whose access was never revoked, or a phishing operator standing up login.yourbrand.com on infrastructure you don't own — gets a certificate authority to issue a valid, publicly-trusted TLS certificate for a name under your domain. It is a real certificate. Browsers trust it. And it is never served on your origin, so nothing you watch will ever connect to it: your uptime check gets a 200 from your real server, your SSL-expiry monitor reads your real certificate's notAfter, and every dashboard stays green while a certificate you never ordered is out in the world with your name on it.
The one place that certificate is guaranteed to appear is a system most teams don't watch at all — the Certificate Transparency logs. Watching them is the difference between finding out from a log and finding out from a customer who got phished.
What Certificate Transparency Actually Is
Certificate Transparency (CT), specified in RFC 6962, is a public, append-only, cryptographically-verifiable record of certificates. When a CA issues a certificate, it submits it to a set of independent CT logs, each of which returns a signed certificate timestamp (SCT) — a promise that the certificate has been publicly recorded.
The reason this isn't optional theater: since 2018, Chrome (and Safari, and others) refuse to trust a publicly-trusted certificate unless it carries valid SCTs proving it was logged. A CA that issues a cert without logging it produces a certificate that browsers reject. So the incentives line up in your favor for once — a certificate that works in a browser is, by construction, a certificate that is written down somewhere you can read.
That flips the usual asymmetry. You cannot watch every CA, every DNS provider, and every corner of your own shadow IT. But you don't have to. Every valid certificate for your domain has to announce itself in public, whether you ordered it or not. The whole game is reading that announcement.
How an Unauthorized Certificate Happens
"Nobody can just get a cert for my domain" is the comfortable assumption CT exists to break. The common paths, none of which require breaking a CA:
-
Domain-validation abuse. A DV certificate — the free, instant kind — proves control, not ownership. Whoever can answer an HTTP-01 challenge on your host, or write a DNS TXT record for your zone, can get a certificate. A brief DNS compromise, a dangling
CNAMEpointing at a de-provisioned cloud resource (subdomain takeover), or a stale record left after a migration is enough. - Someone inside the perimeter you forgot about. A contractor, an old CI pipeline, a marketing SaaS you connected a subdomain to years ago — anything that once had the ability to prove control can still mint a certificate today unless that control was revoked.
-
Lookalike and adjacent names. An attacker can't get a cert for a name they don't control, but they can get one for
yourbrand-support.comoryourbrand.io, or for a subdomain of a domain they do control that impersonates you. Those show up in CT too, keyed on the string, and a monitor that watches the registrable name and its neighbors catches the pattern.
The unifying property: in every one of these, the certificate is served somewhere that isn't your server, so the only signal that reaches you is the log entry.
Check Your Own Logs Right Now
You do not need an account to look. Two free ways:
crt.sh — the human-friendly front end to the logs. In a browser:
https://crt.sh/?q=example.com
Or as JSON you can pipe into a script (%25 is a URL-encoded % wildcard, so this catches subdomains):
curl -s 'https://crt.sh/?q=%25.example.com&output=json' | jq '.[].name_value' | sort -u
certspotter — a cleaner issuance API, one row per certificate, with an authenticated free tier:
curl -s 'https://api.certspotter.com/v1/issuances?domain=example.com&include_subdomains=true&expand=dns_names&expand=issuer'
Read the output the way an auditor would. For each certificate ask: do I recognize this issuer, this set of hostnames, and this issuance date? A Let's Encrypt cert for www you renewed last Tuesday is expected. A cert from a CA you've never used, or covering a subdomain you don't remember creating, or issued at 3 a.m. on a day you shipped nothing, is the row that matters.
Why a One-Time Check Doesn't Protect You
Running that query once tells you the state of the world today. It says nothing about the certificate that gets issued three weeks from now, after you've closed the tab. And the whole value of CT for defense is time — an unauthorized certificate is a leading indicator. It usually appears in the logs before it is used to phish anyone, which is exactly the window in which you can revoke it and close the hole. Miss that window and CT becomes a post-mortem instead of an alarm.
Catching it means the check has to run continuously and, crucially, diff against a baseline of what you already knew about. The signal isn't "a certificate exists" — you have hundreds. The signal is "a certificate exists that wasn't here last time and that I didn't expect." That's a stored baseline plus a new-issuance comparison on every poll, alerting only on the delta. A human re-reading crt.sh every morning is doing that comparison in their head, badly, and only on mornings they remember.
When You Find One — And How to Prevent the Next
If a certificate you don't recognize turns up:
- Confirm it's genuinely unauthorized — not a CDN, a SaaS subdomain, or a colleague's project. Most surprises are shadow IT, not attacks, and that's worth knowing too.
- Report it to the issuing CA for revocation. Every CA has a problem-reporting channel; a certificate proven to be mis-issued or issued to a party without authority is grounds for revocation.
- Close the door it came through — reclaim the dangling subdomain, rotate the DNS/registrar credentials, remove the stale delegation.
Then constrain future issuance with a CAA record (RFC 8659). CAA tells CAs which authorities are allowed to issue for your domain; a compliant CA must refuse if it isn't listed:
example.com. CAA 0 issue "letsencrypt.org"
example.com. CAA 0 issuewild ";"
example.com. CAA 0 iodef "mailto:security@example.com"
That won't stop a CA that ignores CAA (which is itself a reportable violation), and it won't retract a cert already issued — but it narrows the attack surface to "your chosen CA is compromised" instead of "any CA on earth." CAA constrains; CT detects. You want both.
I work on Merlonix, which watches your domain's Certificate Transparency issuance stream continuously: it reads the full issuance set for your domain and its subdomains, holds a baseline of the certificates it has already seen, and alerts on a new, never-before-seen issuance — a certificate from an unexpected CA or covering a name you didn't provision — the kind that never touches your server and never trips an uptime or expiry check. Continuous CT/rogue-certificate monitoring is a paid monitoring feature (Team, Agency, and Compliance tiers), opt-in per asset.
If you just want to look today, both front doors are free and need no signup: the SSL & DNS checker reads a domain's live certificate and DNS in one shot, the free certificate watcher tracks a certificate's expiry countdown, and the free tools hub has the rest. When the problem is your own certificate rather than someone else's, these cover each way it fails: expiry, name mismatch, incomplete chain, untrusted root, and a handshake that fails before any certificate.
The certificate you renew on schedule is the one you'll never be surprised by. The one that hurts is the one you didn't order — and Certificate Transparency is the only place it was ever going to show up.
