High-Assurance Certificate Transparency Monitoring with Red Sift Certificates

Public PKI and digital certificates provide an acceptable baseline for most internet properties, but some carry far greater risk than others. Properties like your application login page, payment flows, corporate domains, and anything that could damage your brand if impersonated are prime targets for attackers. Those properties must be protected by actively building defenses using technologies such as Certificate Transparency (CT) and CAA. While we've gone into great detail before on High-Assurance CT, we wanted to focus on the practical aspects of detecting unauthorized issuances, applying available prevention mechanisms, and configuring high-assurance monitoring with Red Sift Certificates.

Certificate Transparency (CT) is an open standard that requires publicly trusted Certificate Authorities (CAs) to log every certificate they issue to publicly auditable append-only logs. As a result, any certificate issued for your domain is visible to anyone.

CT was designed to address a fundamental weakness in Public PKI: any CA in the trust store can technically issue a certificate for any domain. It doesn't prevent this, but it makes unauthorized issuances detectable. Red Sift has been ingesting and processing CT logs since 2017, building one of the most comprehensive certificate discovery data stores available.

The first line of defense is prevention, and that starts with a DNS CAA (Certification Authority Authorization) policy. A CAA policy lets you declare which CAs are permitted to issue certificates for your domain. Without a policy, any CA can issue a certificate for your properties. Even a basic CAA configuration dramatically reduces your attack surface.

Recommended baseline: Basic CAA policy with default CT monitoring settings.

Defining a CAA policy. Now, let's set up a CAA policy with Red Sift Certificates. Before locking anything down, find out who's currently issuing for your domains. Otherwise, a new record could break legitimate issuance overnight. The Issuer facet on the Certificates page surfaces this instantly. Filtering on "Hostnames contains redsift.com", for example, returns Let's Encrypt (114), Google Trust Services (34), Sectigo (24), and Amazon (4).

That list translates directly into a CAA policy that you need to set up on your DNS record:

redsift.com.  CAA  0  issue      "letsencrypt.org"
redsift.com.  CAA  0  issue      "pki.goog"
redsift.com.  CAA  0  issue      "sectigo.com"
redsift.com.  CAA  0  issue      "amazon.com"
redsift.com.  CAA  0  issuewild  "letsencrypt.org"
redsift.com.  CAA  0  issuewild  "pki.goog"
redsift.com.  CAA  0  issuewild  "sectigo.com"
redsift.com.  CAA  0  iodef      "mailto:security@redsift.com"

issue covers regular certificates, and issuewild covers wildcards. Tighten the wildcard list to only the CAs you actually use for wildcard issuance; the "wildcard" filter in Red Sift Certificates, combined with a "hostnames" filter, shows your current wildcard usage. Need some help with the identifier domains? You can use this CAA generator to look up the correct identifier domain for each CA.

CAs are required to check and honor CAA records before issuance. Should a discovered certificate violate your CAA policy, Red Sift Certificates will flag the CAA configuration issue (for example, like a malformed CAA record or missing property) and push an alert to you for visibility.

CAA prevents compliant CAs from issuing unauthorized certificates, but it doesn't stop a compromised or rogue CA. CT monitoring is how you detect what CAA can't prevent.

Red Sift Certificates continuously monitors CT logs and creates a case for every newly discovered certificate that matches your domains. Each case is automatically evaluated against a set of closing and escalation rules to determine whether the certificate is legitimate, unexpected, or a potential indicator of compromise.

Closing rules automatically resolve cases where there is sufficient evidence that the certificate is legitimate:

Standard CT monitoring flags anomalies reactively. High-Assurance CT Monitoring takes a more rigorous approach: it builds a complete inventory of every certificate you own, then treats anything in CT logs that isn't in that inventory as suspicious by default.

This requires two things:

1. A complete "known-good" inventory. Built by importing certificates via CA integrations or the Create Certificate API. Every imported certificate is automatically marked as endorsed (known to be under your control).
2. Tight escalation rules. Configured to escalate any certificate that isn't accounted for within a short window.

Note: CT logs have an inherent merge delay, up to 24 hours for some logs. Red Sift processes certificates as they appear in CT logs, in near real time but not instantly.

Certificate Transparency turns an invisible risk, where any CA can issue for any domain, into a publicly auditable signal. But raw CT data is noisy; turning it into a reliable early-warning system requires a known-good inventory, sensible closing rules, and tight escalation thresholds.

Red Sift Certificates brings these three layers together in one place: CAA policy enforcement, continuous CT monitoring, and high-assurance escalation backed by nearly a decade of CT log ingestion. Start with the recommended baseline, then tighten escalation rules on your highest-value domains as your known-good inventory matures.