.gh/.sl/.as 域名注册局遭劫持，伪造谷歌 HTTPS 证书流出，Chrome 已紧急拦截

谷歌确认 .gh、.sl、.as 三个国别顶级域名注册局遭入侵，攻击者篡改权威 DNS 后为多个谷歌域名及其他企业域名签出未授权 HTTPS 证书。Chrome 已通过 CRLSets 拦截，用户无需操作；但谷歌强调浏览器拦截不能作为防线，全域名 CT 监控与绑定 ACME 账户的严格 CAA 记录应尽快配置。

出了什么事：三个国别域名注册局被攻破

2026 年 10 月 6 日，谷歌 Chrome 安全与网络团队（Chrome Secure Web and Networking Team）在官方博客发布题为《Chrome’s Response to Recent ccTLD Registry Hijacks》的公告，披露了一起性质相当罕见的安全事件：.gh（加纳）、.sl（塞拉利昂）、.as（美属萨摩亚）三个国别顶级域名（ccTLD）的注册局基础设施遭攻击者入侵。谷歌在公告开头说明，这一系列事件是「上周」进入他们视野的。

先解释被攻破的是什么。一个 ccTLD 注册局，是管理某个国家/地区顶级域名下所有域名解析的权威机构——它不归谷歌管，而是由相应国家/地区或其授权的第三方机构运营。谷歌在公告中说得很直白：

这些事件不涉及对谷歌系统的任何入侵；攻击者攻破的是第三方 ccTLD 基础设施，这使所有以 .gh、.sl、.as 结尾的域名都暴露在风险之中。

攻击过程并不复杂，但每一步都打在信任链的要害上：攻击者篡改了这些顶级域的权威 DNS 记录，利用这一控制权通过了证书签发机构（CA）的域名控制验证（DCV），最终为覆盖多个谷歌域名以及其他组织域名的目标，签出了未经授权的 HTTPS 证书。

ccTLD 注册局被劫持：未授权 HTTPS 证书是怎么签出来的 — 未授权证书的完整签发链条：攻击者不打你的服务器，打的是「证明域名归你管」的那套基础设施

换句话说：攻击者从头到尾没有碰过谷歌的任何一台服务器。他们只是让「域名解析系统」在 CA 面前替他们说谎——而 CA 的验证流程，恰恰只认 DNS。

事件速览

项目	内容
披露方与时间	谷歌 Chrome 安全与网络团队，官方博客，2026 年 10 月 6 日（称「上周」获悉）
被攻破对象	.gh（加纳）、.sl（塞拉利昂）、.as（美属萨摩亚）三个 ccTLD 的第三方注册局基础设施
攻击手法	篡改权威 DNS 记录 → 通过 CA 的域名控制验证（DCV）→ 签发未授权 HTTPS 证书
受影响范围	多个谷歌域名及其他组织的域名；CT 日志回溯显示另有「多家全球知名品牌和广泛使用的在线服务」受同一系列攻击波及
谷歌系统是否被黑	否，官方明确否认
CA 是否有过错	谷歌：「由于攻击的性质，我们没有理由认为 CA 做错了什么」
用户侧处置	Chrome 已通过 CRLSets 自动拦截，并协同 CA 撤销证书；Chrome 用户无需任何操作

谷歌没被黑、CA 也没做错：问题出在信任链的哪一环

这起事件最容易被误读成「谷歌被黑了」或「CA 出了漏洞」。前者谷歌已明确排除；对于后者，谷歌的表述是「没有理由认为 CA 做错了什么」——因为 CA 按流程验证了「申请者控制着目标域名的 DNS」，而攻击者当时确实控制着。

这正是 HTTPS 信任体系的一个底层设计现实：DCV（域名控制验证）验证的是「谁能控制这个域名的 DNS」，而不是「你是不是这个域名真正的所有者」。在绝大多数场景下，「控制 DNS ≈ 拥有域名」这套等式成立；可一旦权威 DNS 本身被劫持，等式就被人从根部拆掉了。

