How to Monitor Certificate Transparency for Better Security Compliance

What Certificate Transparency Actually Is (And Why Developers Should Care)

Certificate Transparency (CT) has been a quiet but critical piece of web security infrastructure since Google mandated it for all publicly trusted TLS certificates in 2018. Yet despite its importance, many developers and site owners have only a vague understanding of how it works, what it protects against, and how to actually monitor it for their own domains. With Cloudflare's CT Monitoring now generally available — and notably, no longer alerting you about certificates Cloudflare itself issues — it's worth taking a deep dive into the mechanics of certificate transparency and building a practical monitoring strategy around it.

How Certificate Transparency Logs Work

At its core, Certificate Transparency is a public, append-only ledger of TLS certificates. When a Certificate Authority (CA) issues a certificate, it must submit that certificate to at least two independent CT logs before it can be trusted by major browsers. Each log returns a Signed Certificate Timestamp (SCT), which is a cryptographic promise that the certificate has been recorded.

These logs are maintained by various organizations including Google, Cloudflare, DigiCert, and others. They're publicly queryable, meaning anyone — including attackers, researchers, and you — can search for certificates issued to any domain.

The Three Delivery Mechanisms for SCTs

There are three ways an SCT can be delivered to a browser:

Embedded in the certificate itself — The CA submits the certificate to a log before issuance and embeds the SCT in the final cert. This is the most common method.
Via TLS extension — The server delivers the SCT during the TLS handshake using the signed_certificate_timestamp TLS extension.
Via OCSP stapling — The SCT is included in the OCSP response stapled to the TLS handshake.

Most modern CAs use the embedded approach because it requires no server-side configuration. From a developer's perspective, this means your certificate is already in a public log the moment it's issued — which is both a transparency feature and a surveillance surface.

Why Certificate Transparency Monitoring Matters for Security

The public nature of CT logs creates a powerful early-warning system. Here's what you can detect by monitoring CT logs for your domain:

Unauthorized Certificate Issuance

This is the primary threat model. If an attacker compromises a CA (or social engineers one), they might issue a certificate for your domain without your knowledge. With that certificate, they could:

Conduct man-in-the-middle attacks on your users
Serve convincing phishing pages under your domain
Intercept API traffic if they can also manipulate DNS

CT monitoring means you'll know about a rogue certificate within minutes of issuance, not months later when a security researcher stumbles across it.

Subdomain Discovery and Exposure

Every certificate issued for *.yourdomain.com or specific subdomains like staging.yourdomain.com appears in CT logs. This is a double-edged sword: it's useful for your own inventory management, but it also means attackers actively query CT logs to discover internal or staging subdomains that might be less hardened than production.

Tools like crt.sh and certspotter are commonly used by both security teams and attackers for exactly this purpose.

CA Compliance Verification

CT logs let you verify that your CA is following proper issuance procedures. You can check whether certificates for your domain were issued by CAs you've authorized, and whether those certificates comply with the CA/Browser Forum baseline requirements.

Setting Up Your Own Certificate Transparency Monitoring

While third-party services handle the heavy lifting, understanding the underlying process helps you build a more robust monitoring strategy.

Querying CT Logs Directly

The most direct approach is querying CT logs via their APIs. The crt.sh aggregator provides a simple JSON API:

curl "https://crt.sh/?q=yourdomain.com&output=json" | jq '.[] | {id: .id, issuer: .issuer_name, name: .name_value, date: .entry_timestamp}'

This returns all certificates ever issued for your domain, including expired ones. For ongoing monitoring, you'd want to filter by not_before date and set up a cron job or webhook-based system.

Using the Certspotter API

Certspotter, run by SSLMate, offers a more developer-friendly monitoring API:

# Get issuances for a domain
curl "https://api.certspotter.com/v1/issuances?domain=yourdomain.com&include_subdomains=true&expand=dns_names&expand=issuer&expand=cert" \
  -u "your-api-token:"

You can set up webhook notifications so that new certificate issuances trigger a POST request to your endpoint, enabling real-time alerting.

Building a Simple Monitoring Script

Here's a basic Python script that checks for new certificates and alerts you:

import requests
import json
from datetime import datetime, timedelta

