Certificate Transparency Logs: How to Monitor for Rogue Certificates

In 2015, Symantec was found to have issued unauthorized test certificates for Google domains without Google's knowledge. This was possible because, at the time, there was no reliable way for domain owners to know when a certificate authority had issued a certificate for their domain. Certificate Transparency (CT) was designed to solve exactly this problem — and today it is your most powerful tool for detecting rogue TLS certificates before attackers use them.

How Certificate Transparency Works

Every public TLS certificate issued by a trusted CA must be submitted to at least one publicly auditable CT log before browsers will trust it. These logs are append-only, cryptographically verifiable Merkle trees. Once a certificate entry is added, it cannot be removed or altered without breaking the log's cryptographic proof.

The structure works like this:

1. A CA issues a certificate for api.example.com
2. The CA submits the certificate (or a pre-certificate) to one or more CT logs
3. The log returns a Signed Certificate Timestamp (SCT) — a cryptographic promise that the cert has been logged
4. The CA embeds the SCT in the certificate before delivery
5. Browsers verify the SCT during the TLS handshake

The key insight: every certificate for your domain will appear in CT logs within minutes of issuance, whether you requested it or not. This gives you near-real-time visibility into your entire certificate footprint.

Reading CT Logs with crt.sh

The simplest way to see all certificates issued for your domain is crt.sh, a public CT log aggregator run by Sectigo.

# All certificates for example.com and subdomains
curl -s "https://crt.sh/?q=%.example.com&output=json" | \
  jq '.[] | {issuer: .issuer_ca_id, name: .name_value, logged: .entry_timestamp}'

This query uses the % wildcard to match all subdomains. The output will include every certificate ever logged for your domain — including expired ones, wildcard certs, and any issued by unexpected CAs.

Look for:

• Certificates issued by CAs you have not authorized
• Wildcard certificates (*.example.com) you did not request
• Certificates for internal subdomains (internal.example.com, admin.example.com) that should never have public certificates
• Duplicate certificates with slightly different SANs

Setting Up Automated Monitoring with cert-spotter

Manual crt.sh queries are useful for audits, but real-time monitoring requires automation. cert-spotter by SSLMate is an open-source daemon that watches CT logs and alerts you when new certificates are issued for domains you care about.

# Install cert-spotter
go install software.sslmate.com/src/certspotter/cmd/certspotter@latest

# Watch all certificates for example.com
certspotter -watchlist watchlist.txt -script /usr/local/bin/cert-alert.sh

Your watchlist.txt:

.example.com
example.com

The leading . instructs cert-spotter to match all subdomains. The -script flag points to a shell script that runs whenever a new certificate is detected:

#!/bin/bash
# cert-alert.sh — called by cert-spotter for each new certificate
DOMAIN="$CERT_SPOTTER_WATCHED_DOMAIN"
DNS_NAMES="$CERT_SPOTTER_DNS_NAMES"
ISSUER="$CERT_SPOTTER_ISSUER"

# Alert via Slack webhook
curl -s -X POST "$SLACK_WEBHOOK_URL" \
  -H 'Content-type: application/json' \
  --data "{\"text\": \"New certificate issued for $DOMAIN\\nSANs: $DNS_NAMES\\nIssuer: $ISSUER\"}"

SSLMate also provides a hosted version of this monitoring at sslmate.com/certspotter if you prefer not to run your own daemon.

DNS CAA Records: Restricting Which CAs Can Issue

Certificate Transparency tells you after a certificate has been issued. CAA (Certification Authority Authorization) DNS records are a preventive control — they instruct CAs which authorities are permitted to issue certificates for your domain.

# Check existing CAA records
dig CAA example.com

# Example CAA records
example.com. 300 IN CAA 0 issue "letsencrypt.org"
example.com. 300 IN CAA 0 issue "digicert.com"
example.com. 300 IN CAA 0 issuewild ";"
example.com. 300 IN CAA 0 iodef "mailto:security@example.com"

The issue tag specifies which CAs can issue single-domain certificates. Setting issuewild ";" (a semicolon with no value) prohibits any CA from issuing wildcard certificates. The iodef tag tells CAs where to report policy violations.

A compliant CA encountering a domain with a CAA record that does not include them must refuse to issue the certificate. This dramatically reduces the blast radius if a CA is compromised or makes an error.

Monitoring via the SSLMate API

For integration into existing security tooling or SIEM pipelines, the SSLMate Certificate Search API provides programmatic access:

# Search for recently issued certs (last 24 hours)
curl -s "https://api.certspotter.com/v1/issuances?domain=example.com&since=$(date -u -d '24 hours ago' +%s)&expand=dns_names&expand=issuer" \
  -H "Authorization: Bearer $SSLMATE_API_KEY"

This can be run as a scheduled job (hourly or daily) and the output fed into your alerting pipeline to flag unexpected issuers or previously unseen subdomains.

What to Do When You Find a Rogue Certificate

If you discover a certificate you did not authorize:

1. Confirm it is unauthorized. Check with your team — someone may have legitimately requested it.
2. Request revocation. Contact the issuing CA's support and request revocation. Most CAs have a security contact or abuse process.
3. Report to the CA/Browser Forum. If the CA refuses to revoke or if issuance was clearly in error, report to the CA/Browser Forum via their bug tracker.
4. Investigate the attack vector. How did the attacker prove domain control? Check your DNS for unauthorized records, your registrar account for unauthorized access, and your web server for unauthorized .well-known/acme-challenge/ files.
5. Tighten CAA records. If no CAA record existed, add one immediately.

Integrating CT Monitoring Into Your Security Program

CT monitoring should be a standard part of your asset inventory and attack surface management workflow:

• Run a full historical audit of crt.sh quarterly to catch certificates you may have missed
• Run cert-spotter (or equivalent) continuously for real-time alerting
• Add CAA records for all domains — even ones you do not actively use
• Include new CT log entries as a trigger for your domain inventory refresh
• Alert on certificates for internal subdomains that should never be publicly trusted

Certificate Transparency has fundamentally changed the trust model for TLS. Attackers cannot issue certificates for your domains without those certificates appearing in public logs — but only if you are watching.