证书透明度（CT）日志验证引擎：Rust 实战 RFC 6962，构建可审计的邮件 TLS 信任体系

引言：证书透明度为何重要？

2011 年，荷兰 CA 公司 DigiNotar 被入侵，攻击者伪造了包括 Google、CIA、MI6 在内的 500 多个域名证书，导致伊朗发生大规模中间人攻击事件。这一事件直接催生了 Certificate Transparency (证书透明度) — RFC 6962 协议，旨在通过公开审计日志让所有 TLS 证书的签发行为可追溯、可验证。

如今，证书透明度已成为 Web PKI 生态的基石。Chrome 从 2018 年起要求所有新签发的 TLS 证书必须包含 SCT（签名证书时间戳），Apple Safari 也有对应的 CT 策略。没有 CT 合规的证书，浏览器会直接拒绝信任。

在邮件认证链验证引擎（Phase 12.1）之后，YBB 项目的 Phase 12.0 — 证书透明度（CT）日志验证引擎现已作为 Rust 安全模块交付，为邮件系统提供证书透明度的核心验证能力。

一、CT 协议核心概念

Certificate Transparency 通过在 CA、域名所有者、公众之间建立一套公开透明的证书签发审计机制，解决传统 PKI "任何 CA 可以为任何域名签发证书" 的隐式信任问题。其核心组件包括：

CT 日志 (CT Log)：仅追加的 Merkle 哈希树，由 Google、Cloudflare、DigiCert 等运营方维护。每个日志拥有唯一的 32 字节 ID（SHA-256 公钥哈希）、签名算法（ECDSA P-256/SHA-256、RSA/SHA-256 或 Ed25519）和一组状态（Usable / Retired / Rejected）。

SCT (Signed Certificate Timestamp)：日志运营方对某条证书哈希的数字签名承诺，证明该证书已被收录于日志中。浏览器在 TLS 握手时要求服务器提供 SCT，通常嵌入在证书扩展、OCSP 响应或 TLS 扩展中。

Merkle 树包含证明 (Inclusion Proof)：验证某条证书确实包含在日志的 Merkle 树中，而不仅仅是一个"空头承诺"。审计者可以通过 O(log n) 个哈希节点验证证书存在性。

Merkle 树一致性证明 (Consistency Proof)：验证日志在两个不同树大小之间没有回滚或分叉，确保日志的仅追加性质。

二、Rust CT 日志验证引擎架构

YBB 项目将 CT 验证能力封装为独立的安全引擎 ct_log_verifier，遵循项目一贯的 "核心引擎 + C FFI 绑定" 双模块设计：

• 核心引擎 security/ct_log_verifier.rs：~890 行纯 Rust 实现，零外部密码学依赖（SHA-256 使用 RustCrypto）
• C FFI 绑定 ffi/ct_log_verifier_ffi.rs：16 个 extern "C" 导出函数 + 8 个单元测试

2.1 SCT 解析与验证

SCT 遵循 RFC 6962 §3.2 的二进制格式：版本（1 字节）+ 日志 ID（32 字节）+ 时间戳（8 字节大端毫秒）+ 扩展字段（变长）+ 签名算法（1 字节）+ 签名值。引擎完整解析每一字段，并对时间戳合理性做检查（不能超过当前时间 24 小时，防止未来日期攻击）：

// SCT 合理性检查示例
pub fn is_timestamp_plausible(&self) -> bool {
    let now = current_ts_millis();
    self.timestamp_millis <= now + 86_400_000 // 24 小时容忍窗口
}

该引擎支持 RFC 6962 V1 和 RFC 9162 V2 两种 SCT 版本，并自动识别 5 种签名算法（RSA-SHA256/384、ECDSA-P256-SHA256、ECDSA-P384-SHA384、Ed25519）。

2.2 CT 日志管理

引擎维护一个 CT 注册表，支持 Chrome 和 Apple 两大 CT 策略体系的日志预加载。每个日志条目包含完整的元数据：

pub struct CtLogInfo {
    pub log_id: Vec<u8>,        // 32 字节 SHA-256 公钥哈希
    pub public_key: Vec<u8>,    // DER 格式公钥
    pub operator: String,       // 运营者名称 (如 "Google")
    pub url: String,            // 日志端点 URL
    pub sig_alg: CtLogSignatureAlg, // 签名算法
    pub state: CtLogState,      // Usable / Retired / Rejected / PendingReview
    pub merge_delay_millis: u64, // 合并延迟（日志可延迟收录）
}

日志状态机制允许引擎正确处理已退役日志（Retired）的 SCT — 根据 RFC 6962，退役日志的 SCT 在退役后一年内仍然有效，超过一年则应标记为问题。

2.3 CT 合规策略引擎

