...更改证书中的公钥并将其发送给客户端。数字签名是一样的，除了公钥之外的所有属性都是一样的。那么浏览器如何理解差异呢？

浏览器检查证书的签名是否符合证书。由于公钥包含在签名中并且公钥被更改，签名不再适合证书。因此验证将失败。

在 TLS 协商结束时（“已完成”消息），客户端和服务器获取他们迄今为止进行的整个对话的哈希值，并进行比较。如果它不同 - 就像有人对证书执行 MitM 攻击一样 - 然后连接被丢弃。

引用RFC 5246：

  The Finished message is the first one protected with the just
  negotiated algorithms, keys, and secrets.  Recipients of Finished
  messages MUST verify that the contents are correct.  Once a side
  has sent its Finished message and received and validated the
  Finished message from its peer, it may begin to send and receive
  application data over the connection.

为了解决@Moo 和@Damon 的评论，Finished 消息不会阻止完整的 MitM（“ SSL 拦截”）攻击，其中 MitM 可以直接拦截和代理所有 TCP，并以目标的名义拥有有效证书。它只防止离散篡改客户端和服务器之间的流 - 正如 OP 所建议的那样。

证书不是孤立存在的。为了值得信赖，证书必须由颁发者签名；这些颁发者称为证书颁发机构。每个浏览器（或操作系统）维护自己的列表，其中包含数百个它已经知道并信任的受信任 CA（称为根 CA）；并且您的雇主或学校可能有自己的私人发行根 CA。如果证书是由客户不知道的任何颁发者签署的，则它是不可信的。

在 TLS 握手到达协议的 Finished 部分之前，服务器在 Server Hello 消息中的证书中发送了它的公钥。客户端负责在获得整个证书后立即对其进行验证。验证包括检查证书的到期日期、其签名以及颁发者的签名及其颁发证书。如果颁发证书不是来自已知的受信任颁发者（客户端在该受信任根 CA 的内部列表中拥有的颁发者），则客户端应拒绝连接。

因此，如果攻击者替换了一个没有由客户端已经信任的授权机构签署的不同证书，它将被拒绝，因为在受信任的 CA 列表中找不到颁发者。如果攻击者试图使用自己的密钥而不发送正确的证书，客户端将使用错误的密钥，并且在 Finished 消息期间无法正常通信。

如果攻击者设法将他们的假根 CA 添加到您系统的可信 CA 列表中，那么是的，攻击者可以执行中间人攻击，并查看您的通信。这通常是由希望检查所有网络流量、运行防病毒扫描、防止恶意软件、防止机密泄露或只是监控其员工的网络冲浪的公司故意进行的。