DOMAIN = "yourdomain.com"
ALERT_EMAIL = "[email protected]"
KNOWN_ISSUERS = ["Let's Encrypt", "DigiCert", "Cloudflare"]

def check_new_certs():
    since = (datetime.utcnow() - timedelta(hours=24)).strftime("%Y-%m-%dT%H:%M:%S")
    
    url = f"https://crt.sh/?q={DOMAIN}&output=json"
    response = requests.get(url, timeout=30)
    certs = response.json()
    
    recent_certs = [
        cert for cert in certs 
        if cert.get('entry_timestamp', '') > since
    ]
    
    for cert in recent_certs:
        issuer = cert.get('issuer_name', '')
        name = cert.get('name_value', '')
        
        # Check if issuer is unexpected
        if not any(known in issuer for known in KNOWN_ISSUERS):
            send_alert(f"Unexpected issuer: {issuer} for {name}")
            
    return recent_certs

def send_alert(message):
    # Integrate with your alerting system (PagerDuty, Slack, etc.)
    print(f"ALERT: {message}")

if __name__ == "__main__":
    new_certs = check_new_certs()
    print(f"Found {len(new_certs)} new certificates in the last 24 hours")

Implementing CAA Records: Your First Line of Defense

Certificate Transparency monitoring is reactive — it tells you after a certificate has been issued. CAA (Certification Authority Authorization) DNS records are proactive — they tell CAs which ones are allowed to issue certificates for your domain in the first place.

yourdomain.com.  CAA  0 issue "letsencrypt.org"
yourdomain.com.  CAA  0 issue "digicert.com"
yourdomain.com.  CAA  0 issuewild "digicert.com"
yourdomain.com.  CAA  0 iodef "mailto:[email protected]"

The iodef tag is particularly useful — it tells CAs to send you a report if they receive a certificate request for your domain that violates your CAA policy. Not all CAs honor this, but major ones do.

You can verify your CAA records are properly configured using the DNS Lookup tool, which lets you query specific record types and see exactly what resolvers see when they look up your domain.

CAA Record Best Practices

Be specific: Only authorize CAs you actually use. If you only use Let's Encrypt, don't leave the field open.
Separate wildcard authorization: Use issuewild to control wildcard certificate issuance separately from regular certificates.
Include iodef: Even if not all CAs honor it, the ones that do will send you valuable signals.
Audit regularly: When you switch CAs, update your CAA records immediately.

Understanding the Cloudflare CT Monitoring Change

The significant operational change in Cloudflare's CT Monitoring going GA is subtle but important: Cloudflare no longer sends you alerts for certificates it issued itself.

Previously, if Cloudflare issued a certificate for your domain (which it does automatically for domains on its network), you'd receive an alert about it. This created alert fatigue — developers would see the notifications, realize it was just Cloudflare doing its normal thing, and start ignoring or filtering the alerts entirely. That's a dangerous habit when the whole point of CT monitoring is to catch unexpected certificates.

By filtering out its own issuances, Cloudflare has made its monitoring tool significantly more actionable. When you receive an alert now, it means a certificate was issued by a CA other than Cloudflare for your domain — which is either expected (you use multiple CAs) or potentially worth investigating.

This is a good model for any CT monitoring setup: reduce noise ruthlessly. An alert system that cries wolf trains humans to ignore it.

You can check whether Cloudflare is active on your domain using the Cloudflare Detection tool, which identifies Cloudflare-specific headers, IP ranges, and configuration signals.

Integrating CT Monitoring with Your Security Workflow

Monitoring is only valuable if it connects to an actionable response process. Here's how to integrate CT alerts into a practical security workflow.

Triage Framework for CT Alerts

When you receive a CT alert, work through these questions:

Is the issuer one you've authorized? Cross-reference against your CAA records and your known CA relationships.
Is the domain name expected? A certificate for api.yourdomain.com might be fine; one for secure-login.yourdomain.com that you don't recognize is concerning.
Does the certificate appear in your internal inventory? If you maintain a certificate inventory (you should), check whether this cert is tracked.
What's the certificate's validity period? Very short-lived certificates from unexpected issuers can indicate automated abuse.

Certificate Inventory Management

