auditing-tls-certificate-transparency-logs

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Auditing TLS Certificate Transparency Logs

审计TLS证书透明度（CT）日志

When to Use

适用场景

Monitoring owned domains for unauthorized or unexpected certificate issuance by unknown Certificate Authorities
Discovering subdomains and hidden services through certificates logged in public CT logs
Detecting phishing infrastructure that uses look-alike domain certificates (typosquatting, homograph attacks)
Auditing Certificate Authority compliance by verifying all issued certificates appear in CT logs as required by browser policies
Building continuous certificate monitoring into a security operations pipeline with alerting for new issuances

Do not use for attacking or disrupting Certificate Authorities, for scraping CT logs in violation of rate limits or terms of service, or as the sole method of subdomain enumeration without corroborating results through DNS verification.

监控自有域名，检测未知证书颁发机构（CA）进行的未授权或意外证书颁发
通过公共CT日志中记录的证书发现子域名和隐藏服务
检测使用相似域名证书的钓鱼基础设施（域名仿冒、同形异义字攻击）
通过验证所有已颁发证书是否按浏览器政策要求出现在CT日志中，审计证书颁发机构的合规性
在安全运营流程中构建持续证书监控，并为新证书颁发设置警报

请勿用于攻击或干扰证书颁发机构、违反速率限制或服务条款抓取CT日志，或作为唯一的子域名枚举方法而不通过DNS验证确认结果。

Prerequisites

前置条件

Python 3.10+ with
```
requests
```
,
```
cryptography
```
, and
```
pyOpenSSL
```
libraries installed
Network access to crt.sh (HTTPS) and public CT log servers
A list of domains to monitor (owned domains, brand variations, typosquat candidates)
SMTP credentials or webhook URL for alerting on new certificate discoveries
Basic understanding of X.509 certificate structure and TLS certificate chain validation

安装了
```
requests
```
、
```
cryptography
```
和
```
pyOpenSSL
```
库的Python 3.10+环境
可访问crt.sh（HTTPS）和公共CT日志服务器的网络权限
待监控的域名列表（自有域名、品牌变体、疑似仿冒域名）
用于新证书发现警报的SMTP凭据或Webhook URL
对X.509证书结构和TLS证书链验证的基本理解

Workflow

工作流程

Step 1: Domain Inventory and Baseline

步骤1：域名清单与基线建立

Build the initial certificate inventory for monitored domains:

Define monitoring scope: List all owned root domains, registered brand names, and known subsidiaries. Include wildcard patterns (
```
%.example.com
```
) for comprehensive subdomain coverage.
Query crt.sh for historical certificates: Use the crt.sh JSON API to retrieve all known certificates for each domain. The API endpoint
```
https://crt.sh/?q=%.example.com&output=json
```
returns certificates matching the wildcard pattern with fields including
```
issuer_ca_id
```
,
```
issuer_name
```
,
```
common_name
```
,
```
name_value
```
,
```
not_before
```
,
```
not_after
```
, and
```
serial_number
```
.
Build baseline database: Store the initial certificate set in a local SQLite database with columns for certificate ID, domain, issuer, validity dates, SANs (Subject Alternative Names), and first-seen timestamp. This baseline prevents alerting on already-known certificates.
Identify authorized CAs: From the baseline, extract the set of Certificate Authorities that have legitimately issued certificates for your domains. Any future issuance from a CA not in this set triggers a high-priority alert.
Map subdomains: Extract all unique subdomains from the
```
name_value
```
field across all certificates to build an initial subdomain inventory.

为监控域名构建初始证书清单：

定义监控范围：列出所有自有根域名、已注册品牌名称及已知子公司。包含通配符模式（
```
%.example.com
```
）以全面覆盖子域名。
查询crt.sh获取历史证书：使用crt.sh JSON API检索每个域名的所有已知证书。API端点
```
https://crt.sh/?q=%.example.com&output=json
```
返回匹配通配符模式的证书，字段包括
```
issuer_ca_id
```
、
```
issuer_name
```
、
```
common_name
```
、
```
name_value
```
、
```
not_before
```
、
```
not_after
```
和
```
serial_number
```
。
构建基线数据库：将初始证书集存储在本地SQLite数据库中，列包含证书ID、域名、颁发机构、有效期、SAN（主题备用名称）和首次发现时间戳。该基线可避免对已知证书发出警报。
识别授权CA：从基线中提取曾合法为您的域名颁发证书的证书颁发机构集合。未来任何来自该集合外CA的证书颁发都会触发高优先级警报。
映射子域名：从所有证书的
```
name_value
```
字段中提取所有唯一子域名，构建初始子域名清单。