拿到一张这样的证书意味着什么？The Register 在报道中点明了后果：攻击者同时握有 DNS 路由控制权和一张被浏览器信任的证书私钥，理论上可以拦截、篡改用户与被冒充站点之间的流量，并滥用被冒充品牌的信誉——而用户浏览器里显示的，依然是那把正常的小锁。

Chrome 的处置：CRLSets 拦截、协同撤销、CT 日志扩查

谷歌的处置分了三层：

即时拦截：获悉事件后，Chrome 立即通过内置的 CRLSets（证书撤销列表集）机制自动拦截了这些未授权证书，保护是自动生效的；
协同撤销：与签发证书的 CA 协作完成撤销——按照谷歌的说法，这一步主要保护的是 Chrome 之外的其他客户端（其他浏览器、系统组件、各类 App 内嵌的 WebView 等）；
扩大排查：利用证书透明度（CT）日志的公开数据回溯排查，发现除谷歌外，还有多家全球知名品牌和广泛使用的在线服务也被同一系列攻击波及。Chrome 对这些证书同样做了主动拦截，并在可能的情况下主动联系了受影响组织。

谷歌给用户侧的结论只有一句话：「Chrome 用户无需采取任何行动即可受到保护。」

但谷歌同时明确警告：浏览器拦截不能当作防线

这是整篇公告里信息量最大的段落。谷歌原话：

「由于 DNS 劫持的复杂性，我们无法保证我们的分析找出了每一个受影响的域名；Chrome 的干预措施也不能可靠地保护非 Chrome 用户。」

拆开看是两个坦白：第一，受影响域名的清单可能不完整——CT 日志只能发现「已经签出去的证书」，没被发现的那部分，只能等它暴露；第二，CRLSets 是 Chrome 的私有机制，Firefox、Safari 以及大量 App 内嵌浏览框架的用户，主要依赖「CA 撤销」这条慢得多的路径。

所以谷歌把责任明确交给了「最有条件知道自己域名该有哪些证书的一方」——域名所有者自己：

谁在防护：浏览器侧与域名所有者侧的分工 — 浏览器侧的拦截是兜底，域名所有者侧的 CT 监控与 CAA 才是自己的防线

域名所有者现在该做的两件事（谷歌官方建议）

第一件：对全部域名做持续的 CT 日志监控

Chrome 信任的每一张证书都必须进入公开的 CT 日志，这意味着监控 CT 日志，可以在任何人为你的域名签出证书的那一刻获得近乎实时的告警。谷歌特别强调了监控范围：要覆盖整个域名组合，包括「停放的域名」和「地区性 ccTLD 资产」——没人看管的旧域名，恰恰是攻击者最好下手的资产。如果你的域名在 .gh、.sl、.as 之下，谷歌建议立即复查近期 CT 日志条目，确认没有异常签发。

第二件：配置严格的 CAA 记录，并绑定 ACME 账户

CAA（证书颁发机构授权）是一条 DNS 记录，用来声明哪些 CA 有权为你的域名签发证书。谷歌对它的定位说得很实在：CAA 挡不住进行中的 DNS 劫持——劫持者连权威 DNS 都改了，改掉一条声明毫无难度；但它能完全防住某些基于路由的攻击和 HTTP 验证类攻击，而且真正的价值在劫持结束之后：

CA 被允许缓存并复用已完成的 DCV 验证结果来做后续签发。如果不加限制，攻击者在劫持期间完成一次验证，之后仍能拿着这个「缓存」继续签新证书。而一份将签发限定到特定授权账户与验证方式的严格 CAA 策略，可以在劫持结束后阻止攻击者复用缓存的验证状态来铸造新证书。

为什么 CAA 挡不住劫持过程，却必须现在就配置 — CAA 在劫持进行中、处置中、劫持结束后三个阶段的不同作用

长期方向：缩短证书有效期、限制 DCV 复用

