首先，我认为您混淆了一些术语。该术语是“数字证书”、“证书”或简称“证书”。不是“数字认证”。如果您真的是指“数字认证”，那么这个答案可能是错误的。

1. 是的。对称密钥用于批量加密，因为对称加密算法比非对称加密算法快得多。
2. 不，这不是保证。所需要的只是服务器和客户端就共享密钥达成一致。通过使用Diffie-Hellman 密钥交换，他们可以就共享秘密达成一致，而无需任何加密。您可以阅读有关算法的详细信息，或者您可以相信 DH 密钥交换允许在不需要任何加密的情况下就共享秘密达成一致。DH 经常（也许主要是，但我没有统计数据）习惯于就共享秘密达成一致。
3. 是的
4. 是的
5. 是的。证书链用于证明所有证书都未被篡改。
6. 受信任的 CA 证书安装在 Windows 中。IE 使用 Windows，而 Chrome 和 Mozilla 安装自己的一组受信任的 CA 证书。
7. 行。你在这里大多是正确的。一些数字签名算法通过使用私钥加密消息的散列来工作。其他算法做其他技巧（我不熟悉细节），但它并不完全相同。因此7，最好将数字称为“签名然后由客户端验证”。通常这将意味着散列和非对称加密，但并非总是如此。
8. 再次，不。通常使用 Diffie-Hellman 密钥交换（2如上所述）。
9. 是的！

关于你的项目符号问题。

我的理解正确吗？

大多数情况下-我在上面进行了更正。

for 2* 是由 Web 客户端创建并发送到 Web 服务器以直接使用（加密）的会话密钥，或者通过交换最终使双方都具有相同会话密钥的信息来设置（Diff hellman 算法？）

Diffie Hellman 如上所述。

5* 我以前从未申请过数字证书。CA颁发数字证书时，它真的颁发数字证书吗？或者它只是发布证书的数字签名哈希。

CA 不像签名请求那样颁发证书。这通常通过向 CA 发送证书签名请求或 CSR来完成。大多数生成证书或密钥的工具都有生成 CSR 的选项。

否则，我们如何在没有 CA 私钥的情况下发送数字证书（原始）及其经过数字签名的散​​列版本？

我不确定你在这里的意思。也许我在上面回答过？

对于 6*，我对 CA 的公钥预装在浏览器中的理解是否正确？

上面已回答，它们随浏览器或操作系统一起提供。我认为 Java 也有自己的列表。可能其他一些常见的应用程序也这样做。

客户端是否需要通过网络服务器进行身份验证？（我读到让客户端也将证书发送到网络服务器）。

这是一个可选步骤。对于大多数应用程序（例如：Amazon 和您的银行），您，作为客户，通过建立一个安全的 HTTPS 连接然后给它您的名称和密码来对站点进行身份验证。一些网站也允许双重身份验证。SSL 的相互认证（AKA：2-way authentication）是 SSL 的一部分，它允许客户端在 SSL 握手期间向服务器进行身份验证。为此，客户端必须具有证书和私钥，并且该证书必须在服务器上预先注册。（请注意，这些证书没有 CA，浏览器信任证书，因为他们获得了证书的副本并被告知要信任它。） 2way auth 方便的部分是它通过魔法发生。无需记住或输入讨厌的密码。（真正）不方便的部分是，必须在所有浏览器（想想移动设备）上管理一组证书和私钥是一件痛苦的事情。有时客户端证书（即：2way auth）也用作双因素身份验证过程中的第二个因素。我的经验是 2way auth 最常用于用户（几乎）总是使用同一台计算机的高安全环境中。

什么将放在 webclient 上的 truststore 中，什么将放在 webserver 上的 keystore 中？

您的意思是在使用 2way auth 时将在信任库/密钥库中放入什么？2way auth 客户端的信任库中没有任何内容。证书及其密钥通常保存在密钥库或其他安全的、通常加密的数据存储中。并且没有任何内容进入服务器的密钥库以进行 2way 身份验证。服务器需要做的就是保留证书的副本并将其与适当的用户相关联。这通常在数据库中完成。

也许您在问标准 SSL 连接的信任库/密钥库中会发生什么？根 CA 证书进入客户端的信任库。这通常由浏览器/操作系统提供商完成，用户无需更改。如果您正在部署自签名证书（即：无 CA）或运行 Web 代理，您可能需要将新证书添加到客户端的信任库。服务器的私钥存储在其密钥库中。为方便起见，证书也经常存储在那里。

当用户访问网站时，为了加密用户与网站之间的通信，需要使用对称密钥。

是的。

*为了让客户端和服务器都使用对称密钥，有关创建对称密钥的信息必须使用非对称密钥进行加密

是的，除非它是 diffie-hellman。

但第一，必须确认网络服务器的真实性。因此，网络服务器向用户/客户端发送其数字证书。在数字证书中，它包含由网络服务器使用的公钥，用于在 2) 处进行非对称加密。

是的。

该数字证书由证书颁发机构颁发，该证书颁发机构将进行检查和验证，以证明网络服务器/域确实属于它应该长期存在的人。

是的 - 这取决于证书的级别。请求的证书是域验证 (DV)、组织验证 (OV) 还是扩展验证 (EV) 证书决定了执行哪些检查。

*然而，我们如何证明数字认证的真实性和完整性？为了完整性，数字证书经过哈希处理并与原始证书一起发送。为了真实性，散列数字证书使用 CA 私钥签名。

是的，证书包括浏览器下载的签名。

*那么如果数字证书是由 CA 私钥签名的，我们如何获得 CA 的公钥？我的总体想法是来自 CA 的公钥已预装在许多浏览器中。

为了让浏览器信任证书，CA 的公钥必须在操作系统或浏览器的证书根存储中。Internet Explorer 和 Chrome 使用操作系统的商店，而 Firefox 有自己的商店。

使用 CA 的公钥，数字签名的散​​列/证书被解密并产生原始散列。然后客户端对收到的证书进行哈希处理，并将其与原始哈希值进行比较。如果 2 个哈希结果匹配，则证书没有被篡改。

不完全的。不要混淆散列、加密和签名。网站的公共证书由 CA（或中间 CA）的私钥签名。只要链产生受信任的根证书，一切都很好。例如

Site CA --signed-by-> Intermediary CA --signed-by-> Root CA

任何人都可以使用 CA 的公钥验证签名是否与散列证书匹配。公钥密码术利用数学方程中的“陷门函数”。使用公钥很容易验证签名是由私钥生成的，但是在没有 CA 的私钥的情况下生成签名在计算上是不可行的。

使用数字证书，网络服务器使用的公钥由网络客户端/用户检索。然后，webclient/用户使用这个公钥来加密构建对称密钥到 web 服务器的信息。

是的，pre-master secret 是用公钥加密的。在 Diffie-Hellman 的情况下，公钥被用来签署共享的秘密。

5* 我以前从未申请过数字证书。CA颁发数字证书时，它真的颁发数字证书吗？或者它只是发布证书的数字签名哈希。

是的，您将收到证书和根据证书哈希计算的签名。

否则，我们如何在没有 CA 私钥的情况下发送数字证书（原始）及其经过数字签名的散​​列版本？

您可以保留私钥。要对证书进行签名，您需要生成证书签名请求 (CSR) 以发送给 CA。一旦他们签署了您的证书，您就可以在您的服务器上安装签名版本以与之前生成的私钥配对。

一些 CA 会为您生成私钥 - 但是，为了安全起见，我建议您自己生成并简单地发送 CSR。

客户端是否需要通过网络服务器进行身份验证？（我读到让客户端也将证书发送到网络服务器）。

是的，您可以使用客户端证书向 Web 服务器验证客户端。不过，这仅用于身份验证，而不是加密。

什么将放在 webclient 上的 truststore 中，什么将放在 webserver 上的 keystore 中？

Web 客户端将发送其证书，Web 服务器可以验证其公钥并检查其是否由受信任的 CA 签名。作为拥有私钥的证明，客户端还签署了可以由服务器通过公钥验证的握手消息。