Step 2: Continuous CT Log Monitoring

步骤2：持续CT日志监控

Set up ongoing monitoring for new certificate issuances:

Poll crt.sh periodically: Query the crt.sh API at regular intervals (every 15-60 minutes) for new certificates. Use the
```
exclude=expired
```
parameter to focus on currently valid certificates. Compare results against the baseline database to identify new entries.
Parse certificate details: For each new certificate, extract the full SAN list, issuer chain, validity period, key type and size, CT log SCT (Signed Certificate Timestamp) details, and certificate fingerprint (SHA-256).
Detect precertificates: CT logs include precertificates (poisoned certificates submitted before final issuance). Track these as early warnings since they indicate a certificate is about to be issued but may not yet be active.
Monitor CT log Signed Tree Heads (STH): For advanced monitoring, query CT log servers directly to fetch the latest STH and verify consistency proofs between consecutive tree heads. An inconsistency indicates log misbehavior (split-view attack).
Rate limiting awareness: Respect crt.sh rate limits by spacing queries and caching responses. Implement exponential backoff on HTTP 429 responses. For high-volume monitoring, consider querying the crt.sh PostgreSQL interface directly at
```
crt.sh:5432
```
.
Atom/RSS feed alternative: Subscribe to crt.sh's Atom feed for lighter-weight monitoring:
```
https://crt.sh/atom?q=%25.example.com
```
provides real-time notification of new log entries.

设置对新证书颁发的持续监控：

定期轮询crt.sh：按固定间隔（15-60分钟）查询crt.sh API获取新证书。使用
```
exclude=expired
```
参数聚焦当前有效的证书。将结果与基线数据库对比，识别新条目。
解析证书详情：对于每个新证书，提取完整SAN列表、颁发链、有效期、密钥类型和大小、CT日志SCT（签名证书时间戳）详情以及证书指纹（SHA-256）。
检测预证书：CT日志包含预证书（最终颁发前提交的带毒证书）。将其作为早期预警跟踪，因为它们表明证书即将颁发但可能尚未激活。
监控CT日志签名树头（STH）：对于高级监控，直接查询CT日志服务器获取最新STH，并验证连续树头之间的一致性证明。不一致性表明日志存在异常行为（分视图攻击）。
注意速率限制：通过间隔查询和缓存响应遵守crt.sh的速率限制。对HTTP 429响应实现指数退避。对于高容量监控，考虑直接查询crt.sh的PostgreSQL接口
```
crt.sh:5432
```
。
Atom/RSS源替代方案：订阅crt.sh的Atom源实现轻量级监控：
```
https://crt.sh/atom?q=%25.example.com
```
提供新日志条目的实时通知。

Step 3: Subdomain Discovery via CT Data

步骤3：通过CT数据发现子域名

Extract and validate subdomains found in certificate transparency data:

Wildcard expansion: Certificates with wildcard SANs (
```
*.dev.example.com
```
) reveal the existence of subdomains that may not be in DNS zone files. Record the parent domain as a target for further enumeration.
Historical certificate mining: Query crt.sh without the
```
exclude=expired
```
parameter to find subdomains from expired certificates that may still resolve in DNS. These represent historical infrastructure that could be vulnerable to subdomain takeover.
DNS validation: For each discovered subdomain, perform DNS resolution (A, AAAA, CNAME records) to determine if the subdomain is currently active. Cross-reference with known IP ranges to identify shadow IT or unauthorized services.
Typosquat detection: Generate permutations of the monitored domain (bitsquatting, homograph, insertion, omission, transposition, keyboard-adjacent replacement) and query CT logs for certificates issued to these variations. Certificates for typosquat domains strongly indicate phishing infrastructure.
Deduplication and enrichment: Normalize discovered subdomains (lowercase, remove trailing dots), deduplicate, and enrich with WHOIS data, IP geolocation, and HTTP response headers to prioritize investigation.

提取并验证证书透明度数据中的子域名：

