CA/B Forum 批准证书颁发机构授权(CAA)提案

2013年在RFC6844中规定的证书颁发机构授权(CAA)是一项旨在改善PKI生态系统强度的提议，它通过新的控件来限定哪些CA，使之可以向特定的域名颁发证书。尽管这项关于CAA的提议已经存在了4年，但仅有100到200家网站采用了这项标准，而直到最近情况才有了一些改善。很快这种情况就会有所不同，因为CA/B论坛最近投票批准了将CAA作为其证书颁发标准的基本要求之一。这项措施将在2017年9月正式生效。

任意CA都可以为任意域名颁发证书，这一事实常常被认为是PKI生态系统的最薄弱环节。尽管CA也不想犯错，但却没有技术手段防止它们任意妄为，这就是我们说PKI生态系统是操作中薄弱中的薄弱环节的原因。对数百个CA来说，就有更多潜在的薄弱环节。

CAA创建了一个DNS机制，使域名所有者可以列出允许为他们的主机名颁发证书的CA白名单。这是通过一个叫做CAA(第257类)的新DNS资源记录(RR)操作的。域名所有者可以通过规定CA数量来限制证书颁发;如果允许一个CA颁发证书，那么他们的主机名就会存在于DNS记录中。例如，这是一个(区域文件中)可能的CAA配置：

example.org. CAA 128 issue "wosign.com"

这就是全部。在颁发证书之前，预计CA会检查DNS记录，一旦发现其不在白名单中，就拒绝为其颁发证书。除了例子中的“issue”指令外，还支持其它两个指令：“issuewild”用于限制外卡证书的颁发，以及“iodef”用于在出错的情况下发布通知。(如，数字“128”是一个标志字节，其最高位被设定为1，这意味着该指令必然会被严格遵守。)

在较高层次上，CAA与公钥绑定(HPKP)有相似的目的，但实际执行则完全不同。首先，CAA是阻止证书的颁发，而HPKP是一个可以阻止已颁发的证书生效的运行时的客户端控件。换言之，CAA是给证书准备的，而HPKP是为浏览器准备的。HPKP通过列出公钥白名单来运行，是一个强大的技术控件;相反，CAA很大程度上是一个管理控件。尽管预计CA会在颁发证书前自动检查CAA，但还是不太清楚接下来会发生什么——如果CA相信请求是通用的，那么就会转为手动处理并可能结束这次证书颁发。与HPKP相比，CAA的主要弱点是，CA的数量很多，它们都需要正确执行检查，而且当违反CAA时，还需要抵抗社会工程学的攻击。

但这并不是说CAA没用或低于HPKP。CAA的优势在于，它不像具有潜在危险的HPKP那样，滥用CAA以侵害网络所有权是不可能的。如果配置不当，HPKP可能会摧毁你的业务，但CAA仅会给你带来一些烦恼而已。最后，可以把CAA看成一种“针对普通网络所有权的公钥绑定”技术。这时你就会发现相对而言HPKP既复杂又很难用。

相关资讯：

通过新的CAA标准,HTTPS证书颁发更加安全

CA浏览器论坛投票发布证书颁发机构授权(CAA)标准，SSL / TLS证书在颁发之前必须执行CAA强制性检查，作为防止HTTPS证书错误签发的安全措施。

强制CAA检查，避免证书误签发

证书颁发机构授权(CAA)是一种可选的安全措施，网站运营商可以使用这些措施来保护其域名免于错误发布。它允许域所有者指定哪些证书颁发机构(CA)被允许为其网站颁发证书。

CA/B Forum新规:SSL证书最长有效期将变更为2年

CA/B论坛第193号投票将对所有公开信任的SSL证书的最大生命周期设置新限制，新的证书有效期为825天——即2年有效期，包括更新和更换部分填充内置——将从2018年3月1日起生效。