为什么要使用CAA？
计算机科学家 Phillip Hallam-Baker 和 Rob Stradling 开发了 CAA，以应对公众对受信任证书颁发机构安全性日益增长的担忧。该计划隶属于互联网工程任务组 (IETF)，该组织是互联网的领先标准开发组织 (SDO)。IETF 制定的自愿标准被互联网用户、网络运营商和设备供应商广泛采用，影响着互联网的发展。
IETF 在出版物 RFC（征求意见稿）中记录了其技术标准。这些文档概述了互联网基础设施的关键方面，包括寻址、路由和传输技术。CAA 的具体定义如下： RFC 6844.
证书颁发机构 (CA) 总是使用以下方法 域验证 确保每个SSL /TLS 证书申请被授权（通常通过确保使用该域以某种方式将其链接到特定站点）。
例如，CA可能会向请求者提供特殊的验证文件。 将该文件放置在网站上可证明请求者也控制了该网站，但不能保证 合法 该控件。 掌握了网站控制权的黑客可能会伪装成合法所有者，然后可以请求并接收SSL /TLS 通过任何CA标准检查的证书，因此 似乎 合法。 然后，他们可以转身使用该SSL /TLS 该网站或其他地方的恶作剧证明。
CAA通过定义允许哪些CA颁发域证书（甚至完全限制证书颁发）来帮助阻止这种利用。 这限制了劫机者可能造成的损害-即使他们控制了某个网站，但他们对恶意SSL /TLS 证书。
什么是 CNAME？
CNAME 记录是一种 DNS 配置，允许一个域名，例如 store.mybusiness.com，作为另一个的别名，例如 mybusiness.com。无需管理多个 A 记录来反映 IP 地址变化，CNAME 通过将别名指向目标域来简化此过程。这种方法对于经常切换网络主机或 CDN 提供商的企业非常有益。此外，CNAME 记录对于构建故障转移系统非常有用，在故障转移系统中，流量从主服务器定向到辅助服务器，确保中断期间的服务连续性。
在证书颁发机构授权 (CAA) 的背景下，CNAME 记录通过将 CAA 检查重定向到目标域来影响该过程。例如，如果 店铺主页 个人中心 关注我们 店铺信息 使用 CNAME 指向 我的网站执行 CAA 检查的 CA 将评估以下记录： 我的网站 验证颁发证书的授权。如果 CAA 记录 我的网站 未授权 CA，则无法颁发证书。即使域利用 CNAME 记录进行 DNS 别名，这也能确保一致执行 CAA 策略。
CAA如何运作
CAA使用DNS
此 域名系统 （DNS）是Internet基础结构的关键部分。 任何域的所有者都维护DNS记录（在所谓的内部 区域文件），将其域名指向托管其网站的IP地址，然后输入 google.com 进入浏览器窗口而不是 216.58.194.46.
DNS记录通常用作“ Internet电话簿”，但是DNS还允许其他类型的特殊记录，这些特殊记录可以将其他信息分配给域名。
CAA记录
CAA使用一种特殊的记录，称为 证书颁发机构授权资源记录 （CAA记录）。 这些都是使用DNS发布的，域所有者只需将CAA记录添加到他的其他DNS记录中即可。 CAA记录包括 行李牌 配备 折扣值，并且标记值对称为“ a” 财产。 还设有一个 旗 指示此属性的重要性。 这是一个什么样子：
example.com。 CAA 0问题“ ssl.com”
在这里， example.com 是该记录适用的域，CAA让我们知道这是哪种记录。 的 0 是标志（零是默认值）。标签是 问题 并且该值（用引号引起）是 ssl.com，它们共同构成了物业。
旗
标志目前只有两个严格定义的状态： 0 （非关键）和 1 （危急）。 严重标志告诉CA 必须 完全理解属性标签才能继续。RFC 6844 为用户定义标志的使用留下了其他可能性（下文将详细介绍）。
标签
RFC 6844定义了三个通用标签的使用： 问题, 发行狂 和 碘定义。 （与标志一样，它允许其他潜在的自定义标签类型。）
此 问题 行李牌
此 问题 标签指定授权哪个（如果有）CA颁发该域的证书。 例如，域example.com的所有者可以使用以下DNS区域文件将证书颁发限制为一个CA（在此为SSL.com）：
example.com。 CAA 0问题“ ssl.com”
域所有者可以选择为一个域设置多个区域文件：
example.com。 CAA 0问题“ ssl.com” example.com。 CAA 0问题“ comodoca.com”
以上记录限制了SSL /TLS 签发证书 example.com 到两个CA（SSL.com和Comodo.com）。
此 问题 记录还授权命名的CA为指定域的任何子域颁发证书。 因此，允许SSL.com的记录可以允许为 example.com 以及诸如 www.example.com, 邮箱.example.com 甚至是特殊的通配符子域 * .example.com.
CAA记录可用于 限制 证书发行也是如此–该记录告诉使用CAA的证书颁发机构 没有 SSL /TLS 证书应签发 example.com 和子域 任何 CA：
example.com。 CAA 0问题“;”
（本例中的分号表示“这里什么都不允许“，但正如我们稍后将展示的，它也用于定义自定义参数。）
请注意，除非由…修改，否则标准发行标签允许CA颁发通配符证书。
此 发行狂 行李牌
此标记指定授权CA颁发所有者域的通配符证书（即 * .example.com).
通配符可以表示无限数量的子域名，因此在颁发通配符证书时需要特别小心和注意。 发行狂 标签使域所有者可以定义哪些CA可以与主域或其他子域分开颁发通配符证书。 发行狂 标签优先于任何 问题 标签。 他们使用与 问题 标签。 一些例子：
example.com。 CAA 0问题“ ssl.com” example.com。 CAA 0 issuewild“;”
以上内容允许SSL.com颁发证书以用于 example.com 以及所有子域 除 通配符 * .example.com。 （不允许SSL.com或任何其他CA颁发通配符证书用于 example.com.)
example.com。 CAA 0问题“;” example.com。 CAA 0 issuewild“ ssl.com”
这个例子禁止 所有 CA颁发证书给 example.com 及其子域，但创建了一个例外，以允许SSL.com颁发通配符证书（和 仅由 通配符证书） example.com.
此 碘定义 行李牌
第三个定义的标签是 碘定义。 此标签可用于向域所有者报告无效的证书请求，它们看起来像这样：
example.com。 CAA 0 iodef“ mailto：certissues@example.com” example.com。 CAA 0 iodef“ certissues.example.com”
最上面的记录提供了向该地址发送电子邮件通知所需的CA信息 certissues@example.com。 第二个命令指示CA将事件消息发布到Web服务（由域所有者为此目的设置），网址为 certissues.example.com。 （可以使用这两种方法中的一种或两种，这取决于CA和域所有者如何设置其操作。）
碘定义 帖子使用一种称为 事件对象描述交换格式 或IODEF –因此得名。 （IODEF在 RFC 6546.)
issuemail 标签 S/MIME
CAA 的一个重要发展是扩展至 S/MIME （安全/多用途互联网邮件扩展）证书，在 RFC 9495 中正式化。 S/MIME 证书通过身份验证、数据隐私和消息完整性来提供电子邮件安全。CA/浏览器论坛引入了一个名为“issuemail”的新 CAA 属性标签，专门用于控制 S/MIME 证书.
自 15 年 2024 月 XNUMX 日起，建议 CA 对以下对象实施 CAA 检查： S/MIME 证书，须于 15 年 2025 月 XNUMX 日前强制实施. 电子邮件地址的标准 CAA 记录表格如下所示：
mail.client.example CAA 0 issuemail“authority.example”
CAA 扩展到电子邮件证书，为域名所有者提供了对电子邮件证书的同等级别的控制 S/MIME 证书颁发 TLS 证书，降低未经授权颁发证书的风险.
CA定义的标志和标签
RFC 6844中描述的CAA仅专门定义了两个标志状态（0和1）和三个标签（问题, 发行狂 和 碘定义）。 但是，它使设计足够开放，以便CA创建并利用自定义标签和标志来定义其证书颁发过程。 例如：
example.com。 CAA 0问题“ SSL.com; policy = ev”
该记录使用标准 问题 标签带有额外的参数，该参数指示CA在为此域颁发证书时使用其扩展验证（EV）策略。
example.com。 CAA 128 pca“ PCA = 12345”
域所有者可以将此记录与新的CA定义一起使用 PCA 标签以显示他们拥有“首选客户帐户”，并将帐号设置为参数。 （该标志也可以是一个自定义值，最多可以为255。）根据CA设置帐户的方式，这可能允许特定的计费方式，额外的帐户定义的验证或其他特殊处理。
利与弊
使用 CAA 有几个很好的理由。主要和最重要的优势是 CAA 能够大大降低证书错误颁发的风险。这有助于保护您的域名、您的业务和您的在线身份。可能在特定 CA 软件中发现错误的潜在攻击者无法利用它为您的域名颁发 SSL 证书。此外，使用 iodef 标签可让您在尝试利用时获得报告。
CAA的设计提高了安全性，但也可以允许对资源进行更详细的分配-例如，公司可以设置记录，以允许（或限制）销售和营销部门从指定来源购买用于sales.example.com的SSL证书。
另外，CAA提供了极大的灵活性。 对于域所有者，它使用由自己控制的DNS资源记录，并且可以根据需要进行更改，因此它们不绑定到特定的CA（并且可以授权多个CA授予任何给定域名的问题记录） 。 对于CA，即使是自定义用途，CA / B论坛（为CA和浏览器安全问题设定标准的小组）新采用的规则也可以使CAA记录用于验证目的，这是使用它们的另一个很好的理由。
一个缺点是，即使有 CAA 记录，用户也无法 执行 由证书颁发机构使用。 CA必须符合RFC 6844才能执行这些记录，而不符合要求的CA可能会简单地忽略域所有者在其CAA记录中声明的明确意愿。
域所有者和CA也必须正确配置CAA。 让我们最近加密（确实支持CAA） 报告了其代码库的一个小问题 不幸的是，这导致CAA规则被忽略，并误发了六份证书。 这些都不是恶意异常（对于让我们加密团队在发现后数小时内解决和报告该问题，我们深表感谢）。 但是，这强调了一个合规的证书颁发机构 必须 实施CAA 完美无瑕.
另一个潜在的问题是CAA对DNS的依赖。 除非域所有者保护其名称服务安全，否则这可能是攻击的载体。 RFC 6844建议实施 域名系统安全扩展（DNSSEC），它使用经过数字签名的DNS记录来认证数据并应对DNS欺骗的威胁。
最后，即使适当地实施了CAA并正确实施了CAA记录，也无法完全阻止发行恶意证书。 尽管CAA是限制攻击者选择的有用且重要的工具，但是具有足够访问权限的劫机者（例如，通过控制DNS或通过社会工程）可以绕过它。
结语
作为更广泛的安全生态系统的一部分，证书颁发机构授权具有巨大的潜力，而广泛采用和实施 CAA 将防止证书错误颁发。尽管 CAA 本身无法阻止每一次证书错误颁发，但它是朝着正确方向迈出的良好一步，SSL.com 希望您考虑自己使用 CAA 记录。
案例
- RFC6844：DNS证书颁发机构授权（CAA）资源记录
- RFC5070：事件对象描述交换格式
- RFC6546：通过HTTP /传输实时网络间防御（RID）消息TLS
- RFC4033：DNS安全性介绍和要求
- CA / B论坛投票125 – CAA记录
- 有关DNS证书颁发机构授权的维基百科条目