通配符扩展：带有通配符SAN的证书（
```
*.dev.example.com
```
）揭示了可能不在DNS区域文件中的子域名存在。记录父域名作为进一步枚举的目标。
历史证书挖掘：不使用
```
exclude=expired
```
参数查询crt.sh，从过期证书中查找可能仍在DNS中解析的子域名。这些代表可能存在子域名接管风险的历史基础设施。
DNS验证：对于每个发现的子域名，执行DNS解析（A、AAAA、CNAME记录）以确定子域名当前是否活跃。与已知IP范围交叉引用，识别影子IT或未授权服务。
仿冒域名检测：生成监控域名的变体（位翻转、同形异义字、插入、遗漏、换位、键盘相邻替换），并查询CT日志是否有针对这些变体颁发的证书。仿冒域名的证书强烈表明存在钓鱼基础设施。
去重与丰富信息：标准化发现的子域名（小写、移除末尾点）、去重，并补充WHOIS数据、IP地理位置和HTTP响应头，以优先处理调查。

Step 4: Certificate Issuance Alerting

步骤4：证书颁发警报

Configure alerting rules for security-relevant certificate events:

Unauthorized CA alert: Trigger when a certificate is issued by a CA not in the authorized CA list. This is the highest-priority alert as it may indicate domain hijacking, BGP hijacking for domain validation, or a compromised CA.
New subdomain alert: Trigger when a certificate contains a SAN with a previously unseen subdomain. This catches shadow IT deployments and unauthorized services.
Wildcard certificate alert: Trigger on any new wildcard certificate issuance, as wildcard certificates have broader impact if compromised and their issuance should be tightly controlled.
Short-lived certificate anomaly: Alert when certificates have unusually short validity periods (under 24 hours) that deviate from the organization's normal certificate lifecycle, as this may indicate Let's Encrypt abuse or automated phishing infrastructure.
Expiration warning: Alert when certificates for critical services approach expiration (30, 14, 7 days) based on the
```
not_after
```
field from CT log data.
Alert delivery: Send alerts via email (SMTP), Slack webhook, PagerDuty, or write to a SIEM-compatible JSON log format for integration with existing security monitoring.

为安全相关的证书事件配置警报规则：

未授权CA警报：当证书由授权CA列表外的机构颁发时触发。这是最高优先级警报，可能表明域名劫持、用于域名验证的BGP劫持或CA被攻陷。
新子域名警报：当证书包含从未出现过的子域名SAN时触发。这会捕获影子IT部署和未授权服务。
通配符证书警报：对任何新的通配符证书颁发触发警报，因为通配符证书若被攻陷影响范围更广，其颁发应受到严格控制。
短期证书异常警报：当证书有效期异常短（不足24小时）且偏离组织正常证书生命周期时触发，这可能表明Let's Encrypt被滥用或存在自动化钓鱼基础设施。
过期警告：当关键服务的证书接近过期时（基于CT日志数据的
```
not_after
```
字段，提前30、14、7天）触发警报。
警报交付：通过电子邮件（SMTP）、Slack Webhook、PagerDuty发送警报，或写入兼容SIEM的JSON日志格式，与现有安全监控集成。

Step 5: CT Log Integrity Verification and Reporting

步骤5：CT日志完整性验证与报告

Verify log integrity and produce compliance evidence:

Signed Tree Head (STH) monitoring: Fetch the latest STH from each monitored CT log via the
```
get-sth
```
API endpoint. The STH contains the tree size and a signed timestamp. Verify the signature using the log's public key.
Consistency proof verification: Between consecutive STH fetches, request a consistency proof via
```
get-sth-consistency
```
to verify the log remains append-only and no entries have been modified or removed.
Certificate inventory report: Produce a complete inventory of all certificates issued for monitored domains, grouped by issuer, with validity status and key strength metrics.
CA diversity analysis: Report on how many different CAs issue certificates for the organization, identifying consolidation opportunities and single-points-of-failure.
Compliance evidence: For organizations subject to PCI-DSS, SOC 2, or similar frameworks, CT monitoring logs provide evidence of certificate lifecycle management and unauthorized issuance detection capabilities.

验证日志完整性并生成合规证据：

