从理论上讲，X.509 链的长度是无限的。该基本约束扩展可以应用于每个链限制; 这主要用于同意颁发子 CA 证书但希望限制该子 CA 仅颁发最终实体证书的 CA。

实现可能有限制。事实上，通过一些精心制作的证书，可以让路径构建应用程序探索n！深度为n 的潜在路径，并且由于阶乘上升得非常快，这可能导致巨大的拒绝服务攻击。相应地，实现倾向于施加相对较低的最大长度（我知道我在自己的实现中使用了“8”）。

从广义上讲，信任在授权时会迅速稀释。当 CA 向子 CA 颁发证书时，它不仅断言子 CA 公钥由该子 CA 拥有，而且还授权它代表父 CA 执行这种验证。当 CA 为终端实体颁发证书时，它会检查其身份；当它向子 CA 颁发证书时，它还需要确保子 CA 不会上当受骗。对于第三级，CA 必须确保子 CA 不会上当受骗，并且不会将证书颁发给上当受骗的子子 CA。

因此，本能反应是尽量保持链条短而不是长。

警惕“单点故障”的表述。它通常适用于操作连续性。在这里，我们谈论的是安全性：单个流氓 CA 会损害安全性，无论您创建多少其他路径。这在某种程度上与 SPOF 规则相反：您通过添加冗余来避免 SPOF，但在认证的情况下，任何涉及的 CA本质上都能够妥协——您添加的 CA 越多，您就越容易受到攻击.

证书链的长度没有技术/规范限制。（但是，有X509v3属性可以对 CA 的证书链的长度施加基于策略的限制；请参阅pathLenConstraint基本约束字段，RFC 5280，第 4.2.1.9 节。）

对于更长的链，验证客户端需要执行更多的验证工作，构建、遍历和验证该链中的每个证书，每次验证，每次。但这不一定是坏事。但是，它确实增加了在某个时间点，链中的一个证书将过期或被撤销的可能性。许多证书链的构造使得从例如叶证书（服务器/客户端）到受信任的根 CA只有一条路径；如果该路径在此过程中的任何地方失效，则该叶证书将不被视为受信任。

CA 有多种方法可以进行交叉认证，表明两个 CA 相互信任（在RFC 5280，第 3.2 节中讨论）。我不确定这种机制的使用有多普遍/广泛。它允许某种形式的委托，但它仍然是非常分层和集中管理的，而不是完全去中心化的。

希望这可以帮助！