pki - PKI 中的信任锚证书

证书将身份绑定到公钥。

假设您收到我的数字签名电子邮件。如果您使用您拥有的公钥验证签名，那么只要您相信人们将私钥保密，您就知道电子邮件来自拥有与该公钥对应的私钥的人。

如果您确定您拥有的公钥是我的（例如，因为我亲自将它交给了您），那么这就是您需要知道的全部内容。问题是你并不总是知道这一点。任何人都可以创建一个密钥对并在整个互联网上发送假称我的公钥，或者设置一个假称是 StackOverflow 的 Web 服务器，或其他任何事情。您可以从独立来源找到 Google 的电话号码并打电话给他们以确认您拥有正确的密钥，但如果您每次想要建立安全的 TLS 连接时都必须这样做，那么电子商务将大大增加比现在低效。

一种解决方案是获取证书。这包含由证书颁发机构进行数字签名的公钥和身份信息（例如姓名和地址、域名、电子邮件地址）。如果您使用证书颁发机构的公钥验证证书中的签名，那么您知道有权访问证书颁发机构私钥的人很乐意签署证书，声明他们同意该身份与该公钥一起使用。如果您相信证书颁发机构不会这样做，除非它采取了合理的步骤来验证这是真的（例如，通过确保他们看到个人的个人身份文件，并验证该个人拥有与公钥对应的私钥） '

但是，即使您有这种信任，这也只是将问题推到了链条上一步，因为要使用证书颁发机构的公钥验证签名中的证书，您首先需要确保您拥有该证书的正确公钥权威。因此，您可能会获得该证书颁发机构的证书，并发现它是由不同的证书颁发机构颁发的，依此类推。

您显然无法验证无限的证书链，因此在某些时候这一切都必须停止。最终，您必须验证您是否拥有顶级证书颁发机构的正确公钥，而无需依赖其他证书，这就是您的信任锚。

所以假设你有一个证书给我，你看到它是由你从未听说过的证书颁发机构 ABC 证书颁发机构签署的。您获得 ABC 的证书并使用其中的公钥来验证我的证书上的签名，这向您证明 ABC 证书颁发机构确实颁发了我的证书。

然后您查看 ABC 证书颁发机构的证书，您会看到它由 DEF 证书颁发机构签名，这是您信任的证书颁发机构，并且您已经拥有自签名证书或信任锚。您使用 DEF 证书中的公钥来验证 ABC 证书中的签名，这向您证明 DEF 确实为 ABC 颁发了该证书。

为了确保我的证书有效，您需要做一些事情并做出一些假设：

您需要获取并信任 DEF 证书颁发机构的（自签名）证书，这是您的信任锚。在大多数情况下，您的浏览器和/或操作系统会预先加载制造商决定信任的一堆 CA 证书，您只会盲目相信制造商对此的判断，但您可以采取自己的步骤如果您愿意，请验证您对自己的信任。
您需要确信 DEF 是一个合法且值得信赖的证书颁发机构，它将保证其私钥的安全，并且不会向任何人颁发证书，除非它有充分的理由这样做。同样，您很可能会信任制造商，但大多数 CA 都会对其证书颁发过程和控制进行定期审核，因此如果您担心，您可以获取该特定 CA 的最后一次审核报告，例如. 请注意，这样做需要您信任审计师的判断，因此无论您走哪条路，在某些时候您都必须信任某个人，因为他们值得信赖。
您需要确信 DEF 不会向 ABC 证书颁发机构颁发中间 CA 证书，除非它有充分的理由相信 ABC 也是一个合法且值得信赖的证书颁发机构，它将保持其私钥的安全并且不会在没有证书的情况下颁发证书好理由。在这里你不直接信任 ABC - 你信任它是因为 DEF 信任它，你信任 DEF。

如果在信任锚和最终用户证书之间的链中存在多个中间 CA 证书，则同样的逻辑适用 - 您实际上信任链中的每个中间 CA，因为链中的前一个 CA 不会t 已经向他们颁发了他们的 CA 证书，除非它确信他们是一个值得信赖的 CA，并且除非它已经验证了中间 CA 证书中的公钥确实属于那个中间 CA。通过使用链中 CA 的公钥验证每个中间 CA 证书中的签名，您可以证明前面的 CA 确实颁发了该证书。由于您明确信任根 CA，那么如果发现您的信任锚位于该链的底部，那么您

归根结底，这一切都是基于这样的想法：您只需明确信任少数知名的根 CA，然后您可以隐含信任互联网上数十亿个其他身份中的任何一个，如果您能找到一系列有效证书可以追溯到一个您明确信任的那些根，并且您是否愿意接受该链中的每个中间 CA 在此基础上都是值得信赖的概念。

现实情况是，证书颁发机构通常对颁发中间 CA 证书非常谨慎，在向第三方机构颁发中间 CA 证书时往往会对其进行限制，以至于颁发给 ACME Inc 的中间 CA 证书可能仅用于为 ACME Inc 员工颁发证书，或仅为以 .acme.com 结尾的域颁发证书，例如。

pki - PKI 中的信任锚证书

问题描述

解决方案

推荐阅读