您引用的消息的意思是：“我想与一个名为的服务器交谈talk.google.com，但那里的响应似乎使用了一个包含名称的证书gmail.com，而不是 talk.google.com”。这意味着以下任何一个都是正确的：

• 一些不怀好意的第三方正在积极地将您的连接重定向到错误的服务器，可能是由于 DNS 中毒；
• 您的 ISP 发生的一些事故意味着 DNS 配置错误，它模拟了 DNS 中毒的影响，将您的连接尝试重定向到错误的服务器；
• Google 不知道如何做 SSL；
• 您的 Pidgin 配置中有问题。

从这里连接到端口 443talk.google.com会生成包含名称的服务器证书：subject=/C=US/ST=California/L=Mountain View/O=Google Inc./CN=talk.google.com，这是正确的。

请注意，众所周知，Google 会玩弄 DNS。在我的家用机器上，talk.google.com解析为 的别名talk.l.google.com，其 IP 为 74.125.113.125。来自另一个大陆的另一台机器，talk.google.com被解析为 的别名talk.l.google.com，这次的 IP 为 209.85.147.125。这里显然有某种全球负载平衡在起作用。

底线：你不能“自己”检查证书是否好坏，也许可以通过打电话给谷歌总部并让他们拼出证书指纹（他们可能会同意；有传言说他们重视这种幽默） ）。实际上，您收到的消息非常明确地表明您没有获得正确的证书，因此您最好将该消息用作症状并调查您是否确实连接到了正确的服务器。我建议尝试使用Wireshark查看 Pidgin 实际连接的服务器，以及 SSL 级别发生的情况。

如何（以及在​​哪里）检查新的 SSL 证书是否有效？

1. 将证书另存为文件（DER、Base-64 或 PKCS #7）。
2. 阅读颁发者以获取证书。
3. 获取颁发者的证书。
   • 颁发者证书的位置通常由“授权信息访问”字段指定。
4. 如果颁发者的证书不是根 CA，则继续沿链向上，直到您从根 CA 获得所有证书到感兴趣的证书。
5. 从根 CA 签署的证书开始，检查每个证书的有效期和正确的主题命名
6. 阅读 Signature Algorithm 字段以了解所使用的 has 和加密类型。
7. 使用签名证书中的公钥解密签名
8. 使用证书数据的签名算法字段中指定的算法计算哈希值，直到但不包括签名。
9. 将解密的值与计算的哈希值进行比较。如果它们匹配，则签名有效。
10. 继续往下走，直到遇到无效的证书。

如果您让 Pidgin 登录到两个帐户，一个 Google Apps 帐户和一个 Gmail 帐户，那么不用担心，没有证书错误。这只是他们在过去一年中一直忽略的Pidgin 错误。

我只是想我会抛出这个问题的解决方案。如果您打开 gmail 帐户的帐户设置并单击高级选项卡，您可能会看到“连接服务器：”设置为 talk.google.com。我不确定发生了什么（如果这是一个旧的默认值或其他东西），但摆脱它可以解决问题。

从我在 Wireshark 会话中看到的情况来看，我的猜测是它正在连接到 talk.google.com，请求 gmail.com 证书，然后对结果感到困惑（我不确定它是否获得了 gmail 证书和因为它连接到talk.google.com而感到困惑，或者如果谷歌因为您连接到一台服务器并从另一台服务器请求证书而吐出错误的证书）。