数字证书是证明某个公钥由特定用户拥有的数字文档。因此，如果您信任签署证书的 CA C，那么您可以信任特定的公钥/私钥对由证书的所有者拥有C。
a) 假设客户端想要与位于 url www.some_domain.comA的服务器建立连接。B在与 建立连接时B，A可能会从另一端收到一个 X.509 证书C和一个属于证书所有者的公钥C。
但是客户端如何知道它的所有者C实际上是一个服务器B，而不是劫持（如果这是正确的术语）连接并将其自己的证书和公钥发送到的其他实体A？
我能想到的唯一方法是让客户知道所有者C是否真的B是，如果C's Subject字段还指定了该证书对其有效的域，或者它是否指定了该证书所属的组织（但这只有在客户知道哪个组织 www.some_domain.com 属于）？！
谢谢你
证书所能做的就是确保 A 和 C 之间的通信被加密，以便 C（或任何安装了证书的东西）是唯一能够解密它的人。
它绝对不代表谁拥有 C。一些证书颁发机构会在发放证书之前尝试确定给定的实体就是他们所说的那个人。然而，坦率地说，所有这些都可能被欺骗，并且大多数网站无论如何都不会为这种级别的研究付费（称为扩展验证）。
现在，如果某些骗子从服务器 C 窃取了证书并设置了自己的服务器（使用相同的完全限定域名），那么是的，他们可以冒充。但是，这将需要额外的步骤来毒化 DNS 解析，以便对 www.some_domain.com 的请求转到黑客的服务器而不是原始服务器。破解原始服务器并安装自己的数据捕获软件通常要容易得多。
另请注意，最近stuxnet蠕虫使用被盗的代码签名证书来绕过一些 Windows 安装保护。
因为“C”是由您系统上已经存在的 CA 证书颁发机构签名的。这就是为什么控制 CA 的政府可以打破该计划的原因。
如果您在浏览器中查看证书，那么您可以看到谁签署了它。例如 gmail 由 Thawte 签名，而 Thawte 由 Verisign 签名。该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 的私钥对其进行加密，并将其发送回客户端。
A 通常配置有一组受信任的 CA，将 C 的公钥映射到受信任的实体，在本例中为 B。您在第一段中没有回答您自己的问题，还是我遗漏了什么？
所以客户端 A 需要知道证书 C 是否真实。谁的任务是验证这一点？答：A的浏览器。它将如何验证？答：浏览器检查谁签署了证书。谁签署了证书？Ans: 一个名为 AweCerts.Inc 的 CA（认证机构）浏览器是否知道这个 CA。浏览器是否信任 CA？答：是的。如果浏览器不信任，则 A 无法继续进行。不仅浏览器信任 AweCerts，还信任她/他的朋友（即整个链）。浏览器如何知道该证书是由 AweCerts.Inc 签署的？Ans: Browser 与 AweCerts 有协议。微软在IE 的案例中就是这样做的。
如果浏览器能够使用 AweCerts 公钥解锁消息（外壳），则可以确定它是“使用 AweCerts 私钥加密”或由 Awecerts 签名的。
我们通常用公钥加密，用私钥解密。但反过来也是可能的，这就是我们所说的数字签名。您可以查看我的博客以获取有关证书和消息传递的更多有趣信息。
这里有一个有趣的博客http://the-blueclouds.blogspot.nl/2011/11/public-key-private-key-hashing-blah.html