Maintaining a certificate inventory sounds tedious but pays dividends. At minimum, track:

Domain and SANs covered
Issuing CA
Expiration date
Who requested it and why
Where it's deployed

You can bootstrap this inventory by querying CT logs for your domain's full history. The SSL Certificate Checker tool can help you verify the details of certificates currently deployed on your domains, including the issuer chain, expiration date, and whether the certificate matches what you expect to see.

Incident Response for Rogue Certificates

If you identify a certificate you didn't authorize:

Don't panic, but act quickly. CT log entry doesn't mean the certificate is being used yet.
Contact the issuing CA immediately. All publicly trusted CAs have a revocation process. Under CA/Browser Forum rules, they must revoke a mis-issued certificate within 24 hours of confirmation.
Check your DNS for hijacking. A rogue certificate is often paired with DNS manipulation. Use the DNS Lookup tool to verify your current DNS records match what you expect.
Review your CAA records. Understand how the issuance was possible and tighten your CAA configuration.
File a report with Google's CT policy team if the CA appears to have violated baseline requirements.

The Broader SSL/TLS Security Picture

Certificate Transparency monitoring doesn't exist in isolation. It's one layer of a multi-layered TLS security strategy.

HSTS and HSTS Preloading

HTTP Strict Transport Security tells browsers to only connect to your domain over HTTPS, and preloading takes this further by hardcoding your domain into browsers before any connection is made. This limits the attack window even if a rogue certificate exists.

Strict-Transport-Security: max-age=63072000; includeSubDomains; preload

Certificate Pinning (With Caution)

HTTP Public Key Pinning (HPKP) was deprecated due to the risk of bricking your site if you lost control of your pinned key. However, certificate pinning in native mobile apps and API clients remains a valid technique when implemented carefully with backup pins.

DANE (DNS-Based Authentication of Named Entities)

DANE uses DNSSEC-signed DNS records to publish information about your TLS certificates, providing an alternative trust path that doesn't rely solely on the CA system. It's not widely supported in browsers but is used in email security (SMTP MTA-STS and DANE for SMTP).

Monitoring Your SEO and Security Headers Alongside SSL

While you're building out your security monitoring stack, it's worth noting that TLS certificate issues often have downstream effects on SEO and site performance. A certificate error causes browsers to show scary warnings, which tanks user trust and can affect crawl rates.

Running a regular SEO Audit alongside your certificate monitoring helps you catch cases where SSL issues might be affecting how search engines see your site — for example, if a certificate problem caused a period of downtime or mixed-content warnings that affected indexed pages.

Automating CT Log Monitoring at Scale

For organizations managing many domains, manual monitoring doesn't scale. Here are approaches for larger deployments:

Using a SIEM Integration

Feed CT log alerts into your SIEM (Splunk, Elastic, etc.) alongside other security signals. This lets you correlate certificate issuance events with other indicators — for example, a new certificate for a subdomain followed by a spike in traffic to that subdomain is a stronger signal than either event alone.

Domain Portfolio Management

If you manage dozens or hundreds of domains, consider a dedicated certificate monitoring service that supports bulk domain configuration. Most commercial options (CertSpotter, Facebook's CT monitoring, various SIEM integrations) support this.

Automated CAA Auditing

Build automated checks that verify your CAA records match your intended CA policy across all your domains. DNS misconfigurations can silently open up unauthorized issuance pathways.

Conclusion

Certificate Transparency monitoring is a mature, practical security control that every organization with a public web presence should have in place. The combination of CT monitoring, properly configured CAA records, and a clear incident response process gives you meaningful visibility into one of the most critical aspects of your site's security posture.

Cloudflare's decision to filter out its own certificate issuances from alerts is a good reminder that the value of any monitoring system comes from the signal-to-noise ratio, not just coverage. Build your monitoring to alert on anomalies, not routine operations.

If you're ready to audit your current SSL configuration, check your DNS records, or run a comprehensive security review of your domains, OpDeck provides a suite of tools to help — from the SSL Certificate Checker and DNS Lookup to the Vulnerability Scanner for checking security headers and common misconfigurations. Start with a baseline audit today and know exactly what the public internet sees when it looks at your domain.