Certificate Transparency Monitoring: Detect Rogue Certificates and Subdomain Leaks

What are Certificate Transparency logs?

Certificate Transparency (CT) is a framework that requires certificate authorities (CAs) to publicly log every TLS certificate they issue. These logs are append-only, publicly auditable, and searchable by anyone.

CT was created to solve a real problem: rogue or compromised CAs issuing fraudulent certificates. Before CT, a compromised CA could issue a valid certificate for google.com and nobody would know until it was used in an attack. With CT, every certificate is logged and can be detected.

All major browsers now require CT compliance. Chrome and Safari will reject certificates that are not logged in CT, so in practice every publicly trusted certificate ends up in the logs.

How attackers use CT logs

CT logs are a goldmine for reconnaissance. An attacker researching your organisation can search CT logs to discover:

Subdomain enumeration

Every certificate reveals the domain names it covers. If you issued a certificate for staging-api.yourcompany.com, that subdomain is now publicly visible -- even if it is not linked anywhere on your website and not indexed by search engines.

This is one of the first steps in any attack surface assessment. Tools like subfinder and amass query CT logs automatically.

Infrastructure mapping

Certificate metadata reveals:

• Which CAs you use (Let's Encrypt, DigiCert, Sectigo, etc.)
• When certificates are issued and renewed (revealing your operational patterns)
• Whether you use wildcards (suggesting many subdomains behind one cert)
• Staging, development, and internal-facing services that have public certificates

Detecting new services before they are hardened

Attackers monitor CT logs in real time. When you issue a certificate for a new subdomain -- say new-app.yourcompany.com -- an attacker can detect it within minutes. If your new service is not fully hardened when you deploy the certificate, there is a window of vulnerability.

This is directly relevant to subdomain takeover -- if you issue a certificate for a subdomain that is not yet pointed to anything, it signals a potential future target.

How security teams should use CT logs

The same visibility that helps attackers also helps defenders. You should be monitoring CT logs for your domains.

Detect rogue or unexpected certificates

If someone (a compromised CA, a rogue employee, or an attacker with access to your domain validation) issues a certificate for your domain, CT monitoring alerts you immediately.

Discover shadow IT

Teams sometimes spin up services and request certificates without informing security. CT monitoring catches these, giving you visibility into your true attack surface.

Verify certificate hygiene

CT logs let you audit all certificates ever issued for your domain: are any expired but still in use? Are there certificates from CAs you do not use? Are there certificates for subdomains that should not exist?

Free CT monitoring tools

crt.sh

crt.sh is the most widely used CT log search engine. Search for your domain to see every certificate ever issued:

https://crt.sh/?q=yourcompany.com

For wildcard coverage, search with %:

https://crt.sh/?q=%25.yourcompany.com

Using crt.sh from the command line

# Query crt.sh and extract unique subdomain names
curl -s "https://crt.sh/?q=%25.yourcompany.com&output=json" | \
  jq -r '.[].name_value' | \
  sort -u

This gives you a list of every subdomain that has ever had a certificate issued for it.

Certspotter

SSLMate Certspotter monitors CT logs and sends you alerts when new certificates are issued for your domains. The free tier covers a limited number of domains.

Facebook Certificate Transparency Monitoring

Facebook CT Monitoring lets you subscribe to alerts for your domains. It is free and sends notifications when new certificates are detected.

Google Certificate Transparency search

Google operates several CT logs and provides a search interface. Visit Google Transparency Report to search for certificates by domain.

How to set up alerts for new certificates

Option 1: Certspotter API

# Subscribe to alerts for your domain
curl -X POST https://api.certspotter.com/v1/issuances \
  -d domain=yourcompany.com \
  -d include_subdomains=true \
  -d email=security@yourcompany.com

Option 2: Monitor crt.sh with a cron job

Create a simple script that checks for new certificates periodically:

#!/bin/bash
DOMAIN="yourcompany.com"
STATE_FILE="/tmp/ct-monitor-$DOMAIN.txt"
CURRENT=$(curl -s "https://crt.sh/?q=%25.$DOMAIN&output=json" | jq -r '.[].id' | sort -n)

if [ -f "$STATE_FILE" ]; then
  PREVIOUS=$(cat "$STATE_FILE")
  NEW_CERTS=$(diff <(echo "$PREVIOUS") <(echo "$CURRENT") | grep "^>" | wc -l)
  if [ "$NEW_CERTS" -gt 0 ]; then
    echo "$NEW_CERTS new certificates detected for $DOMAIN" | \
      mail -s "CT Alert: New certificates for $DOMAIN" security@yourcompany.com
  fi
fi

echo "$CURRENT" > "$STATE_FILE"

Run this hourly or daily with cron.

Option 3: Use a commercial tool

Services like SurfaceScan, Hardenize, and SecurityTrails provide CT monitoring as part of their broader attack surface monitoring capabilities.

What to do when you spot something unexpected

If CT monitoring reveals a certificate you did not request:

1. Identify the issuing CA -- check the certificate details on crt.sh
2. Check domain validation -- did someone exploit a DNS misconfiguration or email-based validation to get a certificate?
3. Revoke the certificate -- contact the CA and request revocation
4. Investigate the cause -- was a DNS record compromised? Is there a subdomain takeover vulnerability?
5. Review your CAA records -- DNS CAA records restrict which CAs can issue certificates for your domain. If you do not have CAA records, any CA can issue for you:

# Check existing CAA records
dig CAA yourcompany.com

# Add a CAA record to restrict issuance to Let's Encrypt only
# In your DNS zone file:
yourcompany.com.  IN  CAA  0 issue "letsencrypt.org"
yourcompany.com.  IN  CAA  0 issuewild "letsencrypt.org"
yourcompany.com.  IN  CAA  0 iodef "mailto:security@yourcompany.com"

The iodef tag tells CAs to notify you if someone requests a certificate that violates your policy.

For more on managing your TLS certificates and preventing expiry, see our guide on expired TLS certificates.

How SurfaceScan helps

SurfaceScan monitors Certificate Transparency logs for all domains in your attack surface. It alerts you when new certificates are issued, flags certificates from unexpected CAs, and detects subdomains revealed through CT that are not in your known asset inventory. This gives you early warning of both rogue certificate issuance and shadow IT, complementing the subdomain takeover detection and TLS health checks that run on every scan.