2026-02-17 19:51:33 网络安全文章来源：ZONE.CI 全球网 0 阅读模式

文章总结： 本文是CertificateTransparency系列的第一部分，详细介绍了证书透明度机制。CT是一个公开的、仅追加的TLS证书日志系统，旨在使证书签发过程可观察，从而快速检测错误签发行为。它解决了传统证书生态系统的信任问题，通过公开日志让域名所有者、研究人员等能够监控和分析证书签发。文章解释了CT的关键特性、涉及的角色、基于Merkle树的技术原理、证书与预证书的区别、SCT的作用以及CT日志API。同时概述了CT的发展历史、主要日志运营者和相关工具。 综合评分： 85 文章分类： 网络安全,技术标准,安全建设,应用安全,其他

cover_image

证书透明度机制详解

latedeployment latedeployment

securitainment

2026年2月14日 10:24 中国香港

| 原文链接 | 作者 | | — | — | | https://latedeployment.github.io/posts/certificate-transparency-101/ | latedeployment |

本文是 Certificate Transparency 系列的第一部分。

Certificate Transparency (CT) 是一个公开的、仅追加的 TLS 证书日志系统。它的设计目的是让证书签发过程变得可观察，从而能够快速、独立地检测错误签发行为。CT 不再仅仅依赖信任，而是让任何人都可以审计某个域名被签发了哪些证书，以及这些证书何时出现在公开日志中。

CT 解决的问题

在 CT 出现之前，证书生态系统存在一个根本性的信任问题：你必须相信证书颁发机构 (CA) 在正确地履行职责，但却没有简便的方法来验证这一点。如果某个 CA 签发了一张欺诈性证书——例如由于系统被入侵或操作失误——通常只有在损害已经造成之后才会被发现。

参见 DigiNotar_、_Comodo和 CCNIC事件。

在所有这些案例中，检测都很缓慢，基本上只能靠运气。

CT 通过公开证书签发过程来解决这个问题。每张公开受信任的证书在被浏览器接受之前，都必须被记录到公开的、可审计的日志中。

因此，有了 CT：

域名所有者可以监控日志中是否出现意料之外的证书。
研究人员可以分析整个生态系统中的签发模式。
错误签发行为可以被直接发现。

什么是 Certificate Transparency

Certificate Transparency 是一组公开的日志，这些日志接收证书并返回密码学证明，以证实证书已被记录。

这些日志具有以下特性：

仅追加

：一旦证书被记录，它将永久保留在日志中。条目不能被修改或删除。
公开可审计

：任何人都可以验证日志的一致性和包含证明。读取日志内容无需身份验证。
由独立组织运营

，以降低单点故障风险。没有任何单一实体控制所有日志。
可密码学验证

：证明基于 Merkle 树构建，客户端无需信任日志运营者即可验证其声明。

该系统还涉及几个关键角色：

证书颁发机构 (CA)

在签发流程中将证书 (或预证书) 提交到 CT 日志。
日志

返回签名证书时间戳 (SCT)——这是一个签名承诺，表示该证书将被纳入日志中。
浏览器

要求公开受信任的证书必须携带 SCT，并执行 CT 策略。
监控者

监视日志中是否存在可疑或意外的签发行为，并向域名所有者发出警报。
审计者

验证日志行为是否正确，确保没有遗漏条目。

理解 Merkle 树

CT 日志基于 Merkle 树构建，这是一种用于密码学哈希的数据结构。

什么是 Merkle 树？

Merkle 树是一种二叉树，其中：

每个叶子节点包含一个数据项的哈希值 (在 CT 中，数据项就是证书)。
每个内部节点包含其两个子节点拼接后的哈希值。
根哈希代表对树中所有数据的密码学承诺。

Merkle tree structure

这种结构支持两个关键操作：

包含证明：给定一张证书，证明它存在于日志中，而无需下载整个日志。你只需要从叶子节点到根节点路径上的哈希值——对于包含 n 个条目的树，只需 O(log n) 个哈希值。

例如，要证明 Cert B 存在于上面的树中，你只需要：

