BrightByte
Defensive
3 min read

TLS Certificate Transparency: What Defenders Are Missing

CT logs are a goldmine for threat intelligence, but most security teams aren't watching them. A practical guide to monitoring, querying, and alerting on certificate issuance.

Certificate Transparency logs are one of the most underused data sources in defensive security. Every publicly-trusted TLS certificate issued since 2018 is logged in append-only, publicly auditable logs. That means every subdomain, every service, every shadow IT deployment that uses HTTPS leaves a trail.

Most security teams aren’t watching.

What CT Logs Actually Are

When a Certificate Authority issues a TLS certificate, it submits the certificate to one or more CT log servers. These servers return a Signed Certificate Timestamp (SCT) that the CA embeds in the certificate. Browsers verify the SCT to ensure the certificate was logged.

The result: a real-time, public record of every certificate issued for every domain.

Certificate Issued
    │
    ▼
CA submits to CT Log ──► Log returns SCT
    │
    ▼
Certificate includes SCT
    │
    ▼
Browser verifies SCT on connection

Why Defenders Should Care

Subdomain enumeration. Forget brute-forcing subdomains. CT logs will tell you every subdomain that has ever had a certificate issued. This includes:

Phishing detection. Attackers request certificates for lookalike domains. Monitoring CT logs for certificates containing your brand name catches phishing infrastructure before the campaign launches.

Shadow IT discovery. When someone in marketing spins up a Netlify site on promo.yourcompany.com and points a CNAME at it, the certificate issuance shows up in CT logs. You’ll see it before they tell you about it.

Practical Querying

Using crt.sh

The simplest starting point is crt.sh, a web interface maintained by Sectigo that indexes CT logs:

-- Find all certificates for a domain (including subdomains)
SELECT ci.NAME_VALUE, cl.CAID, cl.ISSUER_CA_ID
FROM certificate_identity ci
JOIN certificate_log cl ON ci.CERTIFICATE_ID = cl.CERTIFICATE_ID
WHERE ci.NAME_VALUE LIKE '%.example.com'
ORDER BY cl.ENTRY_TIMESTAMP DESC;

Or use their API directly:

# All certificates for a domain
curl -s "https://crt.sh/?q=%.example.com&output=json" | \
  jq -r '.[].name_value' | sort -u

# Find recently issued certificates (last 24 hours)
curl -s "https://crt.sh/?q=%.example.com&output=json" | \
  jq -r '.[] | select(.not_before > (now - 86400 | strftime("%Y-%m-%dT%H:%M:%S"))) | .name_value'

Using Certstream

For real-time monitoring, Certstream provides a WebSocket feed of newly issued certificates:

import certstream
import re

WATCHED_DOMAINS = ['example.com', 'example.org']
BRAND_KEYWORDS = ['examp1e', 'exampl3', 'example-login']

def callback(message, context):
    if message['message_type'] != 'certificate_update':
        return

    all_domains = message['data']['leaf_cert']['all_domains']

    for domain in all_domains:
        # Check for our own domains (subdomain discovery)
        for watched in WATCHED_DOMAINS:
            if domain.endswith(f'.{watched}') or domain == watched:
                print(f"[SUBDOMAIN] {domain}")

        # Check for brand impersonation
        for keyword in BRAND_KEYWORDS:
            if keyword in domain:
                print(f"[PHISHING?] {domain}")

certstream.listen_for_events(callback, url='wss://certstream.calidog.io/')

Building an Alerting Pipeline

A production-grade CT monitoring setup needs three components:

1. Ingestion. Subscribe to CT log feeds or poll crt.sh on a schedule. For high-volume monitoring, run your own CT log follower using Google’s certificate-transparency-go library.

2. Matching rules. Define what you care about:

rules:
  - name: subdomain_discovery
    type: exact_suffix
    patterns:
      - ".example.com"
      - ".example.org"
    action: log_and_alert

  - name: brand_impersonation
    type: fuzzy
    patterns:
      - "example"
    exclude:
      - "example.com"
      - "example.org"
    min_similarity: 0.85
    action: alert_high

  - name: wildcard_issuance
    type: exact
    patterns:
      - "*.example.com"
    action: alert_critical

3. Deduplication and alerting. Certificates get logged to multiple CT logs, so you’ll see duplicates. Deduplicate by certificate fingerprint before alerting. Send actionable alerts — include the domain, issuer, and validity dates.

What You’ll Find

When you start monitoring CT logs for your organization, expect surprises. In every engagement where I’ve set this up, the first 48 hours reveal:

The cost of monitoring is effectively zero. The data is public. The tooling is open source. The only question is whether you’re watching.