土法炼钢兴趣小组的算法知识备份

【密码学百科】PKI 与数字证书：信任链的构建与崩塌

2026-04-04 · cryptography · #PKI #X.509 #certificate #CA #certificate-transparency #OCSP #CRL #ACME #Lets-Encrypt

目录

当你在浏览器地址栏看到那把小锁的时候，背后运转着一套庞大而精密的信任体系——公钥基础设施(Public Key Infrastructure, PKI)。PKI 的核心思想并不复杂：如果你无法亲自验证对方的公钥，那就让一个双方都信任的第三方来担保。这个第三方被称为证书颁发机构(Certificate Authority, CA)，它签发的电子凭证被称为数字证书(Digital Certificate)。整个互联网的加密通信、身份认证、代码签名乃至电子邮件的完整性保护，都建立在这套基础设施之上。

然而，信任从来不是理所当然的。历史上，多家 CA 因为安全事故或蓄意违规而被浏览器厂商吊销信任，每一次事件都动摇着整个体系的根基。理解 PKI 的运作机制——从证书的二进制结构到信任链的逐级验证，从证书吊销的困境到证书透明度的审计——是每一位安全工程师的必修课。本文将系统地拆解这套体系，既讲清楚”它为什么能工作”，也直面”它在哪里会崩塌”。

一、X.509 证书结构

X.509 是国际电信联盟(ITU-T)定义的公钥证书标准，当前广泛使用的版本为 v3(RFC 5280)。一张 X.509 证书本质上是一段被 CA 签名的结构化数据，采用 ASN.1(Abstract Syntax Notation One)语法描述，以 DER(Distinguished Encoding Rules)编码为二进制格式。实际传输中，常将 DER 编码的二进制数据再做一次 Base64 编码，并用 -----BEGIN CERTIFICATE----- 和 -----END CERTIFICATE----- 包裹，形成 PEM(Privacy-Enhanced Mail)格式。

一张 v3 证书包含三个顶层字段：待签名证书体(TBSCertificate)、签名算法标识(signatureAlgorithm)、签名值(signatureValue)。其中待签名证书体承载了全部有意义的信息：

版本号(Version)：指明证书遵循的 X.509 版本，v3 对应整数值 2(因为版本号从 0 开始计数)。

序列号(Serial Number)：由 CA 分配的唯一正整数。RFC 5280 要求序列号在同一 CA 的所有证书中不得重复，且至少包含 20 比特的熵。序列号的唯一性对于证书吊销机制至关重要——吊销列表中正是通过序列号来标识被吊销的证书。

签名算法(Signature Algorithm)：指明 CA 签署此证书时使用的算法，常见值包括 sha256WithRSAEncryption、ecdsa-with-SHA256 等。此字段必须与外层的签名算法标识一致。

颁发者(Issuer)：签发此证书的 CA 的可辨识名称(Distinguished Name, DN)，由一系列属性组成，如国家(C)、组织(O)、通用名称(CN)等。

有效期(Validity)：包含两个时间戳——生效时间(notBefore)和失效时间(notAfter)。证书仅在此区间内有效。当前行业惯例是域名证书的有效期不超过 398 天。

主体(Subject)：证书持有者的可辨识名称。对于域名证书，CN 字段传统上填写域名，但现代实践更依赖扩展字段中的主体备选名称。

主体公钥信息(Subject Public Key Info)：包含公钥算法标识和公钥值。这是证书的核心载荷——验证方正是通过此字段获取证书持有者的公钥。

v3 证书引入了扩展(Extensions)机制，使证书的表达能力大大增强。每个扩展包含三个部分：对象标识符(OID)、是否关键(critical)标志、以及扩展值。如果一个扩展被标记为关键而验证方不认识它，则必须拒绝该证书。常见的关键扩展包括：

基本约束(Basic Constraints)：指明该证书是否为 CA 证书，以及允许的证书链深度。终端实体证书中此扩展的 cA 字段为 FALSE。

密钥用途(Key Usage)：以比特掩码的形式声明公钥的允许用途，如数字签名(digitalSignature)、密钥加密(keyEncipherment)、证书签名(keyCertSign)等。

