ROOT CA 如何验证签名？
假设使用 https 时，浏览器向服务器发出请求，服务器返回其证书，包括公钥和 CA 签名。
此时，浏览器会要求其CA验证给定的公钥是否确实属于服务器？
浏览器上的根证书如何完成此验证？
举个例子： 假设 serverX 从 CA“rootCA”获得了证书。 浏览器在本地存储有 rootCA 的副本。 当浏览器 ping serverX 并回复其公钥+签名时。 现在根CA将使用其私钥来解密签名并确保它确实是serverX？
是这样的吗？
Say when using https, browser makes a request to the server and server returns its certificate including public key and the CA signature.
At this point, browser will ask its CA to verify if the given public key really belongs to the server or not?
How is this verification done by the Root cert on the browser?
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?
is it how it works?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
您的服务器创建一个密钥对，由私钥和公钥组成。 当然，服务器永远不会给出私钥，但每个人都可以获得公钥的副本。 公钥嵌入在证书容器格式 (X.509) 中。 该容器包含与包装密钥相关的元信息，例如服务器的 IP 地址或域名、该服务器的所有者、电子邮件联系地址、密钥创建时间、有效期限、有效期。它可能用于的目的，以及许多其他可能的值。
整个容器由受信任的证书颁发机构 (= CA) 签名。 CA 还有一个私钥/公钥对。 你给他们你的证书，他们验证容器中的信息是否正确（例如，联系信息是否正确，该证书是否确实属于该服务器），最后用他们的私钥对其进行签名。 用户系统上需要安装CA的公钥。 最知名的 CA 证书已包含在您喜爱的操作系统或浏览器的默认安装中。
现在，当用户连接到您的服务器时，您的服务器使用私钥对一些随机数据进行签名，将签名的数据与其证书（=公钥+元信息）打包在一起，并将所有内容发送到客户端。 客户可以用这些信息做什么？
首先，它可以使用刚刚发送的证书中的公钥来验证签名的数据。 由于只有私钥的所有者才能正确地对数据进行签名，公钥才能正确验证签名，因此它会知道无论谁签署了这条数据，这个人也拥有该数据的私钥。收到公钥。
但是，什么可以阻止黑客拦截数据包，用他自己使用不同证书签名的数据替换签名的数据，并用他自己的证书替换该证书呢？ 答案就是什么都没有。
这就是为什么在验证签名数据之后（或在验证之前）客户端会验证收到的证书是否具有有效的 CA 签名。 使用已安装的公钥 CA 密钥，它会验证收到的公钥是否已由已知且值得信赖的 CA 签名。 默认情况下，未签名的证书不受信任。 用户必须在浏览器中明确信任该证书。
最后它检查证书本身内的信息。 IP 地址或域名是否与客户端当前正在通信的服务器的 IP 地址或域名真正匹配？ 如果没有，那就有些可疑了！
人们可能会想：是什么阻止黑客创建自己的密钥对并将您的域名或 IP 地址放入他的证书中，然后由 CA 签名？ 简单回答：如果他这样做，没有 CA 会签署他的证书。 要获得CA签名，您必须证明您确实是该IP地址或域名的所有者。 黑客不是所有者，因此他无法证明这一点，因此他不会获得签名。
但是，如果黑客注册自己的域，为其创建证书，并由 CA 签名怎么办？ 这可行，他将获得 CA 签名，毕竟这是他的域名。 但是，他不能用它来侵入您的连接。 如果他使用这个证书，浏览器会立即看到签名的公钥是针对域 example.net 的，但它当前正在与 example.com 通信，而不是同一个域，因此又出现了问题。
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.
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.
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.
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!
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.
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.
服务器证书是使用 CA 的私钥进行签名的。 浏览器使用CA的公钥来验证签名。 浏览器和 CA 之间没有直接通信。
重要的一点是浏览器附带了公共 CA 密钥。 因此浏览器事先知道它可以信任的所有 CA。
如果您不明白这一点，请查阅非对称加密和数字签名的基础知识。
The server certificate is signed with the private key of the CA. The browser uses the public key of the CA to verify the signature. There is no direct communication between browser and CA.
The important point is that the browser ships with the public CA key. So the browser knows beforehand all CAs it can trust.
If you don't understand this, look up the basics of Asymmetric Cryptography and Digital Signatures.
证书基于使用 RSA 等非对称加密。 您有两个密钥，通常称为私钥和公钥。 使用私钥加密的内容只能使用公钥解密。 （实际上，反之亦然。）
您可以将证书视为护照或驾驶执照：它是一种凭证，上面写着“这就是我；您可以信任它，因为它是由某人（例如威瑞信）您信任。” 这是通过“签名”完成的，可以使用证书颁发机构的公钥来计算该“签名”。 如果数据是CA原始获取的数据，则可以验证证书。
该证书包含有关证书所有者的识别信息。 当您收到证书时，您可以使用从受信任的机构获得的密钥组合来确认您收到的证书是有效的，因此您可以推断您信任颁发该证书的人。
Certs are based on using an asymmetric encryption like RSA. You have two keys, conventionally called the private and public keys. Something you encrypt with the private key can only be decrypted using the public key. (And, actually, vice versa.)
You can think of the cert as being like a passport or drivers license: it's a credential that says "this is who I am; you can trust it because it was given to me by someone (like Verisign) you trust." This is done with a "signature", which can be computed using the certificate authority's public key. If the data is what the CA got originally, you can verify the cert.
The cert contains identifying information about the owner of the cert. When you receive it, you use the combination of the key you know from your trusted authority to confirm that the certificate you received is valid, and that you can therefore infer you trust the person who issued the cert.
您的浏览器不会要求 CA 进行验证，而是在本地存储根证书的副本，并且它将使用标准加密程序来验证证书是否确实有效。
这就是为什么当您自签名证书时，您的证书无效，即使从技术上讲有一个 CA 需要询问，您当然可以将自签名 CA 复制到您的计算机，从那时起它就会信任您的自签名证书。
CACert.org 也有同样的问题，它具有有效的证书，但由于浏览器的列表中没有其根证书，因此它们的证书会生成警告，直到用户下载根 CA 并将其添加到浏览器中。
Your browser does not ask the CA to verify, instead it has a copy of the root certs locally stored, and it will use standard cryptographic procedure to verify that the cert really is valid.
This is why when you self sign a certificate your certificate is not valid, eventhough there technically is a CA to ask, you could off course copy the self signed CA to your computer and from then on it would trust your self signed certifications.
CACert.org has this same issue, it has valid certificates but since browsers don't have its root certs in their list their certificates generate warnings until the users download the root CA's and add them to their browser.