签名树头（STH）监控：通过
```
get-sth
```
API端点从每个受监控的CT日志获取最新STH。STH包含树大小和签名时间戳。使用日志的公钥验证签名。
一致性证明验证：在连续两次获取STH之间，通过
```
get-sth-consistency
```
请求一致性证明，验证日志保持仅追加状态且无条目被修改或删除。
证书清单报告：生成受监控域名的所有已颁发证书的完整清单，按颁发机构分组，包含有效性状态和密钥强度指标。
CA多样性分析：报告为组织颁发证书的不同CA数量，识别整合机会和单点故障。
合规证据：对于受PCI-DSS、SOC 2或类似框架约束的组织，CT监控日志提供证书生命周期管理和未授权颁发检测能力的证据。

Key Concepts

核心概念

Term	Definition
Certificate Transparency (CT)	An open framework (RFC 6962) requiring Certificate Authorities to log all issued certificates in publicly auditable append-only logs, enabling domain owners to detect unauthorized issuance
Signed Certificate Timestamp (SCT)	A promise from a CT log that a certificate will be included within the Maximum Merge Delay (typically 24 hours); browsers require SCTs from multiple logs before trusting a certificate
Merkle Tree	The cryptographic data structure used by CT logs where leaf nodes are certificate hashes and parent nodes are hashes of their children, enabling efficient consistency and inclusion proofs
Precertificate	A certificate submitted to CT logs before final issuance, containing a poison extension (OID 1.3.6.1.4.1.11129.2.4.3) that prevents it from being used for TLS but reserves its place in the log
crt.sh	A free web service operated by Sectigo that aggregates certificates from all major CT logs into a searchable PostgreSQL database, providing both web and API access
Subdomain Takeover	A vulnerability where a subdomain's DNS record points to a decommissioned service (cloud provider, CDN) that an attacker can reclaim, made discoverable through expired CT certificates
Maximum Merge Delay (MMD)	The maximum time (typically 24 hours) a CT log has to incorporate a submitted certificate into its Merkle tree after returning an SCT
CAA Record	DNS Certification Authority Authorization record that specifies which CAs are permitted to issue certificates for a domain; CT monitoring detects violations of CAA policy

术语	定义
Certificate Transparency (CT)	一种开放框架（RFC 6962），要求证书颁发机构将所有已颁发证书记录在可公开审计的仅追加日志中，使域名所有者能够检测未授权颁发行为
Signed Certificate Timestamp (SCT)	CT日志做出的承诺，即证书将在最大合并延迟（通常24小时）内被纳入；浏览器需要来自多个日志的SCT才会信任证书
Merkle Tree	CT日志使用的加密数据结构，叶节点是证书哈希值，父节点是其子节点的哈希值，可实现高效的一致性和包含性证明
Precertificate	最终颁发前提交给CT日志的证书，包含一个有毒扩展（OID 1.3.6.1.4.1.11129.2.4.3），阻止其用于TLS但保留其在日志中的位置
crt.sh	Sectigo运营的免费Web服务，将所有主要CT日志的证书聚合到可搜索的PostgreSQL数据库中，提供Web和API访问
Subdomain Takeover	一种漏洞，子域名的DNS记录指向已停用的服务（云提供商、CDN），攻击者可以重新获取该服务；可通过过期CT证书发现
Maximum Merge Delay (MMD)	CT日志在返回SCT后，将提交的证书纳入其Merkle树的最长时间（通常24小时）
CAA Record	DNS证书颁发机构授权记录，指定哪些CA被允许为域名颁发证书；CT监控可检测违反CAA政策的行为

Tools & Systems

工具与系统

crt.sh: Primary CT log aggregator providing JSON API access at
```
https://crt.sh/?q=<query>&output=json
```
with support for wildcard queries, identity filtering, and certificate detail retrieval
ct-woodpecker: Open-source CT log monitoring tool from Let's Encrypt that integrates with Prometheus and Grafana for operational monitoring of log health and consistency
certspotter: SSLMate's CT log monitor that watches for newly issued certificates and sends notifications; available as hosted service or self-hosted tool
Google Argon / Xenon / Icarus: Google-operated CT logs that are among the most widely used, queryable via the RFC 6962 API at their respective log URLs
OpenSSL: Command-line tool for parsing certificate details, verifying chains, and extracting SAN lists from certificates retrieved through CT monitoring