扩展密钥用途(Extended Key Usage)：以 OID 列表的形式进一步细化用途，如服务器认证(id-kp-serverAuth)、客户端认证(id-kp-clientAuth)、代码签名(id-kp-codeSigning)等。

主体备选名称(Subject Alternative Name, SAN)：列出证书有效的所有名称，包括 DNS 名称、IP 地址、电子邮件地址等。现代 TLS 证书的域名验证完全依赖此扩展而非 Subject 中的 CN 字段。一张证书可以通过 SAN 覆盖多个域名，通配符证书(如 *.example.com)也在此字段中声明。

授权信息访问(Authority Information Access, AIA)：指向颁发者证书的下载地址(用于补全证书链)和 OCSP 响应服务器的地址。

CRL 分发点(CRL Distribution Points)：指向证书吊销列表的下载地址。

使用 OpenSSL 可以方便地查看证书的详细结构：

# 查看 PEM 格式证书的全部字段
openssl x509 -in server.crt -text -noout

# 仅查看主体和颁发者
openssl x509 -in server.crt -subject -issuer -noout

# 查看 SAN 扩展
openssl x509 -in server.crt -noout -ext subjectAltName

# 从远程服务器获取证书并查看
openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null \
  | openssl x509 -text -noout

理解证书的 ASN.1 结构对于排查证书相关问题至关重要。当你遇到”证书无效”的错误时，通常需要检查的第一件事就是证书的各个字段是否符合预期。

实际证书拆包示例

以下是对一张真实 TLS 证书执行 openssl x509 -text -noout 的输出示例（已脱敏），展示了各字段在实际证书中的呈现方式：

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            04:e3:a5:2b:7c:d6:18:3f:9a:01:b2:c4:d5:e6:f7:08
        Signature Algorithm: ecdsa-with-SHA384
        Issuer: C = US, O = Let's Encrypt, CN = E5
        Validity
            Not Before: Mar 15 00:00:00 2026 GMT
            Not After : Jun 13 23:59:59 2026 GMT
        Subject: CN = www.example.com
        Subject Public Key Info:
            Public Key Algorithm: id-ecPublicKey
                Public-Key: (256 bit)
                ASN1 OID: prime256v1
                NIST CURVE: P-256
        X509v3 extensions:
            X509v3 Key Usage: critical
                Digital Signature
            X509v3 Extended Key Usage:
                TLS Web Server Authentication, TLS Web Client Authentication
            X509v3 Basic Constraints: critical
                CA:FALSE
            X509v3 Subject Alternative Name:
                DNS:www.example.com, DNS:example.com
            Authority Information Access:
                OCSP - URI:http://e5.o.lencr.org
                CA Issuers - URI:http://e5.i.lencr.org/
            X509v3 Certificate Policies:
                Policy: 2.23.140.1.2.1
            CT Precertificate SCTs:
                Signed Certificate Timestamp:
                    Version   : v1 (0x0)
                    Log ID    : 76:ff:88:3f:0a:...
                    Timestamp : Mar 15 01:00:00.000 2026 UTC
                    Signature : ecdsa-with-SHA256
    Signature Algorithm: ecdsa-with-SHA384
    Signature Value:
        30:45:02:21:00:a1:b2:c3:...

阅读这份输出时，有几个关键点值得注意。首先，Version: 3 (0x2) 中的 0x2 对应 v3（版本号从 0 开始计数）。其次，Subject 中只有 CN 字段，域名的真正绑定在 Subject Alternative Name 扩展中——现代验证程序完全依赖 SAN 而非 CN。再次，Basic Constraints: CA:FALSE 表明这是终端实体证书而非 CA 证书。CT Precertificate SCTs 的存在表明该证书已被提交到证书透明度日志。最后，签名算法为 ecdsa-with-SHA384，说明签发 CA 使用的是椭圆曲线密钥。

二、证书签发流程

证书签发遵循一套严格的流程，核心步骤可以概括为：生成密钥对、创建证书签名请求、CA 验证并签发、构建证书链。

