ROOT CA 如何验证签名？

Posted 2023-03-08

【中文标题】ROOT CA 如何验证签名？

【英文标题】：How does a ROOT CA verify a signature?

【发布时间】：2010-10-10 00:44:40

【问题描述】：

假设使用 https 时，浏览器向服务器发出请求，服务器返回其证书，包括公钥和 CA 签名。

此时，浏览器会要求其 CA 验证给定的公钥是否真的属于服务器？

浏览器上的根证书是如何进行验证的？

举个例子： 假设 serverX 从 CA“rootCA”获得证书。浏览器在本地存储了 rootCA 的副本。当浏览器 ping serverX 并使用其公钥+签名进行回复时。现在根 CA 将使用它的私钥来解密签名并确保它真的是 serverX？

它是如何工作的？

【问题讨论】：

相关论文：The Security Impact of HTTPS Interception

【参考方案1】：

您的服务器创建一个密钥对，由一个私钥和一个公钥组成。当然，服务器从不提供私钥，但每个人都可以获得公钥的副本。公钥嵌入在证书容器格式 (X.509) 中。此容器包含与包装密钥相关的元信息，例如服务器的 IP 地址或域名、该服务器的所有者、电子邮件联系地址、密钥的创建时间、有效期、用途以及许多其他可能的值。

整个容器由受信任的证书颁发机构 (= CA) 签名。 CA 也有一个私钥/公钥对。你给他们你的证书，他们验证容器中的信息是否正确（例如，联系信息是否正确，该证书是否真的属于该服务器），最后用他们的私钥对其进行签名。 CA 的公钥需要安装在用户系统上。大多数知名 CA 证书已包含在您喜欢的操作系统或浏览器的默认安装中。

当用户现在连接到您的服务器时，您的服务器使用私钥对一些随机数据进行签名，将签名数据与其证书（= 公钥 + 元信息）打包在一起，并将所有内容发送给客户端。客户可以用这些信息做什么？

首先，它可以使用刚刚发送的证书中的公钥来验证签名数据。由于只有私钥的所有者才能正确签署数据，公钥才能正确验证签名，所以它会知道无论是谁签署了这条数据，这个人也拥有该数据的私钥。收到公钥。

但是是什么阻止了黑客拦截数据包，用他自己使用不同证书签名的数据替换签名数据，并用他自己的证书替换证书？答案很简单。

这就是为什么在验证签名数据之后（或在验证之前），客户端会验证接收到的证书是否具有有效的 CA 签名。使用已安装的公共 CA 密钥，它验证收到的公共密钥是否已由已知且希望受信任的 CA 签名。默认情况下，未签名的证书不受信任。用户必须在其浏览器中明确信任该证书。

最后，它会检查证书本身的信息。 IP 地址或域名是否真的与客户端当前正在与之通信的服务器的 IP 地址或域名匹配？如果没有，那就有问题了！

人们可能想知道：是什么阻止了黑客仅仅创建自己的密钥对并将您的域名或 IP 地址放入他的证书中，然后由 CA 签名？简单的回答：如果他这样做，没有 CA 会签署他的证书。要获得 CA 签名，您必须证明您确实是该 IP 地址或域名的所有者。黑客不是所有者，因此他无法证明这一点，因此他不会得到签名。

但是，如果黑客注册了自己的域，为此创建了一个证书，并由 CA 签名，该怎么办？这行得通，他会得到 CA 签名，毕竟这是他的域。但是，他不能使用它来入侵您的连接。如果他使用这个证书，浏览器会立即看到签名的公钥是针对域 example.net 的，但它当前正在与 example.com 通信，而不是同一个域，因此又出现了问题。

【讨论】：

好答案！但我还有另一个相关问题... 引用：“大多数知名 CA 已包含在您最喜欢的操作系统或浏览器的默认安装中。”我想知道浏览器如何扩展默认的已知 CA？它会自动检查网络服务吗？或者它只会在下一个版本的浏览器版本中这样做？

CA 证书与浏览器或操作系统一起提供。 Firefox、Chrome、Opera 包含自己的 CA 证书副本，Internet Explorer 和 Safari 使用安装在 Windows 或 OS X 中的 CA 证书。没有什么能阻止浏览器同时使用自己的副本和操作系统范围的证书（我提到的一些证书甚至可以那）。您只能通过更新浏览器、更新操作系统或手动安装它们（下载然后将它们添加到浏览器或您的操作系统，两者都是可能的）来获得新的 CA 证书。

