Certificate Transparency Monitoring for Defenders

Certificate Transparency records public issuance for audit

Certificate Transparency monitoring finds certificates and precertificates containing names an organization cares about. RFC 9162 Certificate Transparency protocol defines public append-only logs intended to make certificate-authority activity auditable and suspect issuance discoverable.

A log entry establishes that a particular certificate chain or precertificate was submitted to a particular log. It does not prove that the certificate was deployed, that the named organization requested it, that the holder controls every named domain now, or that the certificate is malicious. CT logs themselves do not decide whether issuance was authorized.

Coverage is also bounded. The system focuses on public TLS certificates chaining to trust anchors accepted by logs. Private PKI, self-signed certificates, SSH keys, code-signing certificates, and some enterprise trust arrangements require separate inventories. Keep these HTTPS certificate trust boundaries explicit.

Normalize certificate fields while preserving log provenance

Retain the raw certificate or precertificate entry and parse it with a maintained X.509 library. Record log identity, entry index, observed time, SCT timestamp where available, issuer, serial, subject, every SAN, validity, signature algorithm, SPKI fingerprint, certificate fingerprint, chain, and whether the item is a precertificate or final certificate.

This is an authored, abbreviated monitor event—not a live CT record:

{
  "observed_at": "2026-11-10T14:32:11Z",
  "log_id": "<base64-redacted>",
  "entry_index": 481902311,
  "entry_type": "precertificate",
  "issuer": "Example Public CA R3",
  "dns_names": ["login.example.org", "api.example.org"],
  "not_before": "2026-11-10T00:00:00Z",
  "not_after": "2027-02-08T23:59:59Z",
  "spki_sha256": "<hex-redacted>"
}

Logging time is not necessarily issuance time, deployment time, or first malicious use. Preserve all distinct timestamps and source semantics. Normalize internationalized names to both Unicode display and ASCII A-label forms, but retain the original SAN bytes for evidence.

Match owned names without flooding analysts with expected issuance

Build the watch scope from authoritative domain inventory, subsidiaries, acquisitions, protected brands, critical hostnames, delegated zones, and known third-party service patterns. Match exact names and subdomains intentionally. A wildcard certificate name, wildcard monitoring rule, and substring brand match have different semantics and false-positive rates.

Baseline approved issuers, ACME accounts, certificate automation, CDNs, hosting providers, key fingerprints, name bundles, validity patterns, and renewal cadence. Alert on an unapproved issuer, sensitive hostname, unexpected wildcard, novel SAN co-occurrence, changed SPKI outside planned rotation, issuance after a domain should be retired, or a certificate for a look-alike name. Brand similarity is a discovery lead, not proof that your organization owns the domain.

Maintain log-list health. Chrome Certificate Transparency log lists distinguish known log states and are updated regularly, but Chrome warns against unsupported reliance for third-party CT enforcement. A monitor needs documented source coverage, cached state, deduplication, lag metrics, and failure alerts.

Corroborate unexpected issuance before enforcement

Ask the domain and certificate owners whether the issuer, names, key, and timing match approved automation or a change. Check certificate-management records, ACME account activity, DNS changes, registrar audit, cloud/CDN configuration, current TLS handshakes, and deployment inventories. Use passive DNS and WHOIS evidence only for bounded temporal relationships.

Separate four cases: authorized and expected; authorized but undocumented; unauthorized issuance with no evidence of deployment; and unauthorized issuance with key or domain-control compromise. Each needs a different owner and urgency. A certificate for a phishing look-alike domain is usually a brand-abuse lead, not certificate misissuance for an owned domain.

Apply CTI source evaluation and corroboration: preserve provenance, distinguish independent sources, state collection gaps, and write the narrowest conclusion supported. Repetition across CT aggregation services may trace back to the same log entry and is not independent confirmation.

Revoke unauthorized certificates and repair the issuance path

Preserve the log entry, certificate chain, fingerprints, owner validation, DNS and registrar state, CA case identifiers, and any observed deployment before making changes. Contact the issuing CA through its documented incident or revocation channel and provide proof of domain authority and the exact certificate identifiers.

Revoke the certificate, but also correct how it was issued. Secure compromised DNS, registrar, ACME, cloud, email, or CA accounts; remove unauthorized validation records; rotate the private key when its custody is uncertain; and inspect other certificates created through the same account or validation path. Revocation behavior varies across clients, so do not treat a submitted revocation request as immediate universal containment.

If legitimate services share an account, key, or wildcard certificate, emergency rotation can cause outages. Inventory dependencies, stage replacement certificates, verify deployment, then retire old material. For active abuse, isolate affected routes and coordinate browser, hosting, registrar, and law-enforcement actions according to incident authority.

Turn CT alerts into a rehearsed issuance-control loop

Next step: select one owned domain and document its authorized issuers, certificate automation, account owners, DNS validation paths, expected names, key-rotation behavior, and revocation contacts. Feed those facts into the monitor and test one approved certificate issuance in a non-production name.

Confirm that the alert preserves the source entry, matches the correct domain rule, reaches an accountable owner, and closes with authorization evidence. Then run an authored tabletop for an unrecognized issuer—without obtaining a deceptive certificate or modifying production DNS. The durable control is current coverage, low-noise authorization baselines, defensible claims, and a response path that fixes both the certificate and the issuance weakness.