第一步：生成密钥对。 申请者在本地生成一对公私钥。私钥必须安全存储，绝不能离开申请者的控制范围。这一点是整个 PKI 安全性的基石——如果私钥在生成或传输过程中泄露，证书所代表的身份绑定就毫无意义。

# 生成 RSA 2048 位密钥对
openssl genrsa -out server.key 2048

# 生成 ECDSA P-256 密钥对（推荐）
openssl ecparam -genkey -name prime256v1 -noout -out server.key

第二步：创建证书签名请求(Certificate Signing Request, CSR)。 CSR 是一份由申请者签名的数据结构，包含申请者的公钥、主体信息以及所请求的扩展。CSR 本身用申请者的私钥签名，以证明申请者确实持有对应的私钥。

# 生成 CSR
openssl req -new -key server.key -out server.csr \
  -subj "/C=CN/O=Example Corp/CN=www.example.com"

# 查看 CSR 内容
openssl req -in server.csr -text -noout

第三步：CA 验证身份。 CA 收到 CSR 后，需要验证申请者的身份。根据验证深度的不同，证书分为三类：

域名验证证书(Domain Validation, DV)：CA 仅验证申请者对域名的控制权。验证方式包括在指定 URL 放置特定文件(HTTP-01 验证)、添加特定 DNS 记录(DNS-01 验证)、或响应发送到域名管理员邮箱的确认邮件。DV 证书的签发可以完全自动化，是当前互联网上最常见的证书类型。

组织验证证书(Organization Validation, OV)：CA 在域名验证的基础上，还要核实申请组织的法律存在性和身份。证书的 Subject 字段会包含经过验证的组织信息。

扩展验证证书(Extended Validation, EV)：CA 执行最严格的身份核查，包括组织的法律状态、运营地址、申请授权等。EV 证书曾在浏览器地址栏显示绿色的组织名称，但主流浏览器已在 2019 年前后取消了这一视觉区分，因为研究表明普通用户并不关注这些指示器。

第四步：CA 签发证书。 验证通过后，CA 使用自己的私钥对包含申请者公钥和身份信息的证书体进行数字签名，生成最终的 X.509 证书。CA 通常还会提供中间证书(Intermediate Certificate)，以便申请者构建完整的证书链。

第五步：部署证书链。 服务器在 TLS 握手中需要发送完整的证书链——从自身的终端实体证书开始，依次附上所有中间 CA 证书，直到客户端信任库中的根证书(根证书本身不需要发送)。证书链的顺序至关重要，任何缺失或错序都可能导致验证失败。

# 验证证书链的完整性
openssl verify -CAfile root-ca.crt -untrusted intermediate-ca.crt server.crt

# 查看远程服务器返回的完整证书链
openssl s_client -connect example.com:443 -servername example.com -showcerts </dev/null

三、信任模型

PKI 的信任模型决定了”凭什么相信一把公钥属于声称的持有者”。历史上发展出了几种截然不同的模型。

层级信任模型(Hierarchical Trust Model)是 X.509 PKI 采用的模型。信任从一个或多个根 CA 出发，沿着证书链向下传递。根 CA 签发中间 CA 的证书，中间 CA 再签发终端实体的证书。验证方只需要预先信任有限数量的根 CA，就可以通过链式验证来确认任意终端实体证书的有效性。这个模型的优势在于部署简单、管理集中；劣势在于根 CA 拥有过大的权力——一个根 CA 可以为互联网上的任何域名签发证书，一旦根 CA 被攻破或行为不端，影响范围将是灾难性的。

信任网络模型(Web of Trust)是 PGP(Pretty Good Privacy)采用的模型。没有中心化的权威机构，每个用户自行决定信任哪些密钥。用户之间通过相互签名来建立信任关系：如果 Alice 信任 Bob，而 Bob 签署了 Charlie 的密钥，那么 Alice 可以(在一定程度上)信任 Charlie 的密钥。信任网络的优势在于去中心化，不依赖单点；劣势在于信任关系难以扩展，密钥管理对普通用户来说过于复杂，实际上难以在大规模互联网环境中部署。

