我试图弄清楚信任锚在 PKI 中如何发挥作用。据我所知，它是证书链的根，用于验证证书是否可信。它如何验证证书？（例如，它如何使用公钥和证书链来验证证书？）
Cro*_*man 10
证书将身份与公钥绑定。
假设您收到我发送的一封经过数字签名的电子邮件。如果您使用自己拥有的公钥验证签名，那么只要您相信人们将私钥保密，您就知道该电子邮件来自拥有与该公钥对应的私钥的人。
如果您确定您拥有的公钥是我的（例如，因为我亲自将其交给您），那么这就是您需要知道的全部。问题是你并不总是知道这一点。任何人都可以创建一个密钥对，并在互联网上假冒我的身份发送公钥，或者建立一个假冒 StackOverflow 的网络服务器，或者其他什么。您可以从独立来源找到 Google 的电话号码，然后致电他们以确认您拥有正确的密钥，但如果您每次想要建立安全的 TLS 连接时都必须执行此操作，那么电子商务将会更加困难比现在效率低。
一种解决方案是获取证书。其中包含由证书颁发机构数字签名的公钥和身份信息（例如姓名和地址、域名、电子邮件地址）。如果您使用证书颁发机构的公钥验证证书中的签名，那么您就知道有权访问证书颁发机构私钥的人很乐意签署证书，表明他们同意该身份与该公钥一致。如果您相信证书颁发机构不会这样做，除非采取合理的步骤来验证其真实性（例如，确保他们看到个人的个人身份证件，并验证该人是否拥有与公钥相对应的私钥）将出现在证书中），那么您可以相信您拥有适合正确个人的正确密钥。
但即使您有这种信任，这也只会将问题推上一步，因为要使用证书颁发机构的公钥验证签名中的证书，您首先需要确保您拥有该证书的正确公钥权威。因此，您可能会获得该证书颁发机构的证书，并发现它是由不同的证书颁发机构颁发的，等等。
显然，您无法验证无限的证书链，因此在某些时候这一切都必须停止。最终，您必须验证您是否拥有顶级证书颁发机构的正确公钥，而无需依赖其他证书来完成此操作，这就是您的信任锚。
假设您有我的证书，并且您看到它是由 ABC 证书颁发机构（您从未听说过的证书颁发机构）签署的。您获得 ABC 的证书，并使用其中的公钥来验证我的证书上的签名，这向您证明 ABC 证书颁发机构确实颁发了我的证书。
然后，您查看 ABC 证书颁发机构的证书，您会发现它是由 DEF 证书颁发机构签名的，DEF 证书颁发机构是您信任的证书颁发机构，并且您已经拥有该证书颁发机构的自签名证书或信任锚。您使用 DEF 证书中的公钥来验证 ABC 证书中的签名，这向您证明 DEF 确实为 ABC 颁发了该证书。
为了确保我的证书有效，您需要做一些事情并做出一些假设：
您需要获取并信任 DEF 证书颁发机构的（自签名）证书，这是您的信任锚。在大多数情况下，您的浏览器和/或操作系统会预加载制造商决定信任的一堆 CA 证书，您只会盲目地相信制造商对此的判断，但您可以采取自己的步骤如果您愿意，请验证并相信自己。
您需要确信 DEF 是一个合法且值得信赖的证书颁发机构，它将保证其私钥的安全，并且不会向任何人颁发证书，除非有充分的理由这样做。同样，您很可能会信任这方面的制造商，但大多数 CA 都会对其证书颁发流程和控制进行定期审核，因此，如果您担心，您可以获取该特定 CA 的最后一份审核报告，例如。请注意，这样做需要您相信审计师的判断，因此无论您采取哪种方式，在某些时候您都必须信任某人，因为他们值得信赖。
您需要确信 DEF 不会向 ABC 证书颁发机构颁发中间 CA 证书，除非它有充分的理由相信 ABC 也是合法且值得信赖的证书颁发机构，它将保证其私钥的安全，并且不会在没有证书的情况下颁发证书。好理由。在这里你不直接信任 ABC——你信任它是因为 DEF 信任它，并且你信任 DEF。
如果信任锚和最终用户证书之间的链中存在多个中间 CA 证书，则同样的逻辑适用 - 您实际上信任链中的每个中间 CA，因为链中的前一个 CA 不会”除非它确信它们是值得信赖的 CA，并且除非它已验证中间 CA 证书中的公钥确实属于该中间 CA，否则不会向他们颁发 CA 证书。通过使用链中前一个 CA 的公钥验证每个中间 CA 证书中的签名，您可以证明前面的 CA 确实颁发了该证书。由于您明确信任根 CA，因此如果发现您的信任锚位于该链的底部，那么您就构建了一条隐式信任链，使您确信您最初感兴趣的最终用户证书是好的。
最终，这一切都基于这样的想法：您只需明确信任少数知名的根 CA，然后如果您能找到可追溯到一个的有效证书链，那么您就可以隐式信任互联网上数十亿个其他身份中的任何一个。您明确信任的那些根，以及您是否愿意接受该链中的每个中间 CA 在此基础上都是值得信赖的这一概念。
现实情况是，证书颁发机构通常在颁发中间 CA 证书时非常谨慎，并且在向第三方组织颁发中间 CA 证书时往往会进行限制，使得颁发给 ACME Inc 的中间 CA 证书只能用于为 ACME Inc 员工颁发证书，或者仅为以 .acme.com 结尾的域颁发证书。
信任关系、信任链、信任锚
信任锚与安全交易期间如何建立信任有关，例如在访问安全网站时。当网站向您提供证书时，您如何知道您可以信任该证书？嗯，因为它是由另一个证书签名的，该证书属于您信任的证书颁发机构 (CA) 实体。（下面详细介绍签名和验证。）但是如何信任CA 证书呢？因为它是由属于您信任的实体的另一个证书签名的。您可以重复询问有关该实体的相同问题并获得有关另一个签名者的相同答案的步骤，直到获得未经另一个证书签名的证书。事实上，它是一个自签名证书。这称为根证书。那么，您如何知道信任此证书？答案是你就这么做，通常是因为它在你安装时与你的浏览器或其他软件捆绑在一起，或者你只是接受你信任这个证书。这组证书与CA证书相关，由另一个证书签名，由另一个证书签名。。。由根证书签名，称为您的信任链，根证书是信任锚，因为它的信任不是从其他证书派生的；它只是被接受为可信的，而所有其他证书都直接或间接地从信任锚获得信任。
什么是数字签名以及如何验证它？
非对称密钥—— 有一对与数字证书相关的数字加密密钥。这对由彼此具有特殊关系的公钥和私钥组成用公钥加密的东西只能用私钥解密，反之亦然。“非对称”是指如果一个密钥用于加密，则另一个密钥必须用于解密，而不是一个密钥同时用于加密和解密。顾名思义，私钥由颁发证书的实体保密，但公钥可供任何人使用，事实上，它包含在公开可用的证书中。非对称密钥对使数字签名以及一般的 PKI 成为可能。
散列（摘要）—— 理解数字签名的另一个概念是散列或摘要。哈希函数将任意大小的数据作为其输入，并生成该数据的固定大小表示作为其输出。此输出称为数据的散列或摘要。复杂的哈希算法（例如 MD5）生成具有以下属性的哈希值：
创建和验证签名 - 可以通过（例如证书）的哈希值，然后使用签名者的私钥对哈希值进行加密来创建签名。所以，签名只是一个加密的哈希值。证书颁发机构 (CA) 使用 CA 证书的私钥为 PKI 证书创建数字签名。签名始终包含在 PKI 证书中。
为了验证签名，验证实体（例如浏览器）将：
因此，因为您可以使用签名者的公钥对签名进行解密，所以您知道它只能使用签名者的私钥进行加密，因此除非私钥已被泄露，否则唯一可以签署该签名的实体证书是签名证书所属的 CA。
因为您使用相同的哈希算法创建了相同数据的自己的哈希，并且它与未加密的签名匹配，所以您知道该签名是根据您尝试验证的证书创建的，并且它没有被篡改。
总之，您已经确定这是一个有效的证书，因为它是由您信任的实体签署的，因为该实体的证书是由您信任的实体签署的，依此类推，直到您通过接受到达您信任的信任锚（根） 。
希望这能回答您的两个问题。