Certificate Transparency: See Every Cert Issued
Every certificate for your domain lands in a public log. How to watch CT logs to catch typo'd, rogue or forgotten certs - free, in ten minutes.
Short answer
Certificate Transparency logs record issued TLS certificates publicly. Watch your domain in those logs to catch unexpected, typo, or forgotten certificates.
Why watch your own domain
Rogue or forgotten certs appear for staging hosts, phishing lookalikes, and abandoned SaaS CNAMEs.
CT is how you notice without waiting for a customer report or a brand-abuse ticket three months late.
Readers skimming certificate transparency monitoring often stop at definitions. The part that prevents incidents is the verification step after the change - and the habit of re-checking after the next deploy that touches the same layer.
Ten-minute setup
Search public CT browsers for your domain, enable alerts from your DNS or CA provider if available, and review weekly until automation is in place.
Baseline what you expect so the next unknown SAN stands out.
Common failure mode for certificate transparency monitoring: staging looks fine, production still serves the old config because a CDN, load balancer, or second vhost was never updated. Always verify the hostname customers hit.
What to do on a hit
If you do not recognize the cert, investigate the requester and SAN list. Revoke when appropriate.
Treat unknown certs as an identity incident, not a curiosity - especially if the names look like login or payment hosts.
If this section on certificate transparency monitoring becomes a recurring ticket, automate the check. Manual one-offs rot; a post-deploy assertion or weekly grade keeps the control honest.
What to do this week
- Search CT logs for your registered domains.
- Enable alerts from CA/DNS provider where available.
- Document expected SANs so unknowns stand out.
- On unknown cert: investigate, revoke if needed, fix the process that issued it.
If a cert exists for your name, you should know about it.
Update log (1)
2026-05-21Editorial form rewrite for length and uniqueness.
Sources + verification
Practical guidance based on mainstream browser behavior, common reverse-proxy configuration, and widely published RFCs and vendor docs. Verify on your own stack with curl, browser devtools, and a re-scan after each change.