首次使用信任模型(Trust On First Use, TOFU)是 SSH 协议的默认策略。客户端在首次连接时记录服务器的公钥指纹，后续连接时检查指纹是否发生变化。如果发生变化则发出严重警告。TOFU 不需要任何预先建立的信任关系，但对首次连接时的中间人攻击毫无防御能力。它的价值在于简单实用——在很多场景下，管理员确实只需要确认”服务器还是那台服务器”就够了。

当代互联网主要依赖层级信任模型。但单纯的层级模型已经被证明不够安全，因此业界引入了证书透明度(Certificate Transparency)作为补充监督机制，并通过证书颁发授权(CAA)记录来限制哪些 CA 可以为特定域名签发证书。

笔者认为，PKI 的集中式信任模型是一把双刃剑，也是整个体系最深层的张力所在。一方面，它是可扩展性的保证：一个终端用户只需要信任约 100 个根 CA，就能验证互联网上数十亿张证书的有效性——这种”信任放大”的效率是任何去中心化模型无法匹敌的。另一方面，它也是体系最大的阿喀琉斯之踵：每一个根 CA 都有权为任何域名签发证书，这意味着任何一个 CA 的妥协都可能影响整个互联网。DigiNotar 事件（一个荷兰 CA 被入侵后为 google.com 签发了伪造证书）和 CNNIC 事件（中间 CA 被用于流量拦截）都是这一结构性弱点的直接体现。证书透明度（CT）和证书颁发授权（CAA）正是为了缓解这一矛盾而引入的”制衡层”——它们不改变信任模型的基本结构，但让滥用行为变得可被发现和可被问责。从工程实践来看，PKI 的安全性最终不是一个纯技术问题，而是一个治理问题：谁来决定谁值得信任？当信任被滥用时，惩罚机制是否有效？浏览器厂商作为”信任存储的守门人”，实际上承担着互联网公钥基础设施中最核心的治理角色。

四、根证书存储

层级信任模型的锚点是根证书存储(Root Certificate Store, 也称 Trust Store)。操作系统和浏览器各自维护一份受信任的根 CA 列表，只有被纳入该列表的根 CA 签发的证书链才会被接受。

主要的根证书存储包括：

Mozilla NSS 根证书存储：由 Mozilla 维护，采用公开透明的纳入流程。任何 CA 申请加入都需要经过严格的审查，包括审计报告(WebTrust 或 ETSI)、CP/CPS(Certificate Policy / Certification Practice Statement)文档审查、以及社区讨论。Firefox 直接使用此存储，许多 Linux 发行版也以此为基础。

Microsoft 根证书计划：Windows 和 Edge 浏览器使用的根证书存储。微软有自己的一套准入标准和审计要求。

Apple 根证书计划：macOS 和 iOS 使用的根证书存储。Safari 浏览器依赖此存储。

Google Chrome 根证书计划(Chrome Root Program)：Chrome 从 2022 年开始逐步建立自己独立的根证书存储(Chrome Root Store)，此前它在不同平台上依赖操作系统的信任存储。Google 对 CA 的要求尤为严格，包括强制要求证书透明度。

根证书的纳入并非一劳永逸。如果 CA 发生安全事故或违反行业规范(如 CA/Browser Forum 的基线要求)，浏览器厂商有权将其从信任存储中移除。这种移除意味着该 CA 签发的所有证书都将不再被信任，影响可能波及数百万网站。正因如此，根证书存储的管理是 PKI 体系中权力最大、责任最重的环节。

在服务器端，管理员有时也需要管理自定义的信任存储。例如在企业内网中，可能需要信任企业自建 CA 签发的证书：

# 查看系统信任存储中的根证书数量（以 Debian/Ubuntu 为例）
ls /etc/ssl/certs/ | wc -l

# 将自签名 CA 证书添加到系统信任存储（Debian/Ubuntu）
cp enterprise-ca.crt /usr/local/share/ca-certificates/
update-ca-certificates