浏览器唯一的在线检查（如果可以的话）是 CA 证书是否仍然有效。每个 CA 服务都运行一个证书撤销服务器，浏览器可以在其中询问某个证书是否仍然有效或已被撤销；这是通过 OCSP 协议完成的：tinyurl.com/pcjk2 Certs 包含要询问的 OCSP 服务器的地址。

如果有人，所谓的黑客，在更新期间发送他的假 CA 证书，会发生什么情况，这是一种假更新。更新也安全吗？

那么“IP 欺骗”呢？

【参考方案2】：

服务器证书使用 CA 的私钥签名。浏览器使用 CA 的公钥来验证签名。浏览器和 CA 之间没有直接的通信。

重要的一点是浏览器附带公共 CA 密钥。所以浏览器事先知道它可以信任的所有 CA。

如果您不明白这一点，请查阅非对称加密和数字签名的基础知识。

【讨论】：

假设这个内容是正确的：这是我见过的技术主管最好的总结（想想那些已经熟悉公私钥并且不关心不必要细节的有经验的 CTO） ，在阅读/看过许多臃肿的基于文本和动画的描述之后。简短、简洁、全面，直指重点。非常感谢。

"浏览器使用 CA 的公钥来验证签名。"这是我无法理解的一点。它是怎么做到的？

@waxingsatirical - 我是这样理解的：1）public keys are used to verify private-key signatures（请注意，未编码的证书和所述证书的签名都是必需的，并且由 TLS/SSL 服务器在命令 TLS/SSL 客户端进行此验证），以及 2）#1 中的上述过程被利用到verify TLS/SSL certificates。

【参考方案3】：

证书基于使用 RSA 等非对称加密。您有两个密钥，通常称为私钥和公钥。您使用私钥加密的东西只能使用公钥解密。 （实际上，反之亦然。）

您可以将证书视为护照或驾驶执照：它是一种证明“这就是我；您可以信任它，因为它是由您信任的人（例如威瑞信）提供给我的。”这是通过“签名”完成的，可以使用证书颁发机构的公钥来计算。如果数据是 CA 最初获得的数据，您可以验证证书。

证书包含有关证书所有者的识别信息。当您收到它时，您使用您从受信任的机构知道的密钥组合来确认您收到的证书是有效的，因此您可以推断您信任颁发证书的人。

【讨论】：

服务器的签名应该很容易获得：只需向它发送一个 https 请求。如果 serverY 以这种方式获得 serverX 的签名怎么办 - 它不能冒充 serverX 吗？

不，当您的浏览器连接时，它使用唯一的开始（diffie hellman 密钥交换），除非 ServerY 拥有您的证书的私钥，该私钥用于根据浏览器发送给您的内容计算公钥，它无法模拟 serverX。

Sesh，它在特定条件下可以做的就是所谓的“interposer”或“man in the middle”攻击。这让它可以播放客户端到服务器，服务器到客户端，并拦截所有内容。对此有保护措施。谷歌“中间人”和 SSL 了解详情。

【参考方案4】：

您的浏览器不要求 CA 进行验证，而是在本地存储了根证书的副本，并且它将使用标准加密程序来验证证书是否确实有效。

这就是为什么当您自签名证书时，您的证书无效，即使从技术上讲需要 CA，您当然可以将自签名 CA 复制到您的计算机上，从那时起它就会信任您的自签名证书.

CACert.org 也有同样的问题，它有有效的证书，但由于浏览器的列表中没有根证书，因此它们的证书会生成警告，直到用户下载根 CA 并将它们添加到浏览器中。

【讨论】：

我不清楚。假设 serverX 从 CA rootCA 获得了证书。浏览器在本地存储了 rootCA 证书。因此，当浏览器 ping serverX 时，它会使用其公钥+签名进行回复。根 CA 将使用其私钥解密签名并确保它确实是 serverX？

不，它检查它的签名，我可以用我的私钥签署一些东西来验证我的公钥。所以本地存储的根CA实际上是CA的公共部分。因此，如果远程服务器发送一个证书，它将具有一定的签名，那么该签名可以是

针对 CA 的公共部分进行数学计算，以验证 CA 的私有部分是否实际签署了证书。