我知道 TLS（通常但被错误地称为 SSL）拦截通过在客户端和服务器之间建立两个加密隧道来工作，拦截设备（代理）在中间终止两个隧道。但是，为了混淆正在发生的拦截，必须将客户端的机器配置为接受代理的证书作为受信任的，这样用户就不会收到无法建立身份的弹出消息。这在公司环境中很容易做到，在这种环境中，客户端机器加入了一个域，该域可以悄悄地在用户的根目录中推出证书。
现在，当您通过 TLS 访问网站时，您可以在浏览器中查看该网站的证书。如果中间有拦截代理，那么查看浏览器中站点的证书会不会发生变化？换句话说，虽然代理不能复制服务器的证书来建立到客户端的 TLS 隧道（因为它需要服务器的私钥，而它没有），但它仍然可以直观地输出服务器的证书吗？给用户，让他们不知道，只是通过查看证书，拦截正在发生？因此，例如，您处于拦截所有 TLS 连接的公司环境中，并且该组织的代理证书安装在所有客户端上。如果您通过 TLS 连接到您的银行帐户，则不会弹出窗口，
换句话说，检查安全站点的证书是否足以检测到中间人，或者您是否必须查看公司笔记本电脑上所有受信任的证书以确定其中是否有任何异常（即公司的）？
发送给客户端的证书将是由代理生成的证书，而不是由原始服务器生成的证书。它无法发送终端服务器的证书，因为该证书特定于终端服务器使用的密钥。如果它更改了发送给客户端的密钥并且没有更改证书，则验证将失败，因为计算出的公钥哈希与证书中的哈希不匹配，从而使其无效。
浏览器或 TLS 客户端应显示拦截代理正在使用的任何 CA 的信任路径，无论是默认安装（如果您是一家足够大的公司，实际上有用于此类 MITM 设置的中间证书出售！）或已安装由组织通过政策/管理。
正如sneaker所指出的，客户端将收到代理生成的证书，而不是原始站点证书。原因是代理不能仅凭其证书模拟站点，它必须具有相应的private key。
该证书是 TLS *设置的一个组成部分（即它不是“站点印章”或类似的废话）。它的内容（公钥）被客户端用来加密连接，只有匹配的私钥才能解密才能成功完成连接。代理只能出示其确实拥有密钥的类似证书，这将具有（以非常高的概率）不同的指纹或散列。
[ *协商 TLS 时有很多选项，身份验证和加密的两个主要功能有“空”选项，尽管这些通常不用于 HTTPS。如果您使用空身份验证方法，则不需要证书，例如 ADH]
这种 TLS 拦截的一般方法是代理将生成（在运行中，然后缓存）与目标的 DNS 名称匹配的密钥和证书，证书将由伪 CA 签名，存储在代理，它将被您的操作系统/浏览器“信任”。
信任是这样工作的（稍微简化一下）：
代理能够成功的原因是您的浏览器“信任”公司伪 CA，通常是通过桌面策略、自定义浏览器部署或类似的方式。信任模型的问题很明显：传统上，任何 CA 都可以为任何名称签署证书（通常也可以通过从属 CA 进行委托）。对此有一些缓解措施，包括 DANE、CAA 和 key-pinning。
在合法证书和代理生成的证书之间发生变化的最小字段集是公钥模数和证书签名。如果存在，则 SKID 和 AKID 字段（从相关密钥派生）也将有所不同。验证相关字段（OCSP、CRL）也可能会被剥离，尽管在技术上也可以为伪 CA 提供这些服务。
实际上，虽然生成的证书可能只是表面上类似于真实证书（足以通过日期和 DNS 名称测试），并且由您公司代理的伪 CA 直接签名。然而，完全有可能重现看起来合法的CA 层次结构，获取真实证书，复制证书链的所有其他细节（除了模数和密钥派生的 AKID/SKID 和签名）。一旦证书的任何细节发生变化，计算出的指纹（摘要）也将（很有可能）发生变化。
（对于混淆指数/模数的更正，感谢 dave_thompson_085 注意到这一点。）
总而言之，任何代理生成的证书：
如果您检查它，浏览器中的站点证书是否会更改？
是的，您可能只检查 Issuer 字段或计算的指纹，但您需要验证整个链才能确定。
它是否仍然可以仅将服务器的证书直观地输出给用户，以便他们仅通过查看证书就不会意识到正在发生拦截？
不，HTTPS 服务器（无论是真正的 Web 服务器还是代理）无法控制这一点（用户界面问题、恶意扩展和伪造的位置栏除外）。浏览器显示的是在 TLS 连接设置期间使用的证书，它不是通过 HTTP 获取的文件。
检查安全站点的证书是否足以检测到中间人，或者您是否必须查看公司笔记本电脑上的所有受信任证书以确定其中是否有任何异常？"
仅从证书可能就很明显，生成的证书可能会直接由代理的伪 CA 证书签名，并且可能很容易通过证书中的文本字段（至少是“颁发者”）来识别。为了彻底，您应该比较所有证书指纹或 AKID/SKID 链接。
FWIW，EV 证书在这里为您提供了一点点额外的保护：代理不能伪造真正的 EV 证书，因为任何合格的浏览器都会有一个硬编码的 EV 能力 CA 证书列表。（但它并没有解决先有鸡还是先有蛋的问题：你怎么知道什么时候可以期待或需要 EV 证书？）
IETF的DANE被提议作为更强大的解决方案。它解决了信任模型的根本问题：
TLS 所依赖的公共 CA 模型从根本上是易受攻击的，因为它允许任何这些 CA 为任何域名颁发证书。
为了真正解决问题，而不是把它踢得更远一点，DANE 需要 DNSSEC。还有一个简单的对策：客户端证书，但由于各种原因，这不是一个通用的解决方案。
其他（部分）解决方案包括：
还有其他的，例如Convergence、Verikey [PDF]、CertPatrol（Firefox 插件）、Monkeysphere（多协议）
也可以看看：
根据所使用的密钥交换，通过 RSA 密钥交换，客户端本质上将选择会话密钥（它比这更复杂，但与本讨论无关）并使用服务器公钥（来自证书）对其进行加密。由于代理没有与该证书一起使用的私钥，因此它将无法解密客户端选择的密钥，因此无法在连接上进行通信。
在 DH 密钥交换中，可以完成初始交换，但客户端随后将质询代理以验证其具有与证书关联的私钥，并且代理将无法提供对此质询的响应。
相反，代理必须即时克隆证书详细信息并创建用于该站点的新证书。这样，它就有了对应的私钥，并且可以形成它自己与所需服务器的连接。因为代理在它所服务的系统上具有根信任，所以证书被接受为有效，但如果系统同时在代理上和代理外使用，证书固定可能会由于公钥更改而导致检测到错误。
HTTPS 或 SSL 代理不安全，他们经常使用替代 SSL 证书显示在用户的浏览器上，换句话说，您与 Web 服务器没有真正的 HTTPS 连接，并且您的登录页面和私人数据在代理服务器中打开。只需通过代理和直接模式检查https://google.com证书，您就会发现不同的验证。