H(A)——H(B) 的兄弟节点
H(CD)——H(AB) 的兄弟节点
根哈希

然后你可以验证：Root = H(H(H(A) || H(B)) || H(CD))

一致性证明：证明日志的较新版本是较旧版本的有效扩展——即没有条目被修改或删除。

树头与签名

日志会定期发布签名树头 (STH)，其中包含：

树的大小 (条目数量)。
时间戳。
根哈希。
日志对上述值的密码学签名。

日志记录的内容

一张典型的 X.509 证书包含：

主体与签发者信息

主体可分辨名称 (DN)

：可能包括组织名称、地理位置、通用名称等。
签发者 DN

：标识签发该证书的 CA。

域名

通用名称 (CN)

：主域名。
主体备用名称 (SANs)

：证书有效覆盖的域名和 IP 地址的权威列表。

SANs 示例：

DNS:example.com
DNS:www.example.com
DNS:api.example.com
DNS:staging.internal.example.com
DNS:10-0-1-42.pods.cluster.local

有效期

Not Before

：证书生效时间。
Not After

：证书过期时间。

公钥

证书中包含其公钥。

扩展

各种 X.509 扩展，包括：

密钥用途约束。
基本约束 (该证书是否为 CA 证书？)。
证书策略。
颁发机构信息访问 (在哪里获取签发者的证书和 OCSP)。

证书与预证书

CT 日志接受两种类型的条目：

证书

标准 X.509 证书。在签发后记录证书意味着该证书可以立即使用。

预证书

预证书是一种特殊的类证书结构，它：

包含与最终证书完全相同的信息。
包含一个 “毒药” 扩展 (OID 1.3.6.1.4.1.11129.2.4.3)，将其标记为对 TLS 无效。
由签发 CA 或专用的预证书签名证书签署。

预证书的工作流程：

CA 使用所有最终证书的详细信息创建预证书。
CA 将预证书提交到 CT 日志。
日志返回 SCT。
CA 创建最终证书，并将 SCT 嵌入其中。
CA 将最终证书签发给订阅者。

这使得 SCT 可以直接嵌入证书中，这是最简洁的分发机制。

预证书和最终证书的信息完全一致，区别仅在于：

毒药扩展被移除。
SCT 列表扩展被添加。
签名不同 (覆盖了修改后的扩展)。

在搜索 CT 日志时，你可能会找到证书的其中一个版本或两个版本同时存在。

签名证书时间戳 (SCT)

SCT 是日志对将证书纳入日志的承诺。它包含：

Log ID

：日志公钥的 SHA-256 哈希值。
Timestamp

：日志收到提交的时间。
Extensions

：保留供将来使用 (目前为空)。
Signature

：日志对上述字段加上证书的签名。

CT 日志 API

CT 日志公开了一套 HTTP API。RFC 9162 定义了 v2 版本的端点：

提交端点

POST /ct/v2/submit-entry

提交证书或预证书以进行日志记录。返回 SCT。

{
"submission":&nbsp;"base64-encoded-cert-or-precert",
"type":&nbsp;1,
"chain": ["base64-encoded-issuer",&nbsp;...]
}

type字段指示提交的内容类型：

1

表示证书 (x509_entry_v2)
2

表示预证书 (precert_entry_v2)

查询端点

GET /ct/v2/get-sth

获取当前的签名树头。

响应：

{
"tree_size":&nbsp;123456789,
"timestamp":&nbsp;1705123456789,
"sha256_root_hash":&nbsp;"base64-encoded-hash",
"tree_head_signature":&nbsp;"base64-encoded-signature"
}

GET /ct/v2/get-sth-consistency?first=X&second=Y

获取两个树大小之间的一致性证明。

GET /ct/v2/get-proof-by-hash?hash=X&tree_size=Y

获取叶子哈希的包含证明。

GET /ct/v2/get-entries?start=X&end=Y

按索引检索日志条目。监控者通过此接口下载证书。

GET /ct/v2/get-all-by-hash?hash=X&tree_size=Y

在单次请求中同时获取包含证明和一致性证明。

GET /ct/v2/get-roots

获取该日志可接受的根证书列表。