关于数字证书的一些令人困惑的事情
数字证书是证明特定用户拥有某个公钥的数字文档。因此，如果您信任签署证书 C 的 CA，那么您就可以信任该特定公钥/私钥对由证书 C 所有者拥有。
a) 假设客户端 A 想要与位于 url www.some_domain.com 的服务器 B 建立连接。当与B建立连接时，A可以从另一端接收属于所有者的X.509证书C和公钥证书C。
但是客户端如何知道C的所有者实际上是服务器B，而不是劫持（如果这是正确的术语）连接并发送自己的证书的其他实体和 A 的公钥？
我能想到的让客户端知道 C 的所有者是否真的是 B 的唯一方法是 C 的主题 字段是否也指定了其域该证书有效或者它指定了该证书所属的组织（但只有当客户端知道 www.some_domain.com 属于哪个组织时才有帮助）？！
谢谢
A digital certificate is a digital document that certifies that a certain public key is owned by a particular user. Thus if you trust the CA that signed the certificate C, then you can trust that specific public/private key pair is owned by the owner of certificate C.
a) Assume client A wants to establish a connection with server B located at url www.some_domain.com. When establishing a connection with B, A may receive from the other end a X.509 certificate C and a public key, belonging to the owner of certificate C.
But how can client know that owner of C is really a server B and not some other entity that hijacked ( if that is the correct term ) the connection and sent its own certificate and public key to A?
Only way I can think of for client to know whether owner of C is really B, is if C's Subject field also specifies the domain for which this certificate is valid or if it specifies the organization to which this certificate belongs ( but that only helps if client knows to which organization www.some_domain.com belongs )?!
thank you
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
证书所能做的就是确保 A 和 C 之间的通信被加密，以便 C（或安装了证书的任何设备）是唯一能够解密它的人。
它绝对没有代表 C 的所有者。一些证书颁发机构会在颁发证书之前尝试确定给定实体就是他们所说的实体。然而，坦率地说，所有这些都可能被欺骗，并且大多数网站无论如何都不会为这种级别的研究付费（称为扩展验证）。
现在，如果某个骗子从服务器 C 窃取了证书并设置了自己的服务器（具有相同的完全限定域名），那么他们就可以冒充。然而，这需要一个额外的步骤来毒害 DNS 解析，以便对 www.some_domain.com 的请求发送到黑客的服务器而不是原始服务器。通常，破解原始服务器并安装您自己的数据捕获软件会更容易。
附带说明一下，有巨大 安全 DNS 解析问题。
另请注意，最近 stuxnet 蠕虫使用被盗的代码签名证书来绕过某些 Windows 安装保护。
All a certificate can do is ensure that the communications between A and C are encrypted such that C (or whatever has the certificate installed) is the only one able to decrypt it.
It makes absolutely no representation with regards to who C is owned by. Some Certificate Authorities will try and establish that a given entity is who they say they are prior to disbursing a certificate. However, quite frankly, all of that can be duped and most sites don't bother paying for that level of research anyway (called Extended Validation).
Now, if some crook has stolen the certificate from server C and set up their own server (with the same fully qualified domain name), then yes they can impersonate away. However, this would require an additional step of poisoning DNS resolution so that requests to www.some_domain.com go to the hacker's server and not the original. It's usually much easier just to crack the original server and install your own data capture software.
As a side note there are huge security issues with DNS resolution.
Another note, recently the stuxnet worm used a stolen code signing certificate to get past some of the windows installation protections.
因为“C”是由系统上已有的 CA 证书颁发机构签名的。这就是为什么控制 CA 的政府可以破坏该计划的原因。
如果您在浏览器中查看证书，则可以看到是谁签署的。例如，gmail 是由 Thawte 签名的，而 Thawte 是由 Verisign 签名的。
CN字段标记为www.google.com，因此它仅对该域有效。也许你正在谈论中间的人：
http://en.wikipedia.org/wiki/Man-in-the-middle_attack
因此，在您的情况下，只有一侧会被愚弄。请查看下面的步骤 2：
https://ssl.trustwave.com/support /support-how-ssl-works.php
第 2 步：xyz.com 将其公钥发送回客户。一旦客户收到它，他/她的浏览器就会决定是否可以继续。
第 3 步：如果客户决定信任该证书，那么客户将被发送到 xyz.com 他的/她的公钥。
-第 4 步：接下来，xyz.com 将创建一个唯一的哈希值，并使用客户的公钥和 xyz.com 的私钥对其进行加密，然后将其发送回客户端。
Because 'C' is signed by a CA certificate authority that is already on your system. That is why the scheme can be broken by governments that control the CA's.
If you look at a certificate in your browser then you can see who signed it. For instance gmail is signed by Thawte which is signed by Verisign. The
CNfield is markedwww.google.comso it will only be valid for that domain.Maybe you are talking about man in the middle:
http://en.wikipedia.org/wiki/Man-in-the-middle_attack
So in your scenario only one side would be fooled. Check out step 2 below:
https://ssl.trustwave.com/support/support-how-ssl-works.php
Step 2: xyz.com sends back its public key to the customer. Once customer receives it, his/her browser decides if it is alright to proceed.
Step 3: If the customer decides to trust the certificate, then the customer will be sent to xyz.com his/her public key.
-Step 4: xyz.com will next create a unique hash and encrypt it using both the customer's public key and xyz.com's private key, and send this back to the client.
A 通常配置有一组受信任的 CA，这些 CA 将 C 的公钥映射到受信任的实体，在本例中为 B。您在第一段中没有回答自己的问题，还是我遗漏了什么？
A is typically configured with a set of trusted CAs, which map C's public key to trusted entities, in this case B. Did you not answer your own question in the first paragraph, or am I missing something?
所以客户端A需要知道证书C是否是真实的。谁的任务是验证这一点？
答：A的浏览器。
它将如何验证？
答：浏览器检查谁签署了证书。
谁签署了证书？
答：一个名为 AweCerts.Inc 的 CA（证书颁发机构）
浏览器是否知道这个CA。浏览器信任CA吗？
答：是的。如果浏览器不信任，则 A 无法继续进行。浏览器不仅信任 AweCerts，还信任她/他的朋友（即整个链条）。
浏览器如何知道该证书是由 AweCerts.Inc 签署的？
答：浏览器与 AweCerts 达成协议。 Microsoft 在 IE 的情况中就是这样做的。
如果浏览器能够使用 AweCerts 公钥解锁消息（外壳），则可以确定它是“使用 AweCerts 私钥加密”或由 Awecerts 签名的。
我们通常用公钥加密，用私钥解密。但反过来也是可能的，这实际上就是我们所说的数字签名。您可以查看我的博客，了解有关证书和消息传递的更多有趣信息。
这里有一个有趣的博客http： //the-blueclouds.blogspot.nl/2011/11/public-key-private-key-hashing-blah.html
So the client A needs to know if certificate C is genuine. Whose task is to verify this?
Ans: A's browser.
How will it verify?
Ans: Browser checks who signed the certificate.
Who signed the certificate?
Ans: A C.A(Certification Authority) named AweCerts.Inc
Does the browser know this CA. And does the broswer trust CA?
Ans: Yes. If the broswer does not trust then A cannot proceed further. And not only does the broswer trust AweCerts but her/his friends as well (the whole chain that is).
How does the browser know this certificate was signed by AweCerts.Inc?
Ans: Browser had an agreement with AweCerts. Microsoft does this in IE's case.
If the browser is able to unlock the message(outer covering) with AweCerts public key then it is sure that it was 'encrypted with AweCerts private key' or signed by Awecerts.
We usually encrypt with public keys and have it decrypted with private keys. But the other way around is possible as well and that is infact what we call Digital Signature. And you can check my blog for more interesting info on certificates and messaging.
There is an interesting blog here http://the-blueclouds.blogspot.nl/2011/11/public-key-private-key-hashing-blah.html