这是关于扩大信任，是的。如果您同时信任 CA1 和 CA2，并且两者都签署了证书，那么您将获得非常高的信任度，因为您信任的两个独立实体已经验证了该证书。

它具有增加信任验证的便利性的额外好处，例如您的客户信任 CA1 或 CA2（但不是两者）的情况。在这种情况下，您可以对证书进行交叉签名以得到双方的信任。这允许更多客户端验证信任，而无需为不同的 CA 分发单独的证书。

另一个好处是在 CA 的私钥泄露的情况下。假设 CA1 的密钥泄漏，您的证书由 CA1 和 CA2 签名。在泄漏之后，CA1 对其公钥进行了撤销，您将不再信任 CA1 发布的任何内容。但是，由于您的证书也与 CA2 交叉签名，因此任何信任 CA2 的客户端仍然可以对您的证书保持一定程度的信任。

X.509 规范仅支持一种签名。来自关于他们的 RFC：

   Certificate  ::=  SEQUENCE  {
        tbsCertificate       TBSCertificate,
        signatureAlgorithm   AlgorithmIdentifier,
        signatureValue       BIT STRING  }

要支持多个签名值，您必须执行“位串的签名值序列”之类的操作，并进行一些其他更改。

如果您有一个由多个 CA 签名的 X.509 证书，我很乐意看到它并对其进行一点 asn1parse 操作！

Let's Encrypt 使用的方案不需要在一个证书中包含两个签名。据我了解，它看起来像这样：

This-CA 根

• 中间证书 A（公钥 X，由 CA Root 签名）

其他 CA 根

• 中间证书 A（公钥 X（相同！），由其他 CA Root 签名）

在这种情况下，相同的中间证书 A 有两个实例：一个由您自己的 CA Root 签名，另一个由 Other-CA 签名。它们具有相同的 RSA 密钥，并且所有字段都相同，除了签名（每个中间 CA 实例一个签名）。客户端（如浏览器）使用证书链提供服务，该证书链只有一个中间证书实例，而不是两者，并导致两个根之一。这可能是“交叉签名”的唯一兼容方式。

到期日快乐！

为了纪念这个场合，我想指出交叉签名的一大好处，这是我在其他答案中看不到的：根到期时的连续性。如果您有颁发证书的中间证书的交叉签名版本，则当旧根过期时，操作系统可以（希望但并非总是- 请参阅“客户端实现”）通过构建备用路径继续接受证书通过由较新的根发布的中间体。