Defaults.Exposed › 修复 › CAA 记录

如何修复 CAA 记录

CAA 记录是你域名设置里的一条简短指令，指定哪些证书公司被允许为你的网站签发那张小锁安全证书。开启它之后，再没有别的公司能悄悄以你的名义创建一张有效证书。

对您业务的关键影响： 没有 CAA 记录，全球数百家证书公司里几乎任何一家都能为你的域名签发一张真实、被完全信任的小锁证书——让骗子能立起一个外观完美、看上去完全安全的你网站克隆版，去收割你客户的登录信息和卡号，而屏幕上没有任何东西会警示他们。

这会让您付出什么代价

• 骗子为你网站的一份副本拿到一张真实证书，于是它显示绿色小锁和 HTTPS——你的客户看不出任何不对，照样输入密码和卡号，而你直到退单和愤怒来电开始时才知道。
• 你的客户被一个像素级还原的登录页仿冒品钓鱼；后续的烂摊子——退款、客服负担、声誉受损——都落在你的品牌上，哪怕你真实的网站从未被碰过。
• 潜在客户的安全或采购团队在签约前对你的域名做一次快速检查，发现没有 CAA 防护，便悄悄把你记为基础薄弱——一份只要五分钟就能加上的设置，却把一笔交易置于风险之中。
• 全球某家证书公司被攻破（这反复发生过——DigiNotar、Comodo、Symantec），而因为你从未指明谁有权代表你行事，你的域名就暴露在那个最终成为薄弱环节的公司面前。

为什么它重要。 眼下大门是敞开的：地球上任何证书公司都能为一个声称是你的网站背书，无论你是否与它打过交道。一条 CAA 记录锁上那扇门，只让你选定的提供商能签发证书——它是对抗有人在网上冒充你这家企业最简单、最便宜的防御。

一句话说清 CAA 记录

每个安全网站都有一张证书——就是浏览器里小锁背后、以及你地址前面那个 https 所代表的东西。这些证书由叫证书颁发机构（CA）的专业机构发放：诸如 Let’s Encrypt、DigiCert、Sectigo、Google Trust Services 这些名字。当你的浏览器看到一张有效证书时，它会显示小锁，并告诉你的客户这个连接真实且安全。

下面这一点，大多数业主从没被告知过：默认情况下，全球数百家这样的证书颁发机构，每一家都被允许为你的域名签发证书——无论你是否听说过它们。一条 CAA 记录（证书颁发机构授权，Certification Authority Authorization）是你加进域名 DNS 设置里的一行说明，大意是只有这些提供商被允许为我签发证书。按行业规则，每一家正规的证书颁发机构在签发前都必须查验那行说明——若它不在你的名单上，就必须拒绝。

这就是一扇任何人都能走进来的没上锁的前门，和一扇只有你选定的人持有钥匙的门之间的区别。而加上它不花一分钱。

这会让你付出什么代价

CAA 记录所封堵的风险，是足以乱真的冒充。当骗子能为你网站的一份副本拿到一张真实证书时，通常的警示信号就消失了——没有破损的小锁，没有不安全的横幅，没有证书错误。一切看上去都对，而这正是它危险的原因。

• **完美的仿冒品。**骗子注册一个相似的地址（或攻破一条通往你客户的路径），拿到一张真实证书，立起一个你登录页或结账页的完美克隆——连小锁都有。客户照常输入密码和卡号。你听到的第一个动静，是一波退单、欺诈举报和愤怒的电话。
• **以你之名的钓鱼活动。**攻击者发送请确认你的账户的邮件，链接到他们带证书的你网站克隆版。因为那个页面看上去完全安全，上当的人更多。善后——通知客户、退款、客服工时、那场尴尬的公开说明——全都落在你头上，哪怕你真实的服务器从未被碰过。
• **卡在清单上的交易。**一个较大客户的安全或采购团队在签约前扫描你的域名。无 CAA 记录会在你名字旁显示为一个红色或橙色条目。技术上是小事，但它读作连基础都不做，足以拖慢或拖垮一份你本来能拿下的合同。
• **被别人的事故连累。**一家你从没打过交道的证书颁发机构被攻破——这不是假想；DigiNotar、Comodo 和 Symantec 都出过严重事件。因为你从未限制谁能代表你行事，攻击者就能通过那家薄弱的 CA 为你的域名拿到一张有效证书。一条 CAA 记录本会拒绝他们。
• **通配符盲区。**即使是对主站很谨慎的企业，也常常忘了子域名。没有 issuewild 规则，一个能拿到通配符证书的攻击者，实际上就一次拿到了你今后会有的每一个子域名的钥匙。