引擎提供三种预设策略和自定义策略能力，覆盖主流浏览器要求：

合规验证结果分为四个等级：Fully Compliant（完全合规）、Partial（部分合规）、Non-Compliant（不合规）、Unknown（无法验证）。验证器会输出详细的 SCT 分析和问题列表（如"缺少 Google 运营日志的 SCT"、"SCT 时间戳不合理"等）。

pub struct CtVerificationResult {
    pub status: CtComplianceStatus,        // 合规状态
    pub sct_count: u32,                    // 总 SCT 数量
    pub valid_sct_count: u32,              // 有效 SCT 数量
    pub distinct_logs: u32,                // 不同日志数
    pub issues: Vec<CtIssue>,              // 问题列表（带严重级别）
    pub sct_details: Vec<SctDetail>,       // SCT 详情
}

2.4 Merkle 树证明验证

引擎实现了 RFC 6962 §2 定义的 Merkle 哈希树操作，用于包含证明和一致性证明的验证：

• 叶子哈希： Hash(0x00 ‖ leaf_data) — 前缀字节 0x00 区分叶子节点
• 内部节点哈希： Hash(0x01 ‖ left ‖ right) — 前缀字节 0x01 区分内部节点
• 包含证明：给定叶节点索引和 Merkle 路径，验证从叶子到根哈希的计算链
• 一致性证明：给定旧树大小和新树大小，验证两个 Merkle 根之间的仅追加关系

这些操作使 YBB 邮件系统不仅能验证 SCT 的签名，还能审计性地证明某证书确实收录在日志树中 — 这是区别于简单 SCT 解析器的核心能力。

三、C FFI 导出接口

为支持跨平台客户端（WinUI桌面端、Android/iOS移动端、Linux/Mac原生客户端），引擎通过 C ABI 暴露完整能力。共 16 个导出函数，四组接口：

引擎生命周期（3 个）：rust_ct_log_verifier_create / rust_ct_log_verifier_destroy / rust_ct_log_verifier_reset

CT 日志管理（4 个）：rust_ct_log_register_log / rust_ct_log_remove_log / rust_ct_log_get_log_count / rust_ct_log_list_logs

SCT 合规验证（5 个）：rust_ct_log_verify_scts（批量验证）/ rust_ct_log_check_compliance / rust_ct_log_verify_inclusion_proof / rust_ct_log_verify_consistency_proof / rust_ct_log_get_stats

策略与 Merkle 树（4 个）：rust_ct_log_set_policy（Chrome/Apple/自定义）/ rust_ct_log_compute_leaf_hash / rust_ct_log_compute_node_hash / rust_ct_log_check_timestamp

四、邮件安全中的 CT 应用

在 YBB 邮件系统中，CT 验证引擎在以下场景发挥关键作用：

TLS 连接验证：SMTP/IMAP/POP3 over TLS 连接建立时，对服务器证书执行 CT 合规检查。不合规的连接会被标记为"证书风险"，在 UI 中提示用户。

S/MIME 证书审计：对用于邮件签名和加密的 S/MIME 证书进行 CT 验证，确保证书来源可信，防止伪造证书用于邮件中间人攻击。

TLSRPT 集成：CT 验证结果可直接输入 TLSRPT（TLS Reporting）框架，向域名所有者发送 MTA-STS 和 DANE 聚合报告，帮助邮件管理员发现配置错误的 STARTTLS 服务器。

五、与其他安全引擎的协同

CT 日志验证引擎并非孤立运行，而是 YBB 邮件安全体系的重要一环：

• 认证链验证引擎（Phase 12.1）负责 SPF → DKIM → DMARC 的三阶段链式验证，CT 引擎则从证书透明角度补充"证书是否可信赖"的维度
• DKIM 签名引擎（Phase 10.5）使用的 Ed25519/RSA 密钥可通过 CT 验证公钥合法性
• 综合安全评分引擎（Phase 10.15）将 CT 合规状态作为信任评分的一个信号输入

总结

Certificate Transparency 是现代 Web PKI 信任体系的重要进步。YBB 项目的 CT 日志验证引擎（Phase 12.0）以 Rust 交付，提供从 SCT 解析、Merkle 树证明验证到 CT 合规策略的完整能力，覆盖 Chrome 和 Apple 两大主流策略体系。通过 C FFI 16 个导出接口，引擎可被 WinUI、Android、iOS、Linux、Mac 等多平台客户端直接调用，为邮件系统的 TLS 安全和 S/MIME 证书审计提供坚实保障。

下一篇文章将介绍 邮件认证链验证引擎（Phase 12.1） — 不过我们已经在上篇文章中详细讨论过了，敬请期待后续 Phase 带来的更多安全能力。