0

我试图了解用于配置 TLS 的参数（特别是针对 rabbitmq，但我的问题可能更笼统）。

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

  • 密钥 - 对等方用于解密发送给它的已使用其公钥加密的消息的私钥。

  • Cert - 包含对等方公钥的证书它还包含一些识别细节，如主机名、组织等。其中许多是可选的。证书可以是未签名的（如果有的话很少？）、自签名或由证书颁发机构签名。

  • CACert - 对等方信任的 CA 证书，可用于解密和验证签名证书的签名。

  • CA 密钥 - 用于签署证书的 CA 的私钥。

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

  • enablePeerVerification - 如果为 true，则对等方尝试通过检查证书是否真的由 CA 签名来验证服务器是否是它所说的身份（同样沿着信任链向上直到它到达它信任的 CA，因为它在它的本地 CA 信任库）。将此设置为 false 是一个坏主意，因为有人可能会冒充对等方。（在 go 中，此选项称为 InsecureSkipVerify 作为警告）如果证书是自签名的，则无法进行对等验证。此选项允许您自行承担风险（例如在开发期间）使用对等方的自签名证书。

  • Key - 用于解密的私钥

  • Cert - 用于加密（和握手）

  • 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/）

4

1 回答 1

1

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

TLS 握手是：

  • 您要连接的服务器向您发送其证书，以及（可选）到根 (CA) 的中间证书列表，最后一个也是可选的，并且通常不会发送，因为客户端应该已经在其信任库中拥有它
  • 如果服务器请求客户端证书，它会发送它将接受客户端证书的 CA 列表（这是帮助客户端选择要发送的正确证书的提示）
  • 因此，如果需要，客户端会发送其证书，并以与第一个点相同的方式，将中间证书的潜在列表发送到某个根目录。

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

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

现在：

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

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

于 2018-10-12T15:02:50.590 回答