这些都不需要对你服务器发动高深的攻击。它们利用的是这样一个事实：没有 CAA 记录，更广泛的证书系统在替你做事时实在太轻信了。

它实际上是什么，以及良好的状态长什么样

CAA 记录存在于你域名的 DNS 里——就是把你域名指向网站和邮箱的那套设置。每条记录有三部分：一个标志位、一个标签和一个值。要紧的标签有：

• issue——指定被允许为你域名签发普通证书的某家证书颁发机构。你可以有好几条，每个你正当使用的提供商一条。
• issuewild——管控通配符证书（一张覆盖每个子域名的证书，如 *.example.com）。如果你不用通配符，推荐的设置是把它们完全封禁。
• iodef——一个可选的联系地址，当某家证书颁发机构因你的 CAA 策略而拒绝一次请求时，你会在那里收到通知。这是有人尝试过的早期预警。

**良好的状态长什么样：**至少存在一条 issue（或 issuewild）记录，指定了你实际使用的提供商，并且通配符要么被限制给某个指定提供商、要么被封禁。这就是本检查衡量的标准——它跨多个独立的解析器查询你域名的 CAA 记录，当发现一条真实的 issue 或 issuewild 策略到位时通过。一个完全没有 CAA 记录的域名，被当作它本来的样子：一扇敞开的门。

这会影响我的评分吗？会。缺失的 CAA 记录是一个计分项，标为中等严重级——它是一个真实的漏洞，而不只是锦上添花，因为它留着一条真实的冒充通道。加上这条记录就堵住漏洞、清除该发现项。

如何修复（免费，约 5 分钟）

**把这一节交给管理你域名或网站的人——修复是免费的。**它是一个小的 DNS 改动，不是重建。只有当你之后想让我们持续盯着这条记录是否在位时，我们才收费；加上它不花一分钱。

**第一步——弄清你实际使用的是哪家证书颁发机构。**这是唯一值得做对的一步，因为列错提供商会挡住你下一次续期。常见情形：

• Let’s Encrypt——许多主机和控制面板（cPanel、Plesk）都在用 → letsencrypt.org
• Cloudflare（如果由它签发你的边缘证书）→ letsencrypt.org、digicert.com、comodoca.com、pki.goog 和 ssl.com（Cloudflare 使用多家后端 CA；把它仪表盘里显示的那些、或它的完整集合都列上，续期才永不中断）
• Google Workspace / Google Trust Services → pki.goog
• DigiCert → digicert.com
• Sectigo / Comodo → sectigo.com（以及 comodoca.com）
• Microsoft 365 / Azure——微软的托管证书通常用 DigiCert → digicert.com（请在你的门户里确认）

如果不确定，在浏览器里查看你当前的证书（点小锁 → 证书详情 → 颁发者）就能看到是谁签发的。

**第二步——登录你的 DNS 提供商。**这是你域名记录所在的地方——通常是你的注册商、你的 Web 主机，或 Cloudflare。找到 DNS 记录区域，选择添加一条类型为 CAA 的新记录（有些界面把它标为类型 257）。

**第三步——为你使用的每个提供商添加一条 issue 记录。**以 Let’s Encrypt 为例：

example.com.   CAA   0 issue "letsencrypt.org"

每个正当的提供商加一行 issue。大多数 DNS 仪表盘会给你分开的输入框来填标志位（0）、标签（issue）和值（CA 的域名），这样你就不必手敲整行。

**第四步——管控通配符证书。**如果你不用通配符，就干脆封禁它们，免得有人悄悄弄到一张：

example.com.   CAA   0 issuewild ";"

如果你确实用通配符，就改为指定提供商：0 issuewild "letsencrypt.org"。

**第五步——（推荐）添加一个通知地址。**这样每当一家 CA 拒绝一次尝试时你都会被告知——这是有人尝试过的早期预警：

example.com.   CAA   0 iodef "mailto:[email protected]"