# 用指定的 CA 证书验证服务器证书
openssl verify -CAfile /path/to/trusted-ca-bundle.crt server.crt

五、证书透明度

证书透明度(Certificate Transparency, CT)是 Google 在 2013 年提出的公开审计框架(RFC 6962)，旨在让任何人都能监控 CA 的签发行为。CT 的核心思想是：所有公开信任的 TLS 证书都必须被记录到公开的、只可追加的日志中，任何人都可以查询这些日志，从而发现错误签发或恶意签发的证书。

CT 的三个核心角色：

日志服务器(Log Server)：运营公开的、只可追加的日志。日志的数据结构是默克尔树(Merkle Tree)——与区块链使用的数据结构相同。每次有新证书提交到日志时，日志服务器将其作为叶子节点插入默克尔树，并返回一个签名的证书时间戳(Signed Certificate Timestamp, SCT)。SCT 是日志服务器的承诺，表示该证书已被记录(或将在最大合并延迟 MMD 内被记录)。默克尔树的性质保证了日志的只可追加性——任何对历史记录的篡改都会导致根哈希不一致，从而被审计方发现。

监视器(Monitor)：持续拉取日志中的新条目，检查是否有异常的证书签发。域名持有者可以运行监视器来监控自己域名的证书签发情况。如果发现有未经授权的 CA 为自己的域名签发了证书，就可以立即采取行动。

审计方(Auditor)：验证日志服务器的行为是否诚实。审计方通过请求默克尔树的一致性证明(Consistency Proof)来确认日志没有被篡改，通过包含证明(Inclusion Proof)来确认特定证书确实存在于日志中。

SCT 的交付方式有三种：嵌入证书的扩展(X.509v3 Extension)中——这是最常见的方式，CA 在签发证书前先将预证书(Precertificate)提交到日志服务器获取 SCT，然后将 SCT 嵌入最终证书中；通过 TLS 扩展在握手过程中传递；或者通过 OCSP 装订(OCSP Stapling)附带。

自 2018 年 4 月起，Google Chrome 要求所有新签发的公开信任证书必须附带来自合格日志服务器的 SCT，否则将被视为不受信任。这一强制要求极大地推动了 CT 的普及。如今，全球已有数十个活跃的 CT 日志服务器，由 Google、Cloudflare、DigiCert 等组织运营。

域名持有者可以通过 CT 搜索引擎查询自己域名的证书签发记录：

# 查看证书中嵌入的 SCT
openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null \
  | openssl x509 -noout -ext ct_precert_scts

CT 并不能阻止恶意签发，但它让恶意签发变得可被发现。这种”阳光是最好的消毒剂”的理念，已经成为 PKI 体系中不可或缺的安全层。

六、证书吊销

证书一旦签发，就有可能因为私钥泄露、域名所有权变更、CA 签发错误等原因需要提前作废。证书吊销(Certificate Revocation)是 PKI 中公认最薄弱的环节之一。

证书吊销列表(Certificate Revocation List, CRL)是最早的吊销机制。CA 定期发布一份包含所有被吊销证书序列号的签名列表，验证方下载 CRL 并检查目标证书是否在列表中。CRL 的问题是显而易见的：随着吊销证书的积累，CRL 文件会越来越大(有的 CA 的 CRL 高达数十兆字节)；CRL 的更新有延迟(通常数小时到数天)，在更新间隔内被吊销的证书仍然被视为有效；客户端下载 CRL 的网络请求也会增加延迟。

在线证书状态协议(Online Certificate Status Protocol, OCSP)试图解决 CRL 的实时性问题(RFC 6960)。验证方向 CA 的 OCSP 响应服务器发送查询请求，包含待验证证书的序列号，OCSP 服务器返回该证书当前的状态(有效、已吊销、未知)。OCSP 的优势在于响应体积小(通常只有几百字节)且可以提供接近实时的状态；但它引入了新的问题——隐私泄露(CA 可以知道用户在访问哪些网站)以及可用性依赖(如果 OCSP 服务器不可达，验证方该怎么办)。

