Certificate Transparency Monitoring: Catch Rogue SSL Certificates

Why Certificate Transparency Exists

In 2011, DigiNotar was breached. The attacker issued a fraudulent certificate for *.google.com and used it to intercept Gmail traffic for Iranian users. Nobody noticed for over a month because there was no public record of certificate issuance. A CA could sign a certificate for any domain, and only the domain owner would know — if they happened to be looking.

Certificate Transparency (CT) was the answer. Every publicly trusted CA must now submit every certificate it issues to at least two CT logs. These logs are append-only, cryptographically verifiable Merkle trees operated by Google, Cloudflare, DigiCert, and other organizations. Anyone can query them. Anyone can monitor them. The result is a permanent, auditable record of every SSL certificate ever issued for every domain on the public internet.

The operational implication is straightforward: if a certificate appears in CT logs for your domain, and you did not request it, something is wrong. Either a CA made an error, an internal team spun up a service without telling security, or an attacker has compromised a CA or ACME account. CT monitoring catches all three scenarios.

Searching Certificate Transparency Logs

There are multiple CT search frontends, but crt.sh is the most widely used. Query it directly from the command line:

curl -s 'https://crt.sh/?q=%25.example.com&output=json' | jq '.[] | {name: .name_value, issuer: .issuer_name, logged: .entry_timestamp}'

The %25 is a URL-encoded percent sign acting as a wildcard. It matches every certificate whose subject or SAN includes .example.com, including subdomains. The output shows the domain name as it appears in the certificate, the issuing CA, and the timestamp when the certificate was logged.

Filtering the output helps spot anomalies:

curl -s 'https://crt.sh/?q=%25.example.com&output=json' | jq -r '.[] | select(.name_value | test("^(?!.*cloudfront.net).*$")) | .name_value' | sort -u

This strips out AWS CloudFront certificates (commonly used by CDN services) and shows you unique domain names that received certificates. You are looking for names that do not belong to your infrastructure — a staging subdomain you forgot about, a wildcard issued to a team you did not know existed, or a completely bogus name like login-example.com that someone registered and got a certificate for.

Our CT log search tool provides a structured interface for these queries, with filtering, deduplication, and CSV export. Use it to run weekly checks across your entire domain portfolio.

What a Rogue Certificate Looks Like

CT monitoring yields results in three categories:

Expected certificates. These match your known infrastructure — your primary domain, www, mail, api, and any subdomains you have provisioned certificates for. Their issuers should be the CAs you use (DigiCert, Sectigo, Let's Encrypt, AWS ACM, etc.). Timestamps should align with your renewal schedule. No action needed.

Shadow IT certificates. These are legitimate certificates issued for your domain, but by teams or services you did not know about. Common culprits: a marketing team sets up a landing page on a third-party platform, a developer uses a PaaS that auto-provisions HTTPS, or a contractor deploys a test environment behind a valid certificate. These are not malicious, but they represent unmanaged infrastructure that needs to be brought into your certificate lifecycle management.

Unauthorized certificates. These are certificates you did not request, for domains you control, issued by CAs you do not use. This is the alert condition. It means someone obtained a certificate that can be used to impersonate your domain in a TLS handshake. The most common cause is ACME account compromise — an attacker gains access to your DNS or web server just long enough to complete a domain validation challenge, obtains a certificate, and then leaves. The certificate remains valid for up to 90 days and can be used for man-in-the-middle attacks without any further access to your infrastructure.

Automating CT Monitoring

Manual lookups do not scale. You need a system that queries CT logs on a schedule and alerts on any certificate that does not match your expected pattern. Here is a minimal monitoring script:

#!/bin/bash
DOMAINS="example.com example.org"
KNOWN_CAS="DigiCert|Sectigo|Let's Encrypt|Amazon"
ALERT_LOG="/var/log/ct-alerts.log"

for domain in $DOMAINS; do
    certs=$(curl -s "https://crt.sh/?q=%25.${domain}&output=json" 2>/dev/null)
    echo "$certs" | jq -r '.[].issuer_name' | while read -r issuer; do
        if ! echo "$issuer" | grep -qE "$KNOWN_CAS"; then
            echo "[ALERT] $(date): Unknown CA issued cert for $domain: $issuer" | tee -a "$ALERT_LOG"
        fi
    done
    echo "$certs" | jq -r '.[].name_value' | sort -u | while read -r name; do
        if echo "$name" | grep -qiE '(login|account|secure|verify|update|confirm|billing)'; then
            echo "[WARN] $(date): High-risk subdomain: $name" | tee -a "$ALERT_LOG"
        fi
    done
done

This script checks each domain against CT logs, flags certificates from unrecognized CAs, and specifically highlights subdomains containing high-value phishing keywords. Run it from cron daily. Wire the output into your SIEM or incident response pipeline so alerts do not rot in a log file.

Certificate Details: Beyond the Log Entry

A CT log entry tells you a certificate exists. To understand the risk, you need the full certificate details. Pull the certificate and inspect it:

# Fetch the raw certificate from crt.sh by its ID
curl -s 'https://crt.sh/?d=1234567890' | openssl x509 -text -noout

Replace 1234567890 with the certificate ID from the crt.sh JSON output. This returns the full X.509 structure, including:

Validity period: A 90-day certificate with 88 days remaining buys an attacker nearly three months of impersonation capability.
Key type and size: ECDSA P-256 is standard. RSA 2048 is acceptable. RSA 1024 or smaller indicates either legacy infrastructure or an attacker using weak keys.
SAN extension: A certificate covering example.com, paypal.com, and login-microsoft.com is definitively malicious — no legitimate CA would issue such a multi-tenant certificate without explicit organizational validation.
CRL and OCSP endpoints: An empty or invalid CRL distribution point suggests the attacker does not intend the certificate to participate in revocation infrastructure.

Use our SSL certificate checker to perform this analysis on any certificate you find in CT logs. It validates the chain, checks revocation status via OCSP, and flags structural anomalies that suggest misuse.

Responding to a Rogue Certificate

If you find an unauthorized certificate for your domain, the immediate priority is revocation. Certificate revocation is a two-step process: you must ask the issuing CA to revoke the certificate, and you must confirm that browsers actually enforce the revocation.

Step one: identify the issuing CA from the certificate's Issuer field. Contact their abuse or revocation desk — every publicly trusted CA is required to operate a 24-hour revocation contact under CA/Browser Forum baseline requirements. Provide the certificate serial number and explain that the certificate was issued without authorization.

Step two: understand that revocation is probabilistic. Chrome does not check OCSP or CRLs for most certificates by default; it relies on CRLSets and its own blocklist mechanisms. Firefox checks OCSP for EV certificates and some DV certificates, but not all. Even after revocation, the certificate may remain usable for some clients depending on browser policy. The only complete defense is to prevent issuance in the first place.

Preventing Misissuance

CT monitoring detects problems; CAA records prevent them. A Certification Authority Authorization (CAA) DNS record tells CAs which authorities are permitted to issue certificates for your domain:

dig +short example.com CAA

A properly configured CAA record looks like:

example.com. 3600 IN CAA 0 issue "letsencrypt.org"
example.com. 3600 IN CAA 0 issue "digicert.com"

Each record specifies a CA by its domain name and a flags byte (0 for non-critical). CAs are required to check CAA records before issuing a certificate. If letsencrypt.org is not listed, Let's Encrypt must refuse issuance. If no CAA record exists, any CA may issue. Every domain should have a CAA record that whitelists its approved CAs.

You can also publish an issuewild record to control which CAs may issue wildcard certificates, and an iodef record to specify a contact URL or email for misissuance reports:

example.com. 3600 IN CAA 0 issuewild "digicert.com"
example.com. 3600 IN CAA 0 iodef "mailto:security@example.com"

Combine CAA records with CT monitoring for a defense-in-depth posture. CAA prevents compliant CAs from mis-issuing. CT monitoring catches non-compliant CAs, ACME account compromises, and issuance that slips through CAA for any reason. Together, they close the loop on certificate misissuance.

Certificate Transparency turned an opaque system into an observable one. Before CT, certificates appeared and disappeared in silence. Now every certificate is a matter of public record. Search the logs for your domains today — you may be surprised by what you find.

← Back to Blog