ssl - ROOT CA 如何验证签名？

Question

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

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

浏览器上的 Root 证书如何完成此验证？

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

它是如何工作的？

Answer 1

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

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

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

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

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

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

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

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

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

Answer 2

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

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

如果您不理解这一点，请查看非对称密码学和数字签名的基础知识。

Answer 3

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

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

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

Answer 4

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

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

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