ROOT CA 如何验证签名? [英] How does a ROOT CA verify a signature?

问题描述

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

Say when using https, browser makes a request to the server and server returns its certificate including public key and the CA signature.

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

At this point, browser will ask its CA to verify if the given public key really belongs to the server or not?

这个验证是如何通过浏览器上的 Root 证书完成的?

How is this verification done by the Root cert on the browser?

举个例子:假设 serverX 从 CArootCA"获得了证书.浏览器在本地存储了 rootCA 的副本.当浏览器 ping serverX 并用它的公钥+签名进行回复时.现在根 CA 将使用其私钥解密签名并确保它确实是 serverX?

To give an example: Say serverX obtained a certificate from CA "rootCA". Browser has a copy of rootCA locally stored. When the browser pings serverX and it replies with its public key+signature. Now the root CA will use its private key to decrypt the signature and make sure it is really serverX?

它是如何工作的?

推荐答案

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

Your server creates a key pair, consisting of a private and a public key. The server never gives out the private key, of course, but everyone may obtain a copy of the public key. The public key is embedded within a certificate container format (X.509). This container consists of meta information related to the wrapped key, e.g. the IP address or domain name of a server, the owner of that server, an e-mail contact address, when the key was created, how long it is valid, for which purposes it may be used for, and many other possible values.

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

The whole container is signed by a trusted certificate authority (= CA). The CA also has a private/public key pair. You give them your certificate, they verify that the information in the container are correct (e.g. is the contact information correct, does that certificate really belong to that server) and finally sign it with their private key. The public key of the CA needs to be installed on the user system. Most well known CA certificates are included already in the default installation of your favorite OS or browser.

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

When now a user connects to your server, your server uses the private key to sign some random data, packs that signed data together with its certificate (= public key + meta information) and sends everything to the client. What can the client do with that information?

首先，它可以使用刚刚发送的证书中的公钥来验证签名数据.由于只有私钥的所有者才能以公钥可以正确验证签名的方式对数据进行正确签名，因此知道谁签署了这条数据，这个人也拥有私钥收到公钥.

First of all, it can use the public key within the certificate it just got sent to verify the signed data. Since only the owner of the private key is able to sign the data correctly in such a way that the public key can correctly verify the signature, it will know that whoever signed this piece of data, this person is also owning the private key to the received public key.

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

But what stops a hacker from intercepting the packet, replacing the signed data with data he signed himself using a different certificate and also replace the certificate with his own one? The answer is simply nothing.

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

That's why after the signed data has been verified (or before it is verified) the client verifies that the received certificate has a valid CA signature. Using the already installed public CA key, it verifies that the received public key has been signed by a known and hopefully trusted CA. A certificate that is not signed is not trusted by default. The user has to explicitly trust that certificate in his browser.

最后它会检查证书本身中的信息.IP 地址或域名是否真的与客户端当前正在与之通信的服务器的 IP 地址或域名匹配?如果没有，有些事情是可疑的！

Finally it checks the information within the certificate itself. Does the IP address or domain name really match the IP address or domain name of the server the client is currently talking to? If not, something is fishy!

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

People may wonder: What stops a hacker from just creating his own key pair and just putting your domain name or IP address into his certificate and then have it signed by a CA? Easy answer: If he does that, no CA will sign his certificate. To get a CA signature, you must prove that you are really the owner of this IP address or domain name. The hacker is not the owner, thus he cannot prove that and thus he won't get a signature.

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

But what if the hacker registers his own domain, creates a certificate for that, and have that signed by a CA? This works, he will get it CA signed, it's his domain after all. However, he cannot use it for hacking your connection. If he uses this certificate, the browser will immediately see that the signed public key is for domain example.net, but it is currently talking to example.com, not the same domain, thus something is wrong again.

这篇关于ROOT CA 如何验证签名?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！