请不要将 TLS 协商与集市混淆，因为各方会协商并重新协商，直到他们找到一些共同的解决方案。由于每条消息都需要时间来传递，这太慢了。因此，客户只有一个报价，其中包括客户愿意支持的所有密码，按照客户首选的顺序。如果服务器支持这些密码中的任何一个，它将根据服务器或客户端的偏好选择最好的。如果没有重叠，则协商永久失败。

在您的情况下，服务器接受以下密码（由此工具确定）：

ECDHE-RSA-AES256-SHA384
ECDHE-RSA-AES128-SHA256
ECDHE-RSA-AES256-SHA
ECDHE-RSA-AES128-SHA
AES256-SHA256
AES128-SHA256
AES256-SHA
AES128-SHA
DES-CBC3-SHA

由于您只提供一个密码 DHE-RSA-AES256-SHA 并且服务器不支持此密码，因此协商失败。

是的，TLS 应该严格限制它支持的密码套件。如果不仔细选择密码套件，您可能会面临与可能受到损害的不安全密码套件进行协商的风险。如果另一方不支持符合您标准的密码套件，并且您高度重视该连接的安全性，则不应允许您的系统使用质量较低的密码套件运行。

但是，明智的 TLS 实现也支持多个密码套件，以增加与其他方兼容的机会。尽管最近在各种密码套件中发现了许多弱点，但仍有一些被认为是安全的。只要您只控制对话的一方，将您的系统限制为仅支持一个密码套件，然后期望整个互联网按照您的个人标准运行，那将是荒谬的。

这里发生的情况是您选择仅支持一个密码套件，而另一个系统选择不支持该密码套件。（只有另一个系统的所有者才能说出原因，但我猜它可能与Logjam 有关。）但是，另一个系统可能确实支持其他几个密码套件，它们与您选择的一个。（看起来@SteffenUllrich 有这个列表。）选择一个你觉得舒服的，然后配置你的系统以允许它。

或者只是不使用 TLS 进行该连接。

或者根本不与该服务器交谈。

你的选择。