何时/为什么需要在 TLS 协商中使用 CACert？答案

【问题标题】：When/why would you need to use CACert in a TLS negotiation?何时/为什么需要在 TLS 协商中使用 CACert？
【发布时间】：2018-10-12 13:17:11
【问题描述】：

我正在尝试了解用于配置 TLS 的参数（专门针对 rabbitmq，但我的问题可能更笼统）。

有 4 个主要实体需要考虑：

密钥 - 对等方用来解密发送给它的已使用其公钥加密的消息的私钥。
Cert - 包含对等方公钥的证书它还包含一些识别细节，如主机名、组织等。其中许多是可选的。证书可以是未签名的（如果有的话很少？）、自签名或由证书颁发机构签名。
CACert - 对等方信任的 CA 证书，可用于解密和验证已签名证书的签名。
CA-key - 用于签署证书的 CA 的私钥。

这些映射到配置设置，包括：

enablePeerVerification - 如果为 true，则对等方尝试通过检查证书是否真的由 CA 签名来验证服务器是否是它所说的那个人（同样在信任链上向上直到它到达它信任的 CA，因为它在其本地 CA 信任库中有一个证书）。将此设置为 false 是一个坏主意，因为有人可能会冒充对等方。（在 go 这个选项被称为 InsecureSkipVerify 作为警告）如果证书是自签名的，则无法进行对等验证。此选项允许您改用对等方的自签名证书风险自负（例如在开发过程中）。
Key - 用于解密的私钥
证书 - 用于加密（和握手）
CACert - 签署“Cert”证书的 CA 的证书

为什么有 CACert 的配置设置？

如果证书由 CA 签名，则它已经包含足够的信息来定位 CA（例如域名）。 CACert 的用途是什么，是否或何时在 TLS 协商期间发送？这是否只是为了节省直接前往 CA 的便利？如果 CACert 不匹配或指向您的信任库中的一个，您仍然需要这样做。

我指的是服务器的 rabbitmq.config 中的“cacert”和 C API (rabbitmq-c) 中的 amqp_ssl_socket_set_cacert() 中的设置。

我想检查一下我的理解是否正确 (https://xkcd.com/386/)

【问题讨论】：

这可能是 security.stackexchange.com/questions/93157/… 的副本。服务器将链中的所有证书作为证书消息发送。如果是这种情况，配置设置不应该是包含它们的本地信任存储的位置而不是单个证书吗？
我认为答案可能是 CACert 不是单个证书，而是提供整个链的证书包 (support.comodo.com/index.php?/Knowledgebase/Article/View/1145/1/…)（以根优先顺序连接）。有人可以确认吗？

【解决方案1】：

首先，这里的 CA 私钥在这里无关紧要，因为根据定义它是私有的，因此您永远不会拥有它，除非您使用自签名证书。

TLS 握手是：

根据客户端，您可能会有多个配置项： - 作为中间证书发送的证书列表（作为某个目录的路径或包含所有文件的单个文件）连同它自己的客户端证书 - 您使用的证书列表（同样是目录或文件）作为完全受信任的证书来验证服务器证书。

通常，这两个设置只有一个。

现在：

如果证书由 CA 签名，则它已经包含足够的信息来定位 CA（例如域名）。

不确定是否理解您，但总的来说不会。首先，证书不一定/仅适用于域名，它可以适用于其他事物。然后证书通常由中间人签署，而不是直接由 CA 签署。所以我不确定你想如何找到 CA？

【讨论】：

最后一点可能是我对 CA 一词的误用？我假设 CA 包括根 CA 和中介。您拥有的证书表明链中的第一个中介。我举了一个域名作为例子，因为它可能表明你可以在链中的某个地方获得下一个证书。然而，这似乎是我误解的症结所在。颁发者可以通过 AIA 字段（如果存在）定位，但不是让您离开并获取它，TLS 让您发送一整套证书。也许我的问题应该是为什么不将您的证书包含在您的捆绑包中，即与 CAcert 一起？
所谓的“CA证书”往往是（一个或多个）中间体。由于“真正的”CA 证书（您绝对信任的自签名证书）通常存储在主机上，例如 Unix 上的/etc/ssl/certs，所有工具都在那里查看它，因此不需要在配置中引用它。只需要评估有效性。握手期间也不一定要发送。