数字证书是一种数字文档，用于证明某个公钥由特定用户拥有。因此，如果您信任签署证书C的CA，那么您可以信任特定的公钥/私钥对由证书C的所有者拥有。
a）假设客户A想要与位于www.some_domain.com网址的服务器B建立连接。与B建立连接时，A可能会从另一端收到X.509证书C和属于证书C所有者的公钥。
但客户怎么知道C的所有者确实是服务器B而不是其他一些被劫持的实体（如果这是正确的术语）连接并发送了自己的证书和公钥到A？
我只能想到让客户知道C的所有者是否真的B，if C's Subject字段是否还指定了此证书有效的域名，或者是否指定此证书所属的组织（但只有在客户知道www.some_domain.com属于哪个组织时才有用）？
谢谢
答案 0 :(得分：2)
所有证书都可以确保A和C之间的通信是加密的，这样C（或安装了证书的任何东西）是唯一能够解密它的人。
对于C所拥有者，它绝对没有任何代表。某些证书颁发机构将尝试确定某个特定实体是他们在支付证书之前所说的人。然而，坦率地说，所有这些都可以被欺骗，大多数网站都不打算为这个级别的研究付费（称为扩展验证）。
现在，如果某个骗子从服务器C窃取了证书并设置了自己的服务器（具有相同的完全限定域名），那么他们就可以冒充了。但是，这需要额外的步骤来中毒DNS解析，以便对www.some_domain.com的请求转到黑客的服务器而不是原始服务器。破解原始服务器并安装自己的数据捕获软件通常要容易得多。
作为旁注，huge security issues有DNS解析。
另一个注意事项，最近stuxnet蠕虫使用窃取的代码签名证书来通过一些Windows安装保护。
答案 1 :(得分：1)
因为“C”由系统上已有的CA证书颁发机构签名。这就是为什么该计划可以由控制CA的政府打破。
如果您在浏览器中查看证书，那么您可以看到谁签了它。例如，由Verisign签署的Thawte签署了gmail。 CN字段已标记为www.google.com，因此仅对该域有效。
也许你在谈论中间人： http://en.wikipedia.org/wiki/Man-in-the-middle_attack
只有当攻击者可以模仿每个端点以满足另一个端点时，中间人攻击才能成功 - 这是对相互身份验证的攻击。大多数加密协议都包含某种形式的端点身份验证，专门用于防止MITM攻击。例如，SSL使用相互受信任的证书颁发机构对服务器进行身份验证。
所以在你的场景中，只有一方会被愚弄。请查看下面的第2步：
https://ssl.trustwave.com/support/support-how-ssl-works.php
第2步：xyz.com将其公钥发回给客户。客户收到后，他/她的浏览器会决定是否可以继续。
步骤3：如果客户决定信任证书，则客户将被发送到xyz.com他/她的公钥。 - 第4步：xyz.com接下来将创建一个唯一的哈希，并使用客户的公钥和xyz.com的私钥对其进行加密，并将其发送回客户端。
答案 2 :(得分：1)
A通常配置了一组受信任的CA，它们将C的公钥映射到受信任的实体，在这种情况下为B.您是否在第一段回答了自己的问题，或者我错过了什么？
答案 3 :(得分：0)
因此客户A需要知道证书C是否是真品。谁的任务是验证这个？ Ans：A的浏览器。 它将如何验证？ Ans：浏览器检查谁签署了证书。 谁签了证书？ Ans：一个名为AweCerts.Inc的C.A（证书颁发机构） 浏览器是否知道此CA. broswer是否相信CA？ 答：是的。如果broswer不信任那么A不能继续进行。 broswer不仅信任AweCerts，还信任她/他的朋友（整个链条）。 浏览器如何知道此证书是由AweCerts.Inc签署的？ Ans：浏览器与AweCerts签订了协议。 Microsoft在IE's case中执行此操作 如果浏览器能够使用AweCerts公钥解锁消息（外部覆盖），则可以确定它是“使用AweCerts私钥加密”或由Awecerts签名。
我们通常使用公钥加密并使用私钥解密。但另一种方式也是可能的，这实际上就是我们所说的数字签名。您可以查看我的博客，获取有关证书和消息的更多有趣信息。
这里有一个有趣的博客http://the-blueclouds.blogspot.nl/2011/11/public-key-private-key-hashing-blah.html