crt.sh：主要CT日志聚合器，提供JSON API访问
```
https://crt.sh/?q=<query>&output=json
```
，支持通配符查询、身份过滤和证书详情检索
ct-woodpecker：Let's Encrypt开发的开源CT日志监控工具，与Prometheus和Grafana集成，用于日志健康和一致性的运营监控
certspotter：SSLMate的CT日志监控工具，监控新颁发的证书并发送通知；提供托管服务或自托管工具两种形式
Google Argon / Xenon / Icarus：谷歌运营的CT日志，是使用最广泛的日志之一，可通过RFC 6962 API在各自的日志URL查询
OpenSSL：命令行工具，用于解析证书详情、验证链以及从CT监控获取的证书中提取SAN列表

Common Scenarios

常见场景

Scenario: Detecting Unauthorized Certificate Issuance for a Financial Services Company

场景：检测金融服务公司的未授权证书颁发

Context: A bank monitors its primary domain (

bank.example.com

) and discovers via CT logs that a certificate has been issued by a CA they have never used, covering

secure-login.bank.example.com

-- a subdomain that does not exist in their DNS.

Approach:

CT monitoring agent detects a new certificate from "FreeSSL CA" for
```
secure-login.bank.example.com
```
in crt.sh results, which is not in the authorized CA list (DigiCert, Sectigo)
Alert fires as unauthorized CA + new subdomain, escalating to the security team within 15 minutes of CT log entry
Investigate the certificate: extract the public key, check if the domain validated via HTTP-01 or DNS-01 challenge, query WHOIS for the issuing organization
DNS lookup for
```
secure-login.bank.example.com
```
reveals it resolves to an IP address in a hosting provider not used by the bank -- confirming this is attacker infrastructure
Initiate incident response: request certificate revocation from FreeSSL CA, file a domain abuse report, add the IP to blocklists, and notify the anti-phishing team
Implement CAA DNS records (
```
bank.example.com. CAA 0 issue "digicert.com"
```
) to prevent unauthorized CAs from issuing future certificates

Pitfalls:

Not monitoring wildcard patterns (
```
%.bank.example.com
```
) and missing certificates for subdomains
Ignoring precertificates that appear in CT logs before the actual certificate is issued, losing the early warning advantage
Failing to verify that CAA records are properly configured on all domains after an incident
Over-alerting on legitimate certificate renewals because the baseline database was not updated after authorized changes

背景：一家银行监控其主域名(

bank.example.com

)，通过CT日志发现从未使用过的CA为

secure-login.bank.example.com

颁发了证书——该子域名不存在于他们的DNS中。

处理方法:

CT监控代理在crt.sh结果中检测到来自“FreeSSL CA”的
```
secure-login.bank.example.com
```
新证书，该CA不在授权CA列表（DigiCert、Sectigo）中
触发未授权CA+新子域名警报，在CT日志条目生成15分钟内升级至安全团队
调查证书：提取公钥，检查域名是否通过HTTP-01或DNS-01验证，查询颁发组织的WHOIS信息
对
```
secure-login.bank.example.com
```
进行DNS查询，发现其解析到银行未使用的托管提供商IP地址——确认这是攻击者基础设施
启动事件响应：请求FreeSSL CA吊销证书，提交域名滥用报告，将IP加入黑名单，并通知反钓鱼团队
配置CAA DNS记录(
```
bank.example.com. CAA 0 issue "digicert.com"
```
)，防止未授权CA未来颁发证书

注意事项:

未监控通配符模式(
```
%.bank.example.com
```
)，遗漏子域名的证书
忽略CT日志中实际证书颁发前出现的预证书，失去早期预警优势
事件发生后未验证所有域名的CAA记录是否正确配置
因授权变更后未更新基线数据库，对合法证书续期过度警报

Scenario: Attack Surface Mapping Through CT Log Subdomain Discovery

场景：通过CT日志子域名发现映射攻击面

Context: A penetration tester uses CT logs as the first phase of external reconnaissance to map the target organization's internet-facing services before active scanning.

Approach:

