我正在尝试了解交叉签名（中间）证书的实际机制。例如，我正在查看Let's Encrypt Chain of Trust。该页面提到：
IdenTrust 已经交叉签署了我们的中间体。这允许我们的最终证书被所有主要浏览器接受，同时我们传播我们自己的根。
此外，该页面包含指向使用属于他们自己的 ISRG 根 CA 的私钥签名的中间证书的链接，以及使用属于 IdenTrust 的 CA 的私钥交叉签名的中间证书的链接。
我的期望是在与 www.letsencrypt.org 建立 TLS 连接时，看到这两个中间证书通过网络传输，让客户端决定使用两个中间证书中的哪一个来构建信任链。但是，我只看到 IdenTrust 签署的中间文件。
我使用wireshark 观察到了这一点，在我使用Web 浏览器浏览www.letsencrypt.org 时分析了TLS 流量。为了强制“另一个”信任链，我不信任 Keychain Access 应用程序中的 DST Root CA X3 证书（我在 Mac 上），实际上我不再能够浏览该站点。然后我添加了 ISRG Root X1 证书，表示始终信任它，但我仍然无法浏览该站点。这支持了我的观察，即服务器永远不会提供由 ISRG 签名的中间证书。
我也尝试了该openssl s_client应用程序，但无济于事。
假设我碰巧信任 ISRG Root 而不是 IdenTrust，如何让服务器与我共享由 ISRG Root 签名的中间证书？或者更普遍地问，如果有多个信任链可用，例如由于交叉签名，两条链的证书如何与客户端共享？为什么我没有收到包含两个中间证书的捆绑包？
更新：第一个答案指出 TLS 规范不允许交换多个证书链。这解释了很多。
但是，我的期望是由对 X.509 中交叉签名证书的用途是什么问题的答案设定的？. 那里接受的答案提到：“这是关于扩大信任”和“增加信任验证的便利性，例如您有信任 CA1 或 CA2（但不是两者）的客户的情况。在这种情况下，您可以跨-签署一份双方都信任的证书。”。
如果只允许交换一条链，那么这似乎不是“扩大信任”，而更像是“修改信任”。此外，对于一个特定的服务器，如果它必须选择一个特定的链，那么“易于验证”的论点也不再成立——至少如果你唯一可用的机制是 TLS 握手的话。那是对的吗？