在Cloudflare，我们引以为豪的一件事是采用了新的协议和标准，帮助互联网更快、更安全。有时这意味着我们将启动对实验特性或仍在开发中的标准的支持，就像我们对tls1.3所做的那样。由于这些功能中的一些还不是最终的性质，我们在一开始就将可用性限制在最热心的用户身上，这样我们就可以观察到这些尖端功能在野外的表现。我们的一些观察结果帮助社区对相应的rfc提出了修订建议。我们从6月份开始在beta标志后面支持DNS证书颁发机构授权（CAA）资源记录。我们这样做的目的是了解这些记录的存在会如何影响公共信任的证书颁发机构颁发SSL证书。我们还希望在2017年9月8日强制执行证书颁发时进行CAA检查，同时不向数百万Cloudflare客户引入新的外部未经证实的行为。这个测试期提供了宝贵的洞察力，关于CAA记录是如何变化的，并将继续改变商业公钥基础设施（PKI）生态系统。从今天起，我们已经删除了这个beta标志，欢迎所有用户添加他们认为合适的CAA记录，而不必首先联系支持人员。请注意，如果您启用了通用SSL，我们将自动增加您的CAA记录，以允许来自我们的CA合作伙伴颁发证书；如果您希望禁用通用SSL并提供您自己的证书，也欢迎您这样做。下面是关于CAA的一些附加细节，这个记录类型的用途，以及自从它第一次被引入以来它的使用是如何演变的。如果您想直接跳到我们实现的细节，请单击此处，我们将带您到帖子的相关部分。公众信任的PKI生态系统-节略在深入研究CAA之前，了解公钥基础设施（PKI）的用途是很有帮助的。很简单，PKI是一个框架，用于在不安全的公共网络上保护各方之间的通信。在"web PKI"中，用于保护web浏览器和此博客之间通信的PKI系统（例如），TLS协议与SSL证书和私钥一起使用，以防止窃听和篡改。虽然TLS处理连接的神圣性，确保没有人可以窥探或扰乱HTTPS请求，但您的浏览器如何知道它正在与blog.cloudflare.com不是冒牌货吗？任何有权访问OpenSSL或类似工具的人都可以生成一个声称对该主机名有效的证书，但幸运的是，您的浏览器只信任由某些知名方颁发（或"签名者"）的证书。这些知名方称为认证机构（CA）。构成的证书的私钥和公钥blog.cloudflare.com是在Cloudflare硬件上生成的，但CA在证书上放置了签名的批准戳。当您的浏览器收到此"叶子"证书时，它会一直跟随颁发者到达它信任的一个"根目录"，验证签名方法，并决定是否接受证书对请求的主机名有效。在贴上这个批准标记之前，ca应该采取步骤确保证书请求者能够演示对主机名的控制。（在某些情况下，正如您将在下面了解到的，情况并不总是如此，这也是引入CAA的原因之一。）人为威胁鉴于人们都是不完美的人，容易犯错误或做出错误的判断，在维护信任方面，PKI生态系统有着相当污点的记录，这一点谁也不奇怪。客户机、CA、服务器和证书请求者都是由犯错误的人创建或操作的。侏罗纪公园。1993年，斯蒂芬斯皮尔伯格[电影]环球影业。众所周知，客户端提供商会向本地信任存储区添加泄露证书或安装软件来拦截安全连接；服务器已被证明泄漏私钥或无法正确轮换会话票证密钥；CA故意错误地颁发了证书，或者未能可靠地验证主机名所有权或控制权；请求证书的个人包括仿冒者，他们创建了令人信服的流行域冒名顶替版本，并获得了有效和可信的证书。这个生态系统中的每一方都有可能导致信任感下降。在这些问题中（大多数问题已经解决或正在解决），最令人不安的可能是受信任的ca故意错误地颁发证书。在知情的情况下，向未证明所有权的各方颁发证书，或在CA/Browser Forum（一个自愿和民主的公共信任证书管理机构）定义的参数之外颁发证书，严重损害了信任存储的价值，该CA颁发的所有证书，以及公共信任的PKI生态系统。解决一个问题。。。为了防止将来被公共信任的ca误发，这些ca提出了一种新的DNS资源记录来帮助降低证书错误颁发的风险：证书颁发机构授权（CAA）资源记录。一般的想法是任何给定域的所有者（例如。，example.com网站)将在其权威DNS提供者添加CAA记录，指定一个或多个ca被授权为其域颁发证书。RFC6844当前为CAA记录指定了三个属性标记：issue、issuewild和iodef。issue属性标记指定有权为域颁发证书的CA。例如，记录example.com网站. CAA 0颁发"认证-权威.net允许"证书颁发机构"CA为颁发证书example.com网站.issuewild属性标记指定仅允许颁发指定通配符域的证书的CA。E、 g.记录example.com网站. CAA 0 issuewild"认证-权威.net只允许"证书颁发机构"CA颁发包含通配符域的证书，例如*。example.com网站.iodef属性标记指定一种方法，用于报告违反颁发者或域名持有者的安全策略的相应域的证书颁发请求或证书颁发情况。E、 g.记录example.com网站. CAA 0碘EF"邮箱：example@example.com"指示发布CA通过电子邮件将违规报告发送到尝试发布时提供的地址。带有issue和issuewild标记的CAA记录是累加的；如果作为对给定主机名的DNS查询的响应返回了多个CAA记录，则这两个记录中指定的ca都被认为是授权的。如果权威DNS提供程序尚不支持CAA记录或区域文件中不存在CAA记录，则当没有记录存在时，发布CA仍然有权发出，这在很大程度上保留了CAA记录成为采用标准之前的发布行为。截至2017年9月8日，所有受公众信任的CA现在都需要在颁发时检查颁发的所有证书的CAA，从而使证书请求者（域所有者）能够指定哪些CA可以为其域颁发证书。... 有更多的问题。RFC6844指定了一种非常奇怪的CAA记录处理算法：对CAA记录的搜索从指定的标签直到但不包括DNS根"."。给定对特定域X的请求，或对通配符的请求域*.X，相关记录集R（X）的确定如下：让CAA（X）是响应执行CAA返回的记录集在标签X上记录查询，P（X）是正上方的DNS标签在DNS层次结构中，A（X）是CNAME或DNAME的目标在标签X处指定的别名记录。o如果CAA（X）不是空的，R（X）=CAA（X），否则o如果A（X）不为空，且R（A（X））不为空，则R（X）=R（A（X）），否则o如果X不是顶级域，则R（X）=R（P（X）），否则o R（X）为空。虽然上面的算法一开始不容易理解，但紧接着的例子更容易理解：例如，如果为X.Y.Z请求证书，则颁发者将按以下顺序搜索相关的CAA记录集：十、 Y.Z.公司别名（X.Y.Z）Y、 Z别名（Y.Z）Z别名（Z）返回空值简而言之，这意味着如果example.com网站请求的证书test.blog.example测试.blog.example.com，发布CA必须在查询CAA记录test.blog.example测试.blog.example.com。。如果此主机名存在CAA记录，则发出CA将停止检查CAA记录并相应地发出问题。如果此主机名不存在CAA记录，并且此主机名作为A或AAAA记录存在，则CA会在DNS树中向上移动到下一个最高的标签。在查询CAA记录博客.example.com.. 与第一次检查一样，如果不存在此主机名的CAA记录，并且该主机名作为A或AAAA记录存在，则CA将继续遍历DNS树。在查询CAA记录example.com网站.在com查询CAA记录。在最后一步的最后，发布CA已经爬过整个DNS树（不包括根目录）检查CAA记录。此功能允许域所有者在其域的根目录下创建CAA记录，并将这些记录应用于任何子域。但是，CAA记录处理算法还有一个额外的检查，即主机名是否作为CNAME（或DNAME）记录存在。在这种情况下，签发CA还必须检查CNAME记录的目标。重温上面的例子test.blog.example测试.blog.example.com。如果此主机名作为CNAME记录存在，则颁发CA必须在查询CAA记录test.blog.example测试.blog.example.com。。因为test.blog.example测试.blog.example.com。作为CNAME存在test.blog.example测试.blog.example.com。CNAME公司测试.blog-提供商.net.