与所有密码算法一样，数字签名不能解决问题，它只是移动它们。

注意签名不是加密。如果有人试图将签名解释为一种加密，那就去找他们，用扳手反复敲打他们的牙齿。告诉他们他们不配，我对他们很失望。这种有缺陷的解释不起作用，从来没有起作用，只会传播混乱。

在一个签名系统中，有一个消息m，一个公钥k _p，一个私钥k _s和一个签名s。签名生成算法根据m和k _s计算s。签名验证算法采用m 、 s和k p _，并返回“true”或“false”。当它返回“true”时，这意味着拥有公钥（即知道对应的私钥）的人参与了特定消息m上签名s的生成。.

重点在于密钥所有权：签名验证算法不会告诉您“是的，这是 Bob 签名的”；它只会告诉您“是的，这是由拥有该公钥的人签名的”。只有当您有办法确保您看到的公钥确实是 Bob 的公钥时，这才能保证签名者确实是 Bob。如果 Bob 只是将他的公钥与签名消息一起发送，那么很容易通过简单地说“你好，我是 Bob，这是我的公钥，这是我的签名消息”来冒充 Bob。这根本证明不了。这里的攻击很简单，叫做“说谎”。

虽然签名很有用（实际上，它们将验证多个消息来源的问题减少为将单个公钥与其所有者关联的问题），但它们并不能神奇地凭空保证所有权。这就是证书颁发机构发挥作用的地方。CA 是一个有机体，其工作是确保 Bob 真正拥有他所谓的公钥。据推测，CA 通过亲自会见 Bob 或其他类似机制来做到这一点。当 CA 正式验证 Bob 对其密钥的所有权时，CA 将 Bob 的身份（他的姓名）和他的公钥放入证书中。然后 CA 签署证书。

然后 Alice 的机器可以验证证书上的签名，从而确保证书内容确实来自预期的 CA。此时，Alice 可以保证她在证书中看到的公钥确实是 Bob 的密钥，并且她可以使用它来验证据称由 Bob 计算的签名。

此时你应该说：“但是 Alice 如何验证 CA 对证书的签名？她必须知道 CA 的公钥！” 而且，确实，问题再次转移到 CA 密钥所有权的问题上。我们可以再次使用另一个 CA 移动它。等等。但它必须在某个地方停下来。那个“某处”是根 CA。根 CA 是您绝对知道其公钥的 CA。这就是神奇的部分。实际上，您的计算机配备的操作系统已经包含了大约一百个根 CA 的公钥，这些 CA与 Microsoft达成了一项协议，即所有 Windows 系统都知道（并且信任）他们的公钥。

有点，虽然 CA 不是解决问题的唯一方法。

证书颁发机构通过基本上说“我已经查看了这个公钥和这个实体，并且我声明它们是链接的，并且由于我是一个受信任的实体，你可以相信我”。他们通过使用自己的私钥对密钥进行签名来做到这一点，您可以验证您是否拥有他们的公钥。

这一切都很好，但实际上并不能防止中间人攻击——如果 Bob 没有验证签名，或者 CA 没有真正验证 Alice 拥有密钥，或者 Eve 能够说服 CA她的名字是 Alice，所以她的密钥似乎是有效的，或者如果 Eve 运行一个受信任的 CA，Bob 仍然不知道该消息是由 Alice 签名的。CA 知道这一点，因此，一般来说，他们会努力成为好公民，并实际执行他们声称要做的检查。

那么什么会阻止中间人攻击呢？好吧，如果 Alice 和 Bob 有另一个他们信任的通信渠道（也许他们真的会面，检查彼此的护照，或者以其他方式互相证明他们的身份），然后交换公钥，他们将来可以安全地发送消息，因为Bob 肯定知道他拥有 Alice 的正确公钥，而 Alice 也知道 Bob 的情况。如果 Eve 愿意，她可以尝试交换内容，但如果没有私钥来签署修改后的消息，接收者就会知道有些地方不对劲。在这种情况下，您根本不需要 CA - 您拥有直接信任。