PKI（Public Key Infrastructure），一般指公钥基础设施，是一个包括硬件、软件、人员、策略和规程的集合，用来实现基于公钥密码体制的密钥和证书的产生、管理、存储、分发和撤销等功能。PKI体系是计算机软硬件、权威机构及应用系统的结合。本文讨论了PKI的弱点，并介绍了两个对策。

先介绍一下依赖方（relying party）这个术语，依赖方是指尝试验证x.509证书的Web浏览器、电子邮件客户软件和聊天应用程序等，依赖方多半通过检查其信任锚中的CA（Certificate Authority，证书颁发机构）是否对证书签名来做到这一点。

通常，我们希望借助依赖方确保证书与正确的服务器进行联系，使其全程无欺诈。

然而，互联网有数百个CA获得我们依赖方的信任，其中一些CA甚至有子CA（Sub CA），能够对证书签名，并获得依赖方的信任，所有这些CA都可以为任何有效的域名颁发证书。因此，任何CA通常都可以为用户的域颁发证书，而用户却浑然不知。由于依赖方会信任该证书（因为它有可信任的CA签名），该证书可用于对用户的域发动中间人攻击。

那么如何解决？以下是有助于缓解该问题的两种技术。

证书颁发机构授权（CAA）

来自RFC 8659中DNS证书颁发机构授权（CAA）资源记录的摘要：“证书颁发机构授权（CAA）DNS资源，记录允许DNS域名持有者指定一个或多个已授权为该域名颁发证书的证书颁发机构（CA）。CAA资源记录允许公共CA实施额外的控制机制，以降低证书意外误颁发的风险。”

CAA使域名持有者能够指定允许哪些CA为我们的域颁发证书，而CA本身承诺尊重我们的CAA记录。RFC 8659定义了以下三个属性：issue含有CA的域作为值，CAA记录授权该CA为某个域颁发证书；issuewild与issue基本相同，但用于通配符证书。如果未设置issuewild，改而使用来自issue的值；iodef含有CAA政策方面有任何问题时要使用的联系信息。

不妨看一下以下示例记录：

example.com. IN CAA 0 issue “letsencrypt.org”

example.com. IN CAA 0 iodef “mailto:[email protected]”

上述示例中的第一行意味着，只有CA Let’s Encrypt可以为域example.com下的任何主机颁发证书，任何其他CA不得为该域颁发证书。第二行提供了一个电子邮件地址，如果有任何问题，用户可以通过它联系证书颁发机构。由于DNS是分层次组织的，因此上述CAA记录适用于web.example.com以及host.web.example.com和host.sub.web.example.com。

不妨再看另一个例子：

example.com. IN CAA 0 issue “letsencrypt.org”

example.com. IN CAA 0 iodef “mailto:[email protected]”

sub.web.example.com IN CAA 0 issue “example-pki.org”

这里，只允许CA example-pki.org为host.sub.web.example.com之类的域颁发证书，第三行中的记录覆盖了来自example.com的策略。当然，CAA资源记录无法阻止不合规CA为其无权颁发证书的域颁发证书，但它们可以人为从嵌入的信任锚中移除这些不合规CA，这意味着在大多数情况下不合规CA会难以为继。另外，还有一种可能性，即授权的CA将证书误颁发给无权使用证书的人，虽然CAA资源记录不会带来百分之百的安全性，但很容易实施并降低证书误颁发的风险。

证书透明度（CT）

RFC 6962摘要显示：“证书透明度是一种实验性协议，用于在颁发或观察传输层安全（TLS）证书时公开记录它们的存在，又允许任何人审计证书颁发机构（CA）的活动，注意可疑证书的颁发以及审计证书日志本身。目的是客户端最终将拒绝接受未出现在日志中的证书，实际上迫使CA将所有已颁发的证书添加到日志中。”

CT为TLS证书提供了一种记账形式，使用户能够检查CA为其域名颁发了哪些证书。为此，用户可以使用一些服务，比如sslmate提供的Cert Spotter，该服务还有本地版。有人曾在虚拟专用服务器上运行其本地版，但是由于过去两年日志变长，似乎无法从头到尾爬取日志。

日志变长表明有许多CA已添加了证书，有专家表示，主要的浏览器早晚会开始只信任带有CT日志条目的证书，并将此作为强制要求。