大多数浏览器对 OCSP 查询失败采取”软失败”(Soft-Fail)策略：如果无法联系 OCSP 服务器，就默认证书有效。这意味着攻击者只需要阻断客户端与 OCSP 服务器之间的网络连接，就可以使用已吊销的证书而不被发现。

OCSP 装订(OCSP Stapling)是对上述问题的改进(RFC 6066)。服务器自己定期从 CA 的 OCSP 服务器获取签名的 OCSP 响应，并在 TLS 握手时将其”装订”到自己的证书消息中发送给客户端。由于 OCSP 响应是由 CA 签名的，服务器无法伪造，客户端可以直接验证而无需额外的网络请求。这既解决了隐私问题(CA 不知道谁在访问该服务器)，也改善了延迟(无需额外的网络往返)。

OCSP Must-Staple 扩展进一步强化了装订机制。证书中如果包含此扩展(OID 1.3.6.1.5.5.7.1.24)，则要求服务器必须在 TLS 握手中提供有效的 OCSP 装订响应，否则客户端应拒绝该证书。这解决了软失败的问题——攻击者即使阻断了 OCSP 查询，也无法使用已吊销的证书，因为缺少有效的装订响应本身就会导致连接被拒绝。

# 测试服务器是否支持 OCSP 装订
openssl s_client -connect example.com:443 -servername example.com -status </dev/null 2>/dev/null \
  | head -20

# 手动查询 OCSP 状态
openssl ocsp -issuer intermediate-ca.crt -cert server.crt \
  -url http://ocsp.example-ca.com -resp_text

尽管有了这些改进，证书吊销在实践中仍然不可靠。Chrome 浏览器早在 2012 年就放弃了在线 OCSP 查询，转而使用自己维护的 CRLSet——一份由 Google 推送的精简吊销列表，仅包含高影响力的吊销条目。这种权衡反映了一个尴尬的现实：在保证用户体验和保证安全之间，业界至今没有找到完美的平衡点。

七、CA 失败案例

PKI 体系的安全性最终取决于 CA 的可信程度。历史上发生过多起严重的 CA 安全事件，每一起都深刻地影响了行业的信任机制和技术标准的演进。

DigiNotar 事件(2011 年)是 PKI 历史上最具标志性的灾难。荷兰 CA DigiNotar 的系统遭到入侵，攻击者利用其基础设施为 *.google.com 等大量高价值域名签发了伪造证书。这些伪造证书随后被用于对伊朗境内的 Google 用户实施中间人攻击，目的是监控其通信内容。事件曝光后，所有主流浏览器在数天内将 DigiNotar 的根证书从信任存储中移除。由于 DigiNotar 同时也是荷兰政府 PKI 的运营方，这次事件甚至影响了荷兰公民的电子身份系统。DigiNotar 随后宣告破产。这起事件直接催生了证书透明度(CT)机制的研发——如果当时有 CT 日志，伪造证书的签发将会被迅速发现。

CNNIC 事件(2015 年)涉及中国互联网络信息中心(CNNIC)。CNNIC 作为受信任的根 CA，将其签发权力委托给了一家名为 MCS Holdings 的埃及公司。MCS Holdings 使用该中间 CA 证书部署在其内部网络的代理设备上，用于拦截和检查 TLS 加密流量——这意味着该中间 CA 证书被用于为任意域名动态签发证书。Google 通过证书透明度日志的监控发现了这些异常证书，随后 Google 和 Mozilla 决定不再信任 CNNIC 的根证书。此事件凸显了 CA 对其下级 CA 的管控责任，以及 CT 机制在实际中的价值。

Symantec 事件(2015-2017 年)是影响范围最大的信任撤销事件。Symantec 是当时全球市场份额最大的 CA 之一，其品牌还包括 VeriSign、Thawte、GeoTrust 等。Google 的调查发现 Symantec 及其关联 CA 存在大量违规签发行为：包括在未经域名持有者授权的情况下签发测试证书、审计流程形同虚设、以及对下级 CA 的监管严重失职。经过长达两年的谈判，Google Chrome 最终决定分阶段逐步不信任所有 Symantec 签发的证书。Symantec 被迫将其 CA 业务出售给 DigiCert。这起事件促使全行业加强了对 CA 运营实践的审查力度。

