全球最快DNS服务被挂“假证书”四个月，Cloudflare与微软双双“盲区”？
9月5日消息——近日，Cloudflare公共DNS服务1.1.1.1被曝遭到Fina CA误签TLS/SSL证书。
1.1.1.1是全球用户常用的DNS解析地址之一，被普遍认为是全球最快的公共DNS服务，每天为数百万设备提供域名解析服务。如果其证书遭到滥用，攻击者理论上可能冒充该服务，造成安全风险。Cloudflare表示，此事件是首次观察到针对1.1.1.1公共DNS解析器的未经授权证书签发，未来可能仍有类似尝试。
事件速览
误签证书数量：12张
时间范围：2024年2月至2025年8月
涉及服务：仅1.1.1.1（Cloudflare公共DNS），其他域名未发现问题
是否被滥用：目前没有证据显示攻击者利用这些证书
何时被发现：该问题最初于9月3日由安全研究员Youfu Zhang在Mozilla的dev-security-policy邮件列表中公开报告。
影响范围：
谷歌Chrome、Mozilla Firefox及Apple Safari等主流浏览器未将Fina纳入其受信任的根证书列表。
只有Windows和Edge用户面临潜在风险。
9月3日，微软已承认证书颁发错误，表示正在使用快速撤销机制阻止进一步使用已识别的未经授权的证书。
该公司尚未就为何这些不当颁发的证书在四个月内未被发现发表评论。
Cloudflare已公开确认，公司从未向Fina CA申请过此类证书。
Fina CA回应称，这是“内部测试过程中的误签”，但任何CA在没有验证域名或IP控制权之前，都不应签发证书。
目前所有错误证书已被吊销，Cloudflare正在等待Fina CA提交完整的事故分析报告。
事件背景
Cloudflare运营着公共DNS解析器1.1.1.1服务，数以百万计的设备通过它将人类可读的域名（如example.com）解析为IP地址（如192.0.2.42或2001:db8::2a）。
根据RFC 1034和RFC 1035的原始定义，DNS协议本身并未提供隐私或认证保护。DNS查询和响应通常通过UDP/TCP明文传输，这占了Cloudflare 1.1.1.1服务接收请求的约60%。这意味着任何中间人都可以窃听或篡改DNS数据包，而客户端与服务端无法察觉。
为解决这些问题，Cloudflare参与了IETF多种安全方案的开发与部署，其中与本事件相关的两种是：
•DNS over TLS（DoT，RFC 7878）
•DNS over HTTPS（DoH，RFC 8484）
这两种方式本质上保留了DNS协议的主要功能，但在下层通信中使用TLS来建立加密、认证的传输通道，从而避免明文UDP/TCP带来的隐患。
在TLS握手过程中：
•服务端会向客户端出示一个证书；
•客户端验证该证书是否由其信任的CA签发；
•验证成功后，才会建立TLS连接，确保后续DNS消息的加密与完整性。
与HTTPS网站类似，DNS over TLS/HTTPS使用的也是标准TLS/SSL证书。但存在一个关键区别：
•网站证书通常只包含域名（如example.com）；
•DNS解析器证书则必须包含IP地址（如1.1.1.1），因为客户端无法在连接前解析域名，只能直接连接到已知IP。
例如cloudflare-dns.com，设备通常通过已知IP地址连接到解析器，如1.1.1.1。当使用DoT或DoH时，解析器会出示该IP的TLS证书，客户端验证通过后才发送DNS查询。
客户端必须先与预配置的服务器建立TLS会话，服务器需提供由客户端信任的CA签发的证书，客户端信任的证书集合称为根存储。
事件详情
在此次事件中，Fina CA在未获得Cloudflare授权的情况下，为1.1.1.1颁发了TLS/SSL证书。
这表明Fina CA未能验证请求方是否对该IP地址拥有合法控制权。据Fina CA介绍：
“这些证书原本是用于生产环境中的内部测试。在填写IP地址时发生错误，因此证书被意外记录在证书透明度（CT）日志中。”
虽然尚不清楚Fina CA是否将此行为视为错误，但可以明确指出：在证书透明度日志中发布测试证书本身并非问题，真正的问题在于Fina CA使用生产密钥为未控制的IP地址签发了证书。理应使用其自身控制的测试IP，而非Cloudflare公共DNS解析器的1.1.1.1。
类似的未经授权证书颁发事件在业界并非首次发生。
例如，2024年11月IdenTrust就因操作疏忽错误签发过证书；更著名的案例是2011年荷兰DigiNotar CA被黑客入侵，其密钥被滥用颁发数百张伪造证书。
此类事件促使证书透明度（CT）制度在RFC 6962中得到正式确立。
CT的目的并非直接阻止错误颁发，而是确保所有证书都能被公开查阅，从而在错误发生后能够及时发现。在CT生态中，全球主要有6家机构运营公共日志，记录已颁发证书。
在本事件中，正是因为Fina CA将这些证书提交到了CT日志，研究人员才得以及时发现。此次事件凸显了当前根存储模型可能造成的严重影响——单一证书颁发机构的失误，就可能影响数百万用户依赖的信任体系。
后续措施
Cloudflare介绍称，公司自始至终投入证书透明度（CT）生态系统建设，不仅运营CT日志，还维护监控系统，向客户提供证书异常告警。
然而，这次事件中，公司在自身域名证书监控上出现三次失误：一是1.1.1.1属于IP证书，系统未能触发告警；二是告警和人工审查覆盖不足；三是监控噪声过大，未对所有域名启用告警。
Cloudflare已核查所有相关证书，为防止类似问题再次发生，Cloudflare表示将采取多项改进措施：
告警机制优化：提升对自有域名（包括1.1.1.1）证书签发的告警和升级流程；
CT扩展：推动非浏览器客户端（特别是DNS客户端）采用CT，减少“侥幸发现”依赖（大多数DNS客户端并未强制使用CT包含功能）；
漏洞报告处理改进：优化漏洞奖励计划的报告分流流程，确保异常情况及时被关注；
监控工具升级：在Cloudflare Radar中构建专用UI来探索Radar中的数据，并探索以IP地址作为通用名称的证书。
编辑｜公钥密码开放社区
免责声明
1、本文部分内容来源于网络，不代表本网站立场。本网站对上述信息的来源、准确性及完整性不作任何保证。在任何情况下，本文信息仅作参考。
2、文章重在分享，如有原创声明和侵权，请及时联系本站，我们将在24小时之内对稿件作删除处理。
