好吧，我已经与我们的网络工程师合作，但似乎没人能解决这个问题，所以我已经别无选择，因为我已经尝试在 Google 上研究这个问题，但毫无结果。话虽如此，以下是问题所在以及已执行的所有故障排除。（注意：所有通信都是通过使用端口 443 上的 https 的网站连接进行的。此外，所有这些连接都是通过外部 effacing URL 进入的，然后进入 Citrix 负载平衡器，该负载平衡器将连接重定向到托管网站服务的适当服务器。该服务器运行的是 Windows Server 2012 R2 和 IIs 8.5。是的，所有绑定都已设置。此外，我确实通过注册表明确启用了 TLS 1.0、1.1 和 1.2，以确保一切正常。）
我有一个来自另一家公司网站的连接，直到最近我们都没有遇到任何问题。最近发生的变化是我们关闭了 TLS 1.0 和 TLS 1.1，只启用了 TLS 1.2。我们一这样做，连接就断了。现在你可能会认为问题是因为另一家公司使用较弱的 TLS 连接来连接我们，但这已被证明是错误的。所以我采取的第一步是让我的网络团队重新打开这两个 TLS 版本，在运行 Wireshark Trace 时，我能够捕获到与我们服务器的成功连接。奇怪的是，连接一直在通过 TLS 1.2 进行通话和通信。所以这是让我感到困惑的第一部分。
因此，我们采取的下一步是禁用 TLS 1.1，并保持 TLS 1.0 和 1.2 处于启用状态。在运行另一个 Wireshark Trace 后，我们确认连接仍然能够建立，并且所有通信仍然通过 TLS 1.2 进行。
我们执行的下一步是关闭 TLS 1.0 并重新启用 TLS 1.1，因为我们知道启用 TLS 1.2 最初会破坏连接。进行这些更改并启动另一个 Wireshark Trace 后，连接失败。
拿到所有这些日志后，我回过头来查看每一条日志，看看这三条日志之间的区别。经过大量的亲自研究，我相信我可能已经找到了问题所在，但我需要帮助来确认。我注意到，在连接失败期间从未发生过的一件事是，服务器级别从未尝试过握手。但是，当连接成功时，服务器级别的握手都按预期执行。所以这让我相信问题出在握手上，并且它在负载均衡器上被终止了。
我将这些信息反馈给我的网络工程团队并与他们进行了交流，他们不确定为什么打开 TLS 1.0 和 1.2 以及可选的 1.1 会允许连接，而 Wireshark 日志显示所有内容都是通过 TLS 1.2 进行通信的。因此，我查看了供应商正在使用的某些密码套件以及已获准用于负载均衡器与我的服务器的连接的密码套件。
在仔细研究了这些之后，我发现每次商定的密码套件都不是负载均衡器列表中批准的密码套件之一。所以说实话，整个情况中最令人困惑的部分是，当 TLS 1.0 启用时，这家公司的连接怎么可能被允许通过，但他们提供的所有支持的密码套件都不在我们批准的列表中。然而，当只启用 TLS 1.2 时，连接永远不会与服务器建立，因为它似乎在负载均衡器上被终止。
话虽如此，有人能解释一下为什么打开 TLS 1.0 后密码套件不在负载均衡器批准列表中却可以工作，而关闭它却不行吗？此外，尝试让连接通过的最佳步骤是什么？我们是否应该将另一家公司支持的最高评级密码套件之一添加到我们的批准列表中，然后看看会发生什么？或者还有其他事情我们应该进一步排除故障并尝试找到解决方案？
感谢所有人的帮助和建议。