当服务器提供 CA 列表时，客户端 TLS 1.0 握手失败

Question

我们有一个相对较旧的硬件运行一个客户端应用程序，它需要通过 TLS 1.0 进行 Web 服务调用。

服务器有许多不同的客户端，因此它支持 TLS 1.0、1.1 和 1.2。因此，当服务器发送它的证书时，它也会与一个 CA 列表一起出现。设置服务器以便客户端可以选择提供证书，但这不是必需的。问题是，一旦客户端看到 CA 列表，它就会发回 FIN/ACK（关闭连接）。

这似乎是不正确的行为。根据 TLS 1.0 RFC https://www.rfc-editor.org/rfc/rfc2246#section-7.4.2

请注意，客户可能 如果没有适当的证书，则不发送证书 发送以响应服务器的身份验证请求。

据推测，客户正在查看 CA 的列表，并假设它需要出示证书，但由于没有证书而彻底失败。客户端在没有提供 CA 列表时工作，我们可以通过禁用服务器上的 TLS 1.1 和 1.2 来强制。不幸的是，这在我们的生产环境中不是一个选项。

我的问题是上述结论是否正确；客户端是否应该在没有证书的情况下进行响应而不是关闭连接？

如果是这样，我看到了几个选项：

• 创建客户端证书并安装在每个客户端设备上
• 在服务器上打开一个单独的端口，只允许 TLS 1.0 专门用于此客户端。
• 向供应商提供客户端设备的支持票，希望他们能够修复它或有解决方案（怀疑）

我们倾向于选项 2，因为它是我们实施的最简单的解决方案。如果有人有任何其他方法可以让我们解决问题，将不胜感激。

Answer 1

我的问题是上述结论是否正确；客户端是否应该在没有证书的情况下进行响应而不是关闭连接？

是的。见RFC 2246 #7.4.6 Client Certificate：

此消息仅在以下情况下发送 服务器请求证书。如果没有合适的证书 可用，客户端应发送证书消息 不包含任何证书。

非常清楚。

如果是这样，我看到了几个选项：

• 创建客户端证书并安装在每个客户端设备上

可能是最好的解决方案，但也可能是最昂贵的。

• 在服务器上打开一个单独的端口，只允许 TLS 1.0 专门用于此客户端。

我不明白为什么有必要这样做。服务器应该已经从第一条 ClientHello 消息中知道他的客户端正在使用 TLS 1.0。我怀疑这个选项会改变什么。如果是，则表明服务器有问题。

• 向供应商提供客户端设备的支持票，希望他们能够修复它或有解决方案（怀疑）

我肯定会那样做，不管你做什么。该供应商违反了 RFC 2256，因此发布了一个无用的产品，并且可能不符合其自己的规范（无疑会提到 TLS 1.0）。

我们倾向于选项 2，因为它是我们实施的最简单的解决方案。

正如我上面所说，我怀疑它是否真的能解决它。我认为您应该联系供应商的支持渠道。