您应该将证书基础设施（即 PKI，公钥基础设施）视为信任网络。

当您与多个想要相互验证自己（及其网站）的人进行通信时，您首先选择一个共同的受信任的人。该第三人成为“受信任的第三方”，将被称为“证书颁发机构”（CA），用于证书管理。

CA 将创建一个主密钥，也称为根 CA 密钥。TTP 将不惜一切代价将私钥保密。公钥将嵌入证书中，该证书将由 CA 的公钥签名。这意味着证书是自签名的，您可以使用其中的密钥验证签名。

现在让我们假设您想要访问 Alice 的网站，但您希望它真的是 Alice 的网站，而不是另一个自称是她的人。Alice 是您社区的一员，因此会联系您同意使用的 CA。她向 CA 发送一个 CSR（证书签名请求），它基本上是一个公钥。CA 执行验证 Alice 是否为 Alice 的过程（例如，负责人亲自与 Alice 会面并从她手中获得 CSR）。当 CA 确定 Alice 是 Alice 并且 CSR 属于她时，CA 可以以 Alice 的名义创建一个证书，并使用 CA 私钥对该证书进行签名。

当您在 Alice 的网站上连接时，您要求提供证书。获得证书后，您想验证它是好的证书。您可以在证书中看到它是由 CA 颁发的。如果您有 CA 密钥，则可以验证签名。如果你相信 CA 正确地完成了它的工作，那么你可以相信这个证书是一个好的证书，并且由于 CA 信任它首先验证了 Alice，那么你可以相信这个证书属于 Alice。

然后，您可以确定使用此公钥加密的消息只会被拥有相应私钥的 Alice 读取。您还确定此证书所签署的任何内容都是 Alice 的签名。

如果 Alice 想要对您进行身份验证作为回报，那么您需要做同样的事情（从 CA 那里获得一个证书，因为 Alice 也信任 CA，她也会信任这个证书）

在您的情况下，由于您似乎掌握了所有端点，您可以简单地创建两个自签名证书（实际上是两个根 CA 证书）并将公共部分交换到另一个端点。每个端点将使用自己的私钥签署传出请求并解密传入消息，并使用另一个端点证书加密传出消息并验证传入消息。

如果您碰巧有很多端点，那么创建自己的 CA 可能是值得的。您生成一个根 CA 证书，然后为每个端点签署证书。您可以在每个端点安装公共根 CA 证书。然后，每次一个端点连接到另一个端点时，被联系的端点可以发送其证书，调用者可以根据根 CA 证书对其进行验证。

第一种方法的优点是直截了当，但妥协一个证书意味着在所有端点上将其交换为一个新证书。第二种方法具有可扩展性的优点，一个端点不必知道存在多少其他端点，因为它无论如何都可以动态验证证书。此外，还有一些方法可以使用证书撤销列表来管理密钥泄露。

您提到的两个选项几乎是正确的：但是，您可以（并且应该）安装自签名证书而不是证书颁发机构证书。

自签名证书和 CA 证书之间的区别在于 CA 证书是一种特殊的自签名证书，其“basicConstraints”设置为“CA:true”（通常设置了关键标志）。此外，CA 证书的 keyUsage 序列将“cRLSign”和“keyCertSign”列为不应出现在常规（非 CA）证书中的用途。

现在回答你的两个问题：

1. 您可以根据自己的喜好将其用作框架级或操作系统级证书，但不要将自签名证书与 CA 证书混淆（见上文）。由于证书似乎只是您的应用程序的特殊用途证书，因此我建议将其用作框架级证书。此外，安装受信任的操作系统级证书可能需要并非所有通信合作伙伴都可能拥有的管理员权限。

2. 不适用（因为 1. 的答案是肯定的 :)）

附带说明：CA 和非 CA 自签名证书之间的区别相关的原因是，您不应允许以验证通信伙伴为目的的自签名证书充当证书颁发机构，因为这可能会带来额外的安全隐患（即使用所述证书作为受信任机构的 MITM 攻击）。

在这里，您尝试在充当双向网络的同时验证和信任这两个网络。受信任的权威证书不同/相同，CA颁发的证书可能不同或相同，它没有任何问题。

注意：不要将自签名证书用于 SSL 通信，并遵循标准 RFC 规则。

如果要在两个网络之间建立通信，有多种方法。1) 隧道建立 2) PTP 3) 基于 SSL： a．只需创建两个不同的 CA 并将其跨网络放置，每个 CA 证书将放置在每个网络中。现在每个 CA 都应该颁发证书，它将由信任验证，现在通信将更加安全。

建立连接后应用程序应该做的是检查接收到的证书的有效性。您可以通过向 pki 点头来做到这一点，即。

1. 您在应用程序上有 CA 证书，可以验证收到的证书的颁发者

或者

2. 一个收到的证书的证书颁发者，即它自己。

这在很大程度上取决于您是在滚动自己的库还是依赖于 api。