WoSign 和 StartCom 事件(2016 年)涉及中国 CA WoSign 及其秘密收购的以色列 CA StartCom。WoSign 被发现存在多项严重违规行为：倒签证书日期以规避 SHA-1 禁令、在域名验证中存在漏洞允许攻击者获取他人域名的证书、以及故意对收购 StartCom 的事实进行隐瞒。Mozilla 和 Apple 随后不再信任 WoSign 和 StartCom 的根证书。

这些事件共同推动了几项重要的制度改革：强制要求证书透明度、缩短证书有效期、引入证书颁发授权(CAA)DNS 记录、以及更严格的 CA 审计标准。每一次 CA 的失败都在提醒我们：PKI 的安全不能仅仅依赖技术手段，还需要可靠的治理框架、透明的问责机制、以及浏览器厂商作为最终守门人的制衡力量。

八、Let’s Encrypt 与 ACME

2015 年之前，获取一张 TLS 证书通常意味着付费和繁琐的手动操作。这导致大量网站运行在未加密的 HTTP 上。Let’s Encrypt 的出现彻底改变了这一局面。

Let’s Encrypt 是由互联网安全研究组(Internet Security Research Group, ISRG)运营的非营利 CA，其使命是让 HTTPS 在全球范围内普及。它提供免费的域名验证(DV)证书，并通过完全自动化的签发流程将人工干预降到零。截至目前，Let’s Encrypt 已签发超过数十亿张证书，是全球签发量最大的 CA。

Let’s Encrypt 的自动化签发基于 ACME 协议(Automatic Certificate Management Environment, RFC 8555)。ACME 协议定义了客户端与 CA 之间交互的完整流程：账户注册、域名所有权验证、证书签发、以及证书续期。

ACME 域名验证方式：

HTTP-01 验证：CA 要求申请者在 http://<域名>/.well-known/acme-challenge/<token> 路径放置一个包含特定内容的文件。CA 的验证服务器会尝试通过 HTTP 访问该 URL 来确认申请者对该域名的 Web 服务器具有控制权。这种方式简单直接，但无法用于通配符证书的签发，且要求 80 端口可达。

DNS-01 验证：CA 要求申请者在域名的 _acme-challenge.<域名> 子域创建一条 TXT 记录，内容为特定的验证值。CA 通过 DNS 查询来确认该记录的存在。DNS-01 验证可以用于签发通配符证书(如 *.example.com)，也适用于没有 Web 服务器的场景(如纯邮件服务器)。但它需要申请者具有 DNS 记录的编辑权限，自动化实现依赖于 DNS 提供商的 API 支持。

TLS-ALPN-01 验证：CA 通过 TLS 握手中的应用层协议协商(ALPN)扩展来验证域名控制权。申请者需要在服务器上配置一个使用特定自签名证书的 TLS 服务，该证书包含验证令牌。此方式适用于只开放了 443 端口的场景。

最流行的 ACME 客户端是 Certbot，由电子前哨基金会(Electronic Frontier Foundation, EFF)开发。Certbot 可以自动完成从域名验证到证书部署的全过程：

# 使用 HTTP-01 验证获取证书并自动配置 Nginx
certbot --nginx -d example.com -d www.example.com

# 使用 DNS-01 验证获取通配符证书
certbot certonly --manual --preferred-challenges dns -d "*.example.com"

# 测试证书续期
certbot renew --dry-run

Let’s Encrypt 的设计决策中有几个值得注意的工程选择。首先，证书有效期被设为 90 天(远短于行业惯例的一年)，目的是鼓励自动化续期——如果续期是手动的，90 天的有效期会是一种负担；但如果续期是自动化的，更短的有效期反而减少了密钥泄露的暴露窗口。其次，Let’s Encrypt 的签发基础设施(名为 Boulder)是完全开源的，任何人都可以审查其代码。再次，Let’s Encrypt 的所有签发记录都会提交到多个 CT 日志中，确保完全透明。