**第六步——保存并验证。**运行 dig CAA example.com（或用任意在线 DNS 查询工具），确认你的记录出现。改动在互联网上铺开可能要几分钟到几小时不等。你现有的证书和所有续期全程照常工作——CAA 只管新的签发。

平台速记：在 Cloudflare 上，DNS → Records → Add record → 类型 CAA。在 Google Workspace 上，你在注册商处管理 DNS（如果用了 Cloud DNS 则在那里）——在那里添加带 pki.goog 的 CAA 记录。在 Microsoft 365 上，CAA 不在 M365 管理中心设置；在你域名 DNS 所托管的地方添加它，并列上你的托管证书 CA（通常是 DigiCert）。在常见主机（GoDaddy、Namecheap 等）上，它就在你 A 记录和 MX 记录所在的同一个 DNS 面板里。

常见错误

• **列错了 CA——或漏了一个。**现实中最大的风险不是安全，而是挡住你自己的续期。如果你用了不止一家签发机构（比如主站一家、Cloudflare 后面又一家），就把它们全列上。拿不准时，宁可多列几家你信任的，也别列得太少。
• **设了 issue 却忽略通配符。**一个限制了普通证书、却对通配符只字不提的域名，仍然敞着那条更强大的通配符通道。务必把 issuewild 也设上——要么指向你的提供商，要么用 ";" 封禁它。
• **把 CAA 放在错误的名称上。**CAA 由证书颁发机构针对正被签证的确切名称、沿树向上读取。把它设在你域名的顶层（顶点，如 example.com）是正确做法——除非某个子域名设了自己的，否则它默认覆盖各子域名。
• 以为你的平台已经做了。Cloudflare、Google 和 Microsoft 管理证书，但不会替你添加 CAA 记录。除非你加了，你的域名仍是敞开的。
• **当作一劳永逸、不再监控。**日后的一次 DNS 迁移、一次注册商变更，或一次记录大扫除，都可能悄悄丢掉你的 CAA 防护。每次 DNS 改动后，值得检查它是否还在。

技术层（把这一段交给你的 IT 人员）

CAA 定义于 RFC 8659，并在 CA/Browser Forum 基线要求下强制执行——每家公开受信的 CA 都必须在签发时查验 CAA。记录形如 <flags> <tag> <value>，标签有 issue、issuewild 和 iodef。满足本检查的是一条非空的 issue 或 issuewild 策略；仅有 iodef 不行（它是上报，不是授权）。

顶点处一个稳妥的基线：

example.com.   CAA   0 issue "letsencrypt.org"
example.com.   CAA   0 issuewild ";"
example.com.   CAA   0 iodef "mailto:[email protected]"

给实施者的说明：

• **CAA 沿树向上：**CA 从被请求的 FQDN 向上评估 CAA，直到顶点，并在第一个设有 CAA 记录的名称处停止。因此，顶点处的一条记录会保护所有子域名，除非某个子域名发布了自己的——它可以这样做，当某个特定子域名使用不同签发机构时很有用。
• issuewild 中的 ; 值意为任何 CA 都不得签发通配符——一个显式拒绝。凡是通配符不属于你方案的，都用它。
• 0 标志位是签发方关键标志；常规使用下 0（非关键）是正确的。除非你完全理解，否则不要设关键位，因为一个被误解的关键标签可能导致合规的 CA 拒绝签发。
• **多个签发机构：**允许多条 issue 记录且是叠加的——把你技术栈中每一个正当的 CA（包括你 CDN/边缘提供商使用的后端 CA）都列上，以防续期失败。
• 验证：dig CAA example.com +short，或通过 CA/Browser Forum 的 CAA 测试工具核对。本检查本身会跨多个独立解析器查询 CAA（先本地 DNS，再以 Google、Cloudflare 和 Quad9 的 DNS-over-HTTPS 作为兜底），并接受第一个权威答复，因此单个解析器故障不会产生假的无 CAA 结果。
• **与 DNSSEC 搭配：**CAA 告诉 CA 谁可以签发；DNSSEC 则阻止 CAA 答复本身在传输途中被伪造。它们是互补的——对高价值域名，两者都跑。

在您的托管服务商上完成设置

热门服务商的分步指引：

• 在 GoDaddy 上设置 CAA
• 在 Namecheap 上设置 CAA
• 在 Cloudflare 上设置 CAA
• 在 AWS Route 53 上设置 CAA

常见问题