信任的供应链：Web PKI的修修补补与DNSSEC的未竟之路
内容提要
文章以eMudhra私钥过弱和GoDaddy大规模吊销证书为例，指出Web PKI由众多水平参差的商业CA并联构成，任一CA出问题都可能波及任意域名，整体安全取决于最弱一环。浏览器厂商通过CAA、证书透明度、CRLite等层层打补丁，却边缘化了非Web协议和难以升级的物联网设备。作者认为DNSSEC与DANE虽不优雅，但能将信任收敛回域名层级，值得认真推进。
延伸解读
并联信任的脆弱性：任一CA失守即全局风险
文章指出，Web PKI的根证书库内置数十家受信任根CA，并级联出更多中间CA。在无名称约束等限制时，任何一家受信CA都可能为任意域名签发证书，形成“并联”信任关系。这意味着即使你自己的服务器和域名防护到位，只要其中一家CA出现私钥泄露或配置错误，非其客户的域名也可能受影响。整体安全取决于最弱一环，而非平均水准。
浏览器补丁的边界：保护Web，边缘化非Web与物联网
CAA、证书透明度、CRLite等机制主要内置于浏览器，能提升Web安全性，但非HTTP协议（邮件、数据库、后台守护进程）需自行集成维护，难以自动获得同等保护。物联网设备固件常打包历史根证书库，缺乏可靠OTA，即使浏览器厂商拉黑CA，这些设备仍可能信任弱密钥签发的证书。eMudhra中间CA还获得老根交叉签名，进一步扩大影响面。
DNSSEC与DANE：收窄授权路径，但工程成本未消失
DNSSEC沿根、顶级域、二级域名的树状层级逐级签名授权，DANE通过TLSA记录直接锚定终端公钥，使域名所有者无需依赖公共CA背书，也不受CAA遵守情况或吊销推送及时性影响。但文章强调，DNSSEC自身存在报文尺寸、密钥轮转与DS同步的运维负担，以及否定应答的复杂性；信任链仍依赖根、父区域、注册与DNS托管环节的安全，缓存和物联网信任锚维护成本依然存在。
Q&A
eMudhra 的私钥问题具体是什么？为什么说它很离谱？
eMudhra 有 8 个中间 CA 使用 P-384 椭圆曲线，但私钥标量全都不超过 8 位，其中 6 个用于 TLS，2 个用于代码签名。这意味着任何人用普通硬件就能瞬间穷举出私钥，而且这些证书在 2025 年 4 月签发，直到 2026 年 10 月才被吊销和封禁。
GoDaddy 为什么大规模吊销证书？影响了多少张证书？
GoDaddy 签发的证书与 CP/CPS 中记载的证书配置不一致，因此启动了大规模证书替换和吊销。截至 10 月 22 日，共有 403,643 张证书受影响，其中 378,067 张被吊销，另有 25,576 张已经过期。
Web PKI 的信任模型为什么被认为脆弱？
Web PKI 在根证书库中内置了数十家受信任的根 CA，背后又级联出更多中间 CA。这些机构分布在世界各地，工程水平参差不齐，受制于属地法律与商业利益。在现行信任模型下，对没有名称约束等限制的 CA 而言，它们在域名签发权限上近似于「并联」关系：任何一家都可能为任意域名签发证书。因此，即使你自己的服务器和域名防护得当，只要其中一家 CA 出问题，即使你不是它的客户，也可能受到影响。整体安全性取决于最弱的那一家。
浏览器厂商用了哪些补丁来弥补 Web PKI 的不足？各自有什么局限？
主要补丁包括：1）CAA 记录，允许域名所有者声明只允许某几家 CA 签发证书，但它只是「君子协定」，约束力取决于 CA 是否遵守，浏览器不会用 CAA 验证证书；2）证书透明度（CT）日志，强制校验 SCT 能拒绝未合规的证书，让攻击者不能悄无声息地使用伪造证书，但 CT 不判断域名控制权，也不能阻止误发本身；3）证书吊销机制，如 CRL、OCSP，但 OCSP 因隐私和延迟问题正在退场，CRLite 等浏览器侧机制只覆盖部分客户端。这些补丁主要长在浏览器里，边缘化了非 Web 协议和物联网设备。
为什么说物联网设备在 Web PKI 体系下几乎无解？
物联网设备固件常打包历史版本的根证书库，长生命周期设备既没有能力运行浏览器级吊销推送组件，也缺乏高频可靠的固件空中升级机制。即使浏览器厂商及时拉黑某个 CA，这些设备仍可能继续信任该 CA 签发的证书，或任何人用泄露私钥签出的证书。例如 eMudhra 的中间 CA 还拿到了 Sectigo 旗下 2004 年老根的交叉签名，广泛存在于历史根证书库中，设备若拿不到交叉证书的吊销信息，就可能沿链信任弱密钥签出的证书。
DNSSEC 和 DANE 相比 Web PKI 有什么优势？为什么作者认为值得推进？
DNSSEC 与 DANE 能将信任收敛回域名层级：授权路径唯一，从根域到顶级域再到二级域名逐级签名授权，路径之外的机构无权置喙；不再依赖公共 CA 背书，域名所有者可通过 TLSA 记录直接声明只认特定公钥，即使某家 CA 被攻破或误发证书，客户端也能拒绝连接；与上层协议无关，可服务于邮件等非 Web 协议。虽然 DNSSEC 并不优雅，存在报文尺寸、运维负担、否定应答妥协等问题，但它能被跑通且有效，值得认真推进。
