CA 证书是由 CA 拥有并标记为适合用作 CA 的证书；即，它包含一个Basic Constraints“cA”标志设置为 TRUE 的扩展。

自签名证书是使用与证书本身中的公钥对应的私钥签名的证书。这意味着证书是由证书所有者自己颁发的，而不是由其他人颁发的。

CA证书可以自行颁发；这是根 CA的正常情况。根 CA 是一个独立存在的 CA，它是先验可信的（手动包含在 Web 浏览器或操作系统证书存储中），而不是由另一个可信 CA 颁发。

如果您设想为许多服务器颁发多个证书（可能很多），则创建一个自签名 CA 并使用它来签署实际的服务器证书（选项 1B）很有用。使用您自己的根 CA（这就是选项 1B 的含义），您只需在所有客户端（您的自签名根 CA）中手动插入一个证书。如果您只有一个服务器证书要生成，并预测事情会保持这种状态，那么选项 1A 与 1B 一样好，可以说更好，因为它更简单。

-des3选项用于CA 密钥的对称加密。这还不错。地球上没有足够的计算能力（或者，就此而言，原始能力）来破坏正确完成的 3DES 加密。使用 AES-256 将毫无用处，而且可能会很困难，因为 OpenSSL 命令行工具不支持开箱即用（OpenSSL，库，包括 AES-256 实现，但命令行当涉及到私钥的对称加密时，工具并不能轻松访问它）。

根据定义，数字签名（应用于证书的签名）使用非对称密钥。非对称密钥需要大量的内部数学结构，而这种结构可以用来削弱它们，因此它们必须比对称密钥大得多才能达到不错的安全水平。这就是为什么一个好的 RSA 密钥必须达到 2048 位左右，而 128 位对称密钥已经坚如磐石。该行：

openssl genrsa -des3 -out server.key 4096

生成一个大小为 4096 位的新非对称 RSA 密钥对，并将其存储在文件server.key. 该存储进一步受到 3DES 的保护（加密），使用从您在该点键入的密码派生的对称密钥。

私钥包括公钥的副本。公钥（当然不是私钥）也将成为证书的一部分：它首先被复制到证书请求（“.csr”文件）中，然后再复制到证书本身中。

CA 与自签名证书

在任何 PKI 安装中，必须将自签名证书（CA 或最终实体 - 例如服务器）分发给所有依赖方。对于您的普通用户，自动部署众所周知的、高度信任的公共 CA 系统。对于较小的基础架构（例如内部企业环境），内部 CA 证书可以自动打包在浏览器、服务器和其他发行版中。在所有情况下，如果证书是自签名的，则必须明确信任它。

最大的区别是：

• 自签名终端实体证书 - 如果您创建多个证书，则您创建的每个证书都必须在每个端点都明确信任。如果证书被泄露，则必须从每个端点删除信任。可以使用自动化脚本来完成，但工作量很大。

• 自签名 CA -> 签名终端实体 - 您必须明确信任 CA，然后每个终端实体都将被自动信任。如果您计划在任何时间跨度内创建多个服务器证书，这将减少工作量。诀窍是，如果有任何服务器证书泄露的可能性（总是存在），您需要一种验证撤销的方法。这就是复杂性的所在——CRL 或 OCSP 是就妥协进行沟通的标准方式，但这意味着要做更多而不是更少的工作来暂存和分发 CRL，以及（可选）暂存和运行 OCSP 服务器。此外，必须配置浏览器来检查这一点——这不是默认设置。

它与您系统中的风险以及您认为证书颁发和撤销的生命周期有很大关系。

DES3 与 AES-256

从openSSL 文档中，您使用您引用的命令的选项是：

• DES
• DES3
• 主意

我推荐 IDEA 作为较新的算法和更好的实践，但如果您的任何系统不兼容，则不推荐。这可能是一个真正的痛苦——试图诊断为什么你不能使用给定的证书和私钥可能会非常令人沮丧，而且大多数系统提供的答案都不清楚且难以理解。

根据此文档：

这些选项在输出之前分别使用 DES、三重 DES 或 IDEA 密码对私钥进行加密。如果没有指定这些选项，则不使用加密。如果使用加密，则如果未通过 -passout 参数提供密码短语，则会提示输入密码短语。