Query crt.sh for
```
%.target.com
```
and all known subsidiary domains, collecting 2,400 unique certificates spanning 8 years
Extract 347 unique subdomains from SAN fields across all certificates, including expired ones
DNS-resolve all 347 subdomains, finding 189 currently active with A/AAAA records
Identify 12 subdomains pointing to decommissioned cloud services (CNAME to S3 buckets, Azure endpoints) that are candidates for subdomain takeover
Discover
```
staging-api.target.com
```
and
```
dev-portal.target.com
```
which are not in the target's documented scope but are reachable and running older software versions
Present findings to the target organization showing the gap between their known asset inventory and the CT-derived attack surface

Pitfalls:

Assuming all CT-discovered subdomains are in scope without confirming with the asset owner
Not checking for wildcard DNS responses that make it appear subdomains exist when they resolve to a catch-all
Relying solely on CT data without cross-referencing with passive DNS databases for comprehensive coverage

背景：渗透测试人员在主动扫描前，将CT日志作为外部侦察的第一阶段，映射目标组织的互联网面向服务。

处理方法:

查询crt.sh获取
```
%.target.com
```
和所有已知子公司域名的证书，收集到8年间的2400个唯一证书
从所有证书的SAN字段中提取347个唯一子域名，包括过期证书
对所有347个子域名进行DNS解析，发现189个当前活跃且带有A/AAAA记录
识别出12个指向已停用云服务（CNAME到S3存储桶、Azure端点）的子域名，存在子域名接管风险
发现
```
staging-api.target.com
```
和
```
dev-portal.target.com
```
，它们不在目标的文档化范围内，但可访问且运行旧版本软件
向目标组织展示发现结果，说明其已知资产清单与CT导出的攻击面之间的差距

注意事项:

未与资产所有者确认，假设所有CT发现的子域名都在测试范围内
未检查通配符DNS响应，这些响应会使子域名看似存在但实际解析到通配符地址
仅依赖CT数据，未与被动DNS数据库交叉引用以获得全面覆盖

Output Format

输出格式

undefined

undefined

CT Log Monitoring Report

CT日志监控报告

Domain: example.com Monitoring Period: 2026-03-01 to 2026-03-19 Total Certificates Tracked: 142 New Certificates Detected: 7 Alerts Generated: 2

域名: example.com 监控周期: 2026-03-01 至 2026-03-19 跟踪证书总数: 142 检测到新证书: 7 生成警报: 2

Alert: Unauthorized CA Issuance

警报：未授权CA颁发

Severity: Critical
Certificate CN: secure-login.example.com
SANs: secure-login.example.com, www.secure-login.example.com
Issuer: Unknown Free CA (NOT in authorized CA list)
Serial: 04:A3:B7:2F:...:9E
Not Before: 2026-03-18T00:00:00Z
Not After: 2026-06-16T00:00:00Z
CT Log: Google Argon 2026
SCT Timestamp: 2026-03-17T22:15:33Z
Action Required: Investigate immediately, request revocation

严重程度: 关键
证书CN: secure-login.example.com
SANs: secure-login.example.com, www.secure-login.example.com
颁发机构: 未知免费CA（不在授权CA列表中）
序列号: 04:A3:B7:2F:...:9E
生效时间: 2026-03-18T00:00:00Z
过期时间: 2026-06-16T00:00:00Z
CT日志: Google Argon 2026
SCT时间戳: 2026-03-17T22:15:33Z
需采取行动: 立即调查，请求吊销证书

Subdomain Discovery Summary

子域名发现摘要

Total Unique Subdomains: 89
New Subdomains This Period: 3
- api-v3.example.com (DigiCert, valid)
- staging-new.example.com (Let's Encrypt, valid)
- old-portal.example.com (expired 2025-12-01, CNAME to Azure -- takeover risk)

唯一子域名总数: 89
本期新子域名: 3
- api-v3.example.com（DigiCert，有效）
- staging-new.example.com（Let's Encrypt，有效）
- old-portal.example.com（2025-12-01过期，CNAME到Azure -- 存在接管风险）

Typosquatting Alerts

仿冒域名警报

Domain	Certificate Count	Issuer	Action Required
exarnple.com	2	Let's Encrypt	Investigate phishing
examp1e.com	1	ZeroSSL	Investigate phishing

undefined

域名	证书数量	颁发机构	需采取行动
exarnple.com	2	Let's Encrypt	调查钓鱼行为
examp1e.com	1	ZeroSSL	调查钓鱼行为

undefined