了解 ssl 文件和机制
understand ssl files and mechanisme
你好，我想让别人向我解释 ssl 是如何工作的，最重要的是向我解释所有这些文件扩展名是什么以及它们的目的是什么，例如我正在尝试连接到 kafka 并且我有一个凭据它在 mu kubernetes 集群中为我的 kafka 提取了秘密，我有多个文件并且不知道它们的用途：所以如果有人可以向我解释什么是 .trustore .keystore .pem .p12 .key 。 crt .ca.crt ...谢谢，我知道它可能含糊不清，但我是使用 ssl 和 kafka 的新手，所以如果有人对此有一些基本的解释，那真的对我有帮助。
感谢您的帮助
这是一个非常复杂的主题，您应该使用 Google。我会尝试在这里回答，但如果您不了解 SSL、PKI 和非对称加密概念，您可能会在我的解释中迷失方向。您可以在 Youtube 上找到视频以及互联网上的大量教程和解释。
每个 SSL 证书由两部分组成：
- SSL 证书本身 - 这是一个 public 部分，它包含通用名称、一些关于证书及其所有者的其他重要信息。最重要的部分可能是 PUBLIC KEY 和 CA 签名
- 私钥 - 这实际上是密码 - 它是私人部分，您绝不能与任何人共享它
私钥和 Public 密钥在数学上相互绑定。您用一个密钥加密的内容可以用另一个密钥解密。拥有 PRIVATE 密钥的人可以轻松地从中派生出 PUBLIC 密钥，但它不能以另一种方式工作。这就是非对称加密的原理。
证书和密钥只是两个文件。扩展并不重要。但为方便起见，.key 后缀用于私钥。对于证书，我们通常使用.crt、.pem或.der。
重要的是证书和私钥是如何编码的。它可以是 PEM 编码或 DER 编码：
- PEM：这是人类可读的格式。你可以告诉 PEM 编码证书，因为第一行包含
-----BEGIN CERTIFICATE----- 行。
- DER：这是二进制格式。如果你在编辑器中打开这个文件，它将是一堆不可读的废话，因为它只是一堆 0 和 1
现在您可以看到后缀 .der 和 .pem 的来源了。 .crt 后缀仅用作 .pem 后缀的替代。好让大家分清楚'this most likely the certificate'.
关于每个证书的重要部分是它必须由某人签名。某人是证书颁发机构。证书颁发机构只是另一个 public/private 密钥对。它由一些高度信任的组织拥有。证书颁发机构可以使用他们的私钥来签署您的证书。他们的私钥非常安全。您可以获得的是 public 键，这就是 ca.crt、ca.pem 或 ca.der 包含的内容。重要的是您可以使用 CA public 密钥来验证其私钥完成的签名。签名是您证书的一部分。
Internet 上有 public 受信任的证书颁发机构，每个 Web 浏览器都信任它们。这些是经过审计和普遍信任的组织。
您可以自己创建证书颁发机构证书和私钥。问题是当您使用它来签署证书时，没有人会信任它。这就是为什么您必须获取 ca.crt 文件并同时提供它的原因。除了您的服务器证书 whatever.crt，您还必须发送 ca.crt 并告诉试图验证它的人 'hey! this is the CA I used to sign that certificate please trust it'。信任与否取决于他们:)
现在 .p12 分机。这是证书的另一种形式。 PKCS#12 是证书 'container' 或 'archive'。您可以将您的私钥文件 (.key) 和您的证书文件 (.crt、.pem 或 .der 文件) 放在一起，并将它们“放在”一个文件中。您可以将其视为 ZIP 存档，但显然它不是 ZIP 文件。您也可以使用密码保护它。您可以使用 openssl 实用程序创建 pkcs#12 容器。
truststore 和 keystore 是 Java 概念。我个人讨厌它们，因为它们只会使事情过于复杂并且不会增加任何价值。大多数 Java 应用程序可以使用 pem/crt/key/p12/der 文件。 Kafka 最近也包括了支持，但我想说它有点不成熟。
truststore 也是包含 'certificates to trust' 的 'archive' 或 'container'。换句话说，它包含证书颁发机构文件（一个或多个）。所以 ca.crt 文件就在那里（不是它的私钥！只是 ca.crt）。它可以包含多个证书。当 Java 应用程序启动时，它将读取文件并信任文件中由证书颁发机构签署的任何证书（例如，当您从 java 连接到某些受 SSL 保护的网页或服务器时）。信任库通常受密码保护。
keystore 也是 'archive' 或 'container'。您从 .p12 存档创建密钥库。所以密钥库包含与 .p12 文件相同的内容。证书+它的私钥。密钥库通常受密码保护。
keystore 和 truststore 是使用 Java keytool 实用程序创建的。如前所述，您需要 .p12 文件来创建它们，因此通常的过程是：
- 我会用
openssl生成私钥
- 我将使用
openssl生成CSR（.csr后缀）或证书签名请求文件——此文件为未签名证书
- 我会将
.csr 文件发送给证书颁发机构，他们将对其签名并提供回 .crt 或 .pem 或 .der 文件（甚至所有这些文件我可以选择）。他们还会向您发送 ca.crt 文件。
- 我将使用
openssl 将 .crt 和 .key 文件放入 .p12 存档
- 我将使用
keytool 将 .p12 存档放入 keystore 存档。
- 我将使用
keytool 将 ca.crt 文件放入 truststore 存档
大多数支持 SSL 的应用程序（我不确定是否是 Kafka，但例如 Elasticsearch）都有一些内置工具可以帮助您设置自己的证书颁发机构和证书以用于 development/testing 目的。它们不适合生产，但我认为很多人都在使用它们 way.anyway.
你好，我想让别人向我解释 ssl 是如何工作的，最重要的是向我解释所有这些文件扩展名是什么以及它们的目的是什么，例如我正在尝试连接到 kafka 并且我有一个凭据它在 mu kubernetes 集群中为我的 kafka 提取了秘密，我有多个文件并且不知道它们的用途：所以如果有人可以向我解释什么是 .trustore .keystore .pem .p12 .key 。 crt .ca.crt ...谢谢，我知道它可能含糊不清，但我是使用 ssl 和 kafka 的新手，所以如果有人对此有一些基本的解释，那真的对我有帮助。
感谢您的帮助
这是一个非常复杂的主题，您应该使用 Google。我会尝试在这里回答，但如果您不了解 SSL、PKI 和非对称加密概念，您可能会在我的解释中迷失方向。您可以在 Youtube 上找到视频以及互联网上的大量教程和解释。
每个 SSL 证书由两部分组成：
- SSL 证书本身 - 这是一个 public 部分，它包含通用名称、一些关于证书及其所有者的其他重要信息。最重要的部分可能是 PUBLIC KEY 和 CA 签名
- 私钥 - 这实际上是密码 - 它是私人部分，您绝不能与任何人共享它
私钥和 Public 密钥在数学上相互绑定。您用一个密钥加密的内容可以用另一个密钥解密。拥有 PRIVATE 密钥的人可以轻松地从中派生出 PUBLIC 密钥，但它不能以另一种方式工作。这就是非对称加密的原理。
证书和密钥只是两个文件。扩展并不重要。但为方便起见，.key 后缀用于私钥。对于证书，我们通常使用.crt、.pem或.der。
重要的是证书和私钥是如何编码的。它可以是 PEM 编码或 DER 编码：
- PEM：这是人类可读的格式。你可以告诉 PEM 编码证书，因为第一行包含
-----BEGIN CERTIFICATE-----行。 - DER：这是二进制格式。如果你在编辑器中打开这个文件，它将是一堆不可读的废话，因为它只是一堆 0 和 1
现在您可以看到后缀 .der 和 .pem 的来源了。 .crt 后缀仅用作 .pem 后缀的替代。好让大家分清楚'this most likely the certificate'.
关于每个证书的重要部分是它必须由某人签名。某人是证书颁发机构。证书颁发机构只是另一个 public/private 密钥对。它由一些高度信任的组织拥有。证书颁发机构可以使用他们的私钥来签署您的证书。他们的私钥非常安全。您可以获得的是 public 键，这就是 ca.crt、ca.pem 或 ca.der 包含的内容。重要的是您可以使用 CA public 密钥来验证其私钥完成的签名。签名是您证书的一部分。
Internet 上有 public 受信任的证书颁发机构，每个 Web 浏览器都信任它们。这些是经过审计和普遍信任的组织。
您可以自己创建证书颁发机构证书和私钥。问题是当您使用它来签署证书时，没有人会信任它。这就是为什么您必须获取 ca.crt 文件并同时提供它的原因。除了您的服务器证书 whatever.crt，您还必须发送 ca.crt 并告诉试图验证它的人 'hey! this is the CA I used to sign that certificate please trust it'。信任与否取决于他们:)
现在 .p12 分机。这是证书的另一种形式。 PKCS#12 是证书 'container' 或 'archive'。您可以将您的私钥文件 (.key) 和您的证书文件 (.crt、.pem 或 .der 文件) 放在一起，并将它们“放在”一个文件中。您可以将其视为 ZIP 存档，但显然它不是 ZIP 文件。您也可以使用密码保护它。您可以使用 openssl 实用程序创建 pkcs#12 容器。
truststore 和 keystore 是 Java 概念。我个人讨厌它们，因为它们只会使事情过于复杂并且不会增加任何价值。大多数 Java 应用程序可以使用 pem/crt/key/p12/der 文件。 Kafka 最近也包括了支持，但我想说它有点不成熟。
truststore 也是包含 'certificates to trust' 的 'archive' 或 'container'。换句话说，它包含证书颁发机构文件（一个或多个）。所以 ca.crt 文件就在那里（不是它的私钥！只是 ca.crt）。它可以包含多个证书。当 Java 应用程序启动时，它将读取文件并信任文件中由证书颁发机构签署的任何证书（例如，当您从 java 连接到某些受 SSL 保护的网页或服务器时）。信任库通常受密码保护。
keystore 也是 'archive' 或 'container'。您从 .p12 存档创建密钥库。所以密钥库包含与 .p12 文件相同的内容。证书+它的私钥。密钥库通常受密码保护。
keystore 和 truststore 是使用 Java keytool 实用程序创建的。如前所述，您需要 .p12 文件来创建它们，因此通常的过程是：
- 我会用
openssl生成私钥 - 我将使用
openssl生成CSR（.csr后缀）或证书签名请求文件——此文件为未签名证书 - 我会将
.csr文件发送给证书颁发机构，他们将对其签名并提供回.crt或.pem或.der文件（甚至所有这些文件我可以选择）。他们还会向您发送ca.crt文件。 - 我将使用
openssl将.crt和.key文件放入.p12存档 - 我将使用
keytool将.p12存档放入keystore存档。 - 我将使用
keytool将ca.crt文件放入truststore存档
大多数支持 SSL 的应用程序（我不确定是否是 Kafka，但例如 Elasticsearch）都有一些内置工具可以帮助您设置自己的证书颁发机构和证书以用于 development/testing 目的。它们不适合生产，但我认为很多人都在使用它们 way.anyway.