我整天都在看这个错误，现在真的抓耳挠腮。我们有一个运行 .NET web 服务的 Windows Server 2016 Std。这反过来又连接到我们的数据库服务器，相同的操作系统，在同一个庄园，即同一个防火墙后面。我应该首先声明，两台服务器都只启用了 TLS1.2，并且运行 Qualys Labs 测试确认 SSL3 未打开。
似乎发生的情况是，请求正在通过并且遇到了 ssl/tls 问题，如下所示，这是我从应用程序日志文件中检索到的：
请求已中止：无法创建 SSL/TLS 安全通道。
然后在 59-61 秒后，我们收到 SQL 错误：
建立与 SQL Server 的连接时发生与网络相关或特定于实例的错误。未找到或无法访问服务器。
也就是说，这些错误是成对出现的。这种情况似乎已经发生了几个月，但现在我们调查了另一个问题，才发现这一点。
.net 应用程序现在使用正确的数据库服务器主机名，因为之前它使用的名称并不存在，但存在于本地主机文件中，但这并没有解决问题（我认为主机名与我们的通配符证书上的主机名不匹配可能会导致问题）。此应用程序由一些 CRM 开发人员编写，但不幸的是，他们非常不合作。
Windows 事件日志（系统）充满了 Schannel 36874 错误，这些错误似乎与上面提到的错误相关：
从远程客户端应用程序收到 SSL 3.0 连接请求，但服务器不支持客户端应用程序支持的任何密码套件。TLS 连接请求失败。
正如我所说，我真的不知道下一步该怎么做。我看到一些帖子说，事件日志中的这些错误可以被抑制，但前提是它们不会造成问题，然而，在开始这样做之前，我想先弄清楚事情的真相。
我已经在相关服务器上安装了 Wireshark，并过滤了 443 流量，但我不确定如何查询 Wireshark 的日志，或者这是否可行。
任何帮助都将不胜感激。我想我真的需要找出事件日志中的“远程客户端”是谁/什么，有人能指点一下吗？
非常感谢
答案1
这似乎是客户端在握手之前请求的服务器 CIPHER 套件的问题。您能否向我们提供有关客户端如何建立连接的更多信息？如果您可以访问命令行 SSL 客户端，您可以自行启动握手并尝试触发错误。
我建议确保应用程序开发人员标准化握手以使用 TLS 1.2 获得最兼容的设置，如果您可以控制密码套件服务器端，则使用 TLS 1.3。