这就是在 server.key 文件中存储和保护私钥的方式。它与证书如何允许您的服务器与其他系统通信无关。

在常规 CA 系统（OpenSSL 可能有点原始）中，有一种方法可以指定如何使用密钥进行加密 - 这可以包括有效的 SSL 设置，例如允许或强制执行 256 位会话密钥。

这不是证书密钥的一个因素（在您的示例中，这是一个 4096 位 RSA 非对称密钥） - 它是根据 CA 及其关联的安全策略允许所表示的密钥对执行的一个因素。这通常控制 SSL 会话的设置方式。

需要明确的是，在创建证书时不会生成 SSL 会话密钥。会话密钥是在客户端与服务器通信时创建和协商的——在证书创建、签名和安装很久之后。

1. 如果一家公司想要生成自己的 CA，他们可以将其包含到他们个人的计算机中，例如用于信任内部网站或代理（在检查 SSL 连接的情况下）。
2. 3 DES 没有被破坏，但 AES - 提供比 DES 更高的安全性并且在计算上比 3DES 更有效。AES 提供三种不同的密钥强度：128 位、192 位和 256 位密钥。3DES本质上是DES加密了3次。
3. RSA 是一种昂贵的算法，并不适合加密每个连接。所以发生的事情是，服务器不是传输使用 RSA 加密的所有内容，而是创建一个由 256 位组成的随机密钥（您可以将这个密钥视为密码，只是一堆随机字符，长度为 256 位）并用RSA 密钥并将其发送到另一端。从这里开始，它们都使用像 AES 这样的对称加密算法（加密和解密数据比 RSA 快得多）来安全地传输数据。

为了：

该文档显示了两种方式：（1A）生成您自己的自签名证书。(1B) 生成您自己的证书/CA，然后使用 CA 签署您的证书。

我不明白两者之间有什么区别。如果没有浏览器信任它（与 Verisign 签署的证书不同），生成您自己的 CA 有什么意义？

即使您的证书未由浏览器信任的 CA 签名，它也可用于加密客户端和服务器之间的流量。这意味着您将通过加密获得所需的保密性。您不会得到访问者浏览器中的绿色小挂锁，它告诉他们您的域所有权已通过证书颁发机构的审查。因此他们将无法验证您网站的真实性（可能是 MITM），但通信将被加密。

自签名证书是所有证书层次结构中的信任根。Verisign 有一个自签名证书，它是他们签署的所有证书的信任根（它可能在某处的地堡中）。如果您希望能够使用证书颁发机构（即创建多个证书并将它们全部作为同一信任链的一部分），那么您应该创建一个自签名证书并使用它来签署其他证书（请参阅openssl req和openssl x509）。

(1B) 是否用于防止 MITM 攻击？

不。您的 (1B) 旨在允许创建多个证书，这些证书都绑定到同一个 CA，就像作者在第一段中所说的那样。基本上，这是一个练习，可以有效地向您展示什么是证书层次结构。

如果是这样，我应该使用（1B）而不是（1A）吗？

对于单个网站，尽管做 1B 是一个很好的练习，但您可以很好地摆脱 1A。

我注意到文档使用了 des3 密码。除非有充分的理由使用 des3，否则是否可以使用 aes-256 密码？（还有我该怎么做？）

Linux 发行版中的一些 openssl 文档缺少它，但您可以使用 256 位 AES 代替-aes256它。-des3同样，也提供 192 位和 128 位变体。检查openssl genrsa --help支持算法列表的输出。至于正确的算法选择：只要不知道算法被破坏，差别不大。AES256 和三重DES（des3）都非常强大。我通常更喜欢 AES，因为它更有效。

openssl genrsa -des3 -out server.key 4096 这条线是否意味着它正在生成一个对称密钥（des3），然后生成一个公钥（RSA 4096 位）？

否。此命令会导致 openssl 创建一个 4096 位 RSA 私钥，该私钥使用三重 DES 加密。系统将提示您输入密码，在您可以将此密钥用于任何目的之前，您必须使用相同的密码对其进行解密。这是为了防止钥匙丢失/被盗时使用。