SSL 证书验证

Question

我想知道通过 HTTP 进行证书身份验证的具体步骤是什么。 我知道以前有人问过这个问题，但从我读到的内容来看，我仍然不清楚它是如何工作的。

1. 第一次联系安全站点时，客户端将发送其证书

   • 这将是他的公钥（假设是一个 public_key.pem 文件以 ----BEGIN PUBLIC KEY---- 请求）

2. 服务器将查看此证书是否已由受信任的 CA 签名。

   • 服务器只有一个它信任的证书列表（您在配置 SSL 时配置此密钥库）。那是存储所有私钥的地方。这是否等同于服务器的所有受信任 CA？
   • 现在下一步是获取 public_key.pem 并检查密钥库中的任何证书是否已对其进行签名。

如果上述过程是准确的：

第一个问题：“证书”是由另一个证书（或自签名）签名的私钥

第二个问题：服务器如何验证公钥是否使用特定的私钥（证书）签名？

第三个问题：'certificate' A 可以用来签署另一个'certificate' B，因此是'certificate' B 可用于签署证书C等。如果我的服务器在其信任库中有证书 A，这意味着它也会信任来自证书 B 和 C 的公钥？

根据以下答案进行编辑

我的服务器有 cert.pem 和 privkey.pem。 cert.pem（x509 证书）已由受信任的 CA 使用其私钥签名（“签名”过程涉及 CA 使用其私钥“做某事”并签署我的证书签名请求)。

协商 SSL 时，我的服务器会将 cert.pem 发送给客户端（以某种形式）。客户端如何确定我的公共证书是由受信任的 CA 签署的。我的信任库 pb 仅包含受信任 CA 的其他公共证书，因此它最终会检查我的 cert.pem 是否仅使用受信任 CA 的公共证书进行签名。 这是不清楚的部分 - 我可能误解了整个过程 - 客户可以通过仅拥有受信任 CA 的 x509 证书列表来检查我的 x509 证书是否有效吗？

Answer 1

第一次联系安全站点时，客户端将发送其证书

客户端不必发送证书。从您的问题来看，听起来您并不是在专门询问客户端证书身份验证。在许多站点中，例如如果您访问 google、stackoverflow、facebook 等，客户端/浏览器将不会发送证书。

“证书”是由另一个证书（或自签名）签名的私钥

不完全是。一个证书包含一个 public 密钥，该密钥由对应于另一个证书的私钥签名。

我认为这值得澄清。证书本身只会包含公钥，或 x509 用语中的“主题公钥信息”。该公钥对应的私钥与 x509 证书分开存储。

有些格式可以将证书和私钥“组合”到一个文件中，但此时它不再是证书，而是包含证书的文件 - PKCS#12 就是一个例子.这是一种可以根据需要存储尽可能多的证书和私钥的格式。

私钥甚至不一定是磁盘上的文件 - 它可能在硬件安全模块、智能卡等中。

'certificate' A 可用于签署另一个'certificate' B，因此'certificate' B 可用于签署证书C 等等。如果我的服务器在其信任库中有证书 A，这意味着它也会信任来自证书 B 和 C 的公钥？

是的。这称为证书链。 A 是“根”证书，B 是“中间”证书，C 是“最终实体”或“叶”证书。

这在 CA 的 HTTPS 证书中很常见。证书永远不会直接从根上颁发，它们是从中间颁发的。

服务器如何验证公钥是否使用特定的私钥（证书）签名？

这是假设证书是私钥，但事实并非如此。

服务器，就像服务 HTTPS 的东西一样，并不真正关心证书的有效性。由客户端决定它是否应该信任服务器提供的证书。

服务器有证书和对应的私钥。服务器可以验证公钥和私钥是否属于一起。如何做到这一点取决于密钥类型，但其要点是，如果您知道私钥，则可以从中完全重建公钥。服务器将验证私钥的“公共部分”是否与证书的公钥匹配。

服务器会将证书呈现给客户端，就像浏览器一样。浏览器会检查很多东西，但至少会检查两件重要的事情：

1. 浏览器能否建立一个链回信任库中的证书。因此浏览器将查看证书的签署者，称为颁发者，并检查颁发者是否在它的信任库中。如果是，则证书是可信的。如果没有，它将查看该证书是否具有颁发者，并沿着链一直循环直到到达链的末端，或者当它在信任存储中找到某些东西时。如果它到达最后，那么证书不是由它信任的任何人颁发的。

2. 证书对该域有效。证书包含一个主题备用名称 (SAN)，它指示证书对哪些域有效。

还有很多其他的东西需要检查，比如过期、撤销、证书透明度、证书的“强度”——太多了，无法一一列举。

客户端如何确定我的公共证书是由受信任的 CA 签署的。

每个客户端都有自己的信任库。 Windows 上的 Internet Explorer 使用 Windows 信任存储，macOS 上的 Google Chrome 和 Windows 使用操作系统信任存储（钥匙串、Windows 信任存储等）。

浏览器/客户端需要建立信任路径，如上所述。它是如何做到的有点复杂，但它适用于 Authority Key ID 属性 - 如果它存在，以及证书的 Issuer 属性。它使用这些值来查找颁发它的证书。

一旦找到颁发证书，它就会使用颁发者的证书公钥检查证书上的签名。

该颁发证书可以在“根”信任存储中，并使用颁发证书中的公钥来验证签名证书。

您的网络服务器可能（可能）发送中间证书以及“主”（叶）证书。客户端可能会使用这些中间体来构建返回根信任存储中的证书的路径。中间体只能用作中间体 - 您不能发送额外的证书说“这是根证书，相信它”。

客户能否仅通过一个受信任 CA 的 x509 证书列表来检查我的 x509 证书是否有效？

是的。那是信任库。每个浏览器都有/使用一个。 Firefox 有自己的信任库，称为 NSS。操作系统通常也有自己的信任库。