首先得明确几个关键的TLS规范细节和客户端库实现差异，这能解释你观察到的现象：

为什么服务器会随证书发送CA证书？ #

TLS握手时，服务器发送的不是孤立的服务器证书，而是完整的证书链（从终端服务器证书向上追溯到根CA），这是TLS规范的默认行为，核心原因有两点：

• 虽然你已经在客户端信任存储里预置了CA，但规范并不假设客户端一定能从本地存储中精准匹配到服务器证书的签发者（比如存在配置错误、存储里有多个同名CA等情况）。发送完整链能让客户端直接通过链完成证书路径验证，无需在本地存储中遍历查找，既提升了验证效率，也避免了因本地存储问题导致的验证失败。
• 即使客户端信任存储配置完全正确，发送完整链也能规避一些边缘场景的验证风险，比如CA证书存在多个版本、客户端存储中的CA与服务器使用的CA在扩展字段上有细微差异等。

为什么部分客户端会发送CA证书？ #

你提到Python和Node.js客户端会发送所持有的CA证书，本质上是这些客户端库的实现默认会发送完整的客户端证书链（客户端证书 + 签发它的CA证书）。而Java PAHO客户端只发送终端客户端证书，这是不同语言TLS栈的实现差异：

• Python（比如paho-mqtt）和Node.js的TLS栈在双向认证场景下，默认会将客户端证书的完整链发送给服务器，这样服务器不需要在本地信任存储中查找客户端证书的签发者，直接通过收到的链就能完成验证。
• Java的TLS实现（以及PAHO客户端基于它的封装）则更偏向最小化发送原则，只发送终端客户端证书，完全依赖服务器信任存储中已预置的CA来验证客户端证书的有效性。

关于握手成功/失败的差异 #

你观察到的两种场景差异，核心在于客户端和服务器对证书链的依赖程度不同：

• Java客户端场景：Java的TLS验证逻辑要求服务器提供完整的证书链（或者客户端能通过本地存储自动构建完整链，但如果服务器不发送CA，Java的实现可能无法自动从本地存储中匹配到对应的CA完成路径验证），因此服务器不发CA证书时握手直接失败。
• Python/Node.js客户端场景：这些客户端的TLS栈兼容性更强，即使服务器不发送CA证书，它们可以自动从本地信任存储中查找匹配的CA来验证服务器证书；同时它们发送完整客户端链，服务器也能顺利完成客户端证书的验证，因此握手可以成功完成。

总结一下：CA证书预置在信任存储是双向TLS验证的基础，但握手阶段交换证书链是为了提升验证的可靠性和兼容性，不同客户端库的实现逻辑差异则导致了行为上的不同。

内容的提问来源于stack exchange，提问作者Nowa Concordia