服务器提供CA列表时，客户端发生TLS 1.0握手问题

Question

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

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

这似乎是不正确的行为。据TLS 1.0 RFC http://tools.ietf.org/html/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：

仅当 服务器请求证书时才会发送此消息。如果没有合适的证书 可用，则客户端应发送不包含证书的证书消息 。

完全清楚。

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

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

也许是最好的解决方案上，但它proobsbly也是最昂贵的。

• 打开服务器上的单独的端口只允许TLS 1.0到专门为这个客户端中使用。

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

• 支持票，对供应商的客户端设备，并希望他们得到它固定或有一个解决方案（怀疑）

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

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

正如我上面所说，我怀疑它会实际解决它。我认为你应该参与供应商的支持渠道。