除了给域名所有者的建议，谷歌也给出了生态层面的承诺：通过 Chrome Root Program 和新宣布的 Chrome 抗量子 Root Program（Chrome Quantum-resistant Root Program），推动缩短证书有效期、限制 DCV 结果复用等长期改进，并继续与社区合作，「限制瞬时性路由与 DNS 入侵对 Web 安全的影响」。

这个方向不难理解：证书越好签、越长效，一次 DNS 劫持的「战果」就越保值。把有效期和 DCV 复用窗口压短，等于直接压缩攻击者的获利空间。

目前仍没有答案的三个问题

攻击者是谁：谷歌没有披露任何关于攻击者身份与动机的信息；
注册局是怎么被打进来的：入侵路径、三个注册局的失陷是否相互关联、是否为同一伙人所为，均未披露；
完整的受影响域名清单：谷歌自己都承认「无法保证找全」，短期之内不会有一份权威清单。

对普通站长来说，最后一条尤其重要：不要等「名单公布了再查自己」——按下面的清单主动查一遍，才是正解。

给国内站长和企业的自查清单

1. 先查自己的 CAA 记录

dig example.com CAA +short

如果返回为空，意味着没有任何限制——任何 CA 在通过 DCV 之后都可以为你的域名签证书。建议至少配置到这个程度：

example.com.  CAA 0 issue "letsencrypt.org"
example.com.  CAA 0 issuewild ";"
example.com.  CAA 0 iodef "mailto:security@example.com"

进阶做法是谷歌点名的 ACME 账户绑定（RFC 8657），把签发权限锁定到具体的自动化账户：

example.com.  CAA 0 issue "letsencrypt.org; accounturi=https://acme-v02.api.letsencrypt.org/acme/acct/12345678"

配置前先确认你的 CA 对 accounturi 等参数的支持情况；这条记录的成本几乎为零，今天就可以加。

2. 把 CT 监控挂上

用 crt.sh、Cert Spotter 或各 CA 的到期/签发通知服务，把你名下所有域名纳入监控——重点是停放域名、多年不用的老域名、注册在地区 ccTLD 下的资产。问自己一个问题：十年前注册的那些域名，现在还有人看吗？

3. 域名账户本身加固

注册商账户开启两步验证，开启转移锁；
权威 DNS 托管在与注册商不同的服务商，避免单点被一锅端；
DNS/注册局侧的账号权限最小化，人员变动及时回收权限。

4. 给「证书异常」准备一份响应预案

一旦在 CT 日志里发现非预期签发：第一时间联系签发 CA 请求撤销 → 排查 DNS 记录变更历史，确认解析是否被篡改 → 检查 DCV 验证途径（邮件/DNS/HTTP）是否仍处于可控状态。预案写在平时，比事发时翻文档强得多。

5. 想清楚各层防护的边界，别指望单点兜底

顺便说一个容易走偏的预期：这次事件里，WAF 这类应用层防护拦不住伪造证书——被劫持的流量会以「正常 HTTPS」的形态在链路上被截走，根本不会以「攻击」的形态到达你的 WAF。各层管各层的事：证书信任链靠 CAA 和 CT 监控，域名解析靠注册商/DNS 服务商的账户与变更安全，应用层漏洞和流量攻击才轮到 WAF 与源站加固。分清边界，防护的钱才花在刀刃上。

小结

这不是「谷歌被黑」，而是「域名信任链的底座」被拆：注册局失陷让攻击者可以合法通过 DCV、合法拿到浏览器信任的证书。防御思路必须从「防入侵」扩展到「防冒充」；
Chrome 用户已被兜底，但谷歌明说兜底不可依赖：受影响清单可能不全，非 Chrome 用户的保护并不稳定。域名所有者的安全感只能自己给——CT 监控 + 绑定 ACME 账户的严格 CAA；
最被低估的风险是「没人看管的域名」：停放域名和地区 ccTLD 资产，正是谷歌点名必须纳入监控的部分。现在就翻一遍自己的域名列表。

{{userData.name}}已认证