Let’s Encrypt 的成功推动了互联网加密的大规模普及。从 2015 年不到 40% 的网页使用 HTTPS，到如今超过 90% 的网页流量被加密，Let’s Encrypt 功不可没。

九、PKI 的未来

尽管当前的 PKI 体系在实践中运行良好，但它面临着几个方向上的演进压力。

基于 DNS 的命名实体认证(DNS-Based Authentication of Named Entities, DANE)试图减少对 CA 的依赖。DANE 通过在 DNS 中发布 TLSA 记录，允许域名持有者直接指定自己的证书或公钥。验证方通过 DNSSEC(DNS Security Extensions)保护的 DNS 查询获取 TLSA 记录，并据此验证服务器证书。DANE 的价值在于它将信任锚从 CA 转移到了域名持有者本身——即使所有 CA 都被攻破，只要 DNS 基础设施是安全的，DANE 仍然可以提供正确的证书绑定。但 DANE 的部署严重依赖 DNSSEC 的普及，而 DNSSEC 本身的部署率至今仍然不高，这限制了 DANE 在公共互联网上的推广。

证书颁发授权(Certificate Authority Authorization, CAA)是一种更温和的改进(RFC 8659)。域名持有者可以在 DNS 中发布 CAA 记录，声明哪些 CA 被授权为该域名签发证书。CA 在签发证书前必须检查 CAA 记录，如果发现自己不在授权列表中，就必须拒绝签发。CAA 并不能阻止恶意 CA 忽略这一检查，但它与 CT 日志结合后，可以让域名持有者更容易发现违规签发。自 2017 年 9 月起，所有公开信任的 CA 都被要求执行 CAA 检查。

# 查询域名的 CAA 记录
dig example.com CAA +short
# 输出示例：0 issue "letsencrypt.org"
# 含义：只有 Let's Encrypt 被授权为此域名签发证书

后量子证书(Post-Quantum Certificates)是 PKI 面临的最深远挑战。当前 X.509 证书中使用的签名算法——无论是 RSA 还是 ECDSA——都将在大规模量子计算机出现后变得不安全。美国国家标准与技术研究院(NIST)已于 2024 年正式发布了首批后量子密码学标准，包括基于格的数字签名算法 ML-DSA(原 CRYSTALS-Dilithium)和基于哈希的签名算法 SLH-DSA(原 SPHINCS+)。

迁移到后量子证书面临的主要工程挑战在于密钥和签名的尺寸。ML-DSA-65 的公钥为 1952 字节，签名为 3309 字节，与 ECDSA P-256 的 64 字节公钥和 64 字节签名相比，增幅巨大。这将显著增加 TLS 握手中证书消息的大小，对网络延迟和带宽都产生影响。更大的证书链可能导致 TCP 的初始拥塞窗口不够用，需要额外的网络往返才能完成握手。

混合证书(Hybrid Certificates)是过渡期的一种策略：在同一张证书中同时包含经典算法和后量子算法的公钥与签名，确保即使后量子算法被发现有缺陷，经典算法仍然提供保护。但这进一步加大了证书的体积。

短生命期证书(Short-Lived Certificates)也是一个值得关注的趋势。如果证书的有效期足够短(例如仅数天)，那么证书吊销就变得不那么关键——即使无法及时吊销，证书也会在很短的时间内自然过期。这一思路与 Let’s Encrypt 缩短有效期的理念一脉相承，可能最终取代复杂的吊销基础设施。

PKI 的演进从来不是一蹴而就的。每一次改进都需要在安全性、兼容性、性能和部署复杂度之间做出权衡。但有一点是确定的：只要互联网上存在需要验证身份的场景，PKI——以某种形式——就将继续存在。它或许会变得更分散、更自动化、更抗量子，但其核心使命不变：将一把公钥可靠地绑定到一个身份之上。

密码学百科系列 · 第 23 篇

← 上一篇：TLS 协议 | 系列目录 | 下一篇：密码认证协议 →

By .