Cross-Signing (Cross-certificate)

Cross-signing creates a second certificate for the same CA name and public key, signed by a different CA that clients already trust. Certificates issued with that key then have two possible paths: one to the new CA's own root, and one through the cross-certificate to the older root. A client follows whichever path ends in its trust store.

Why it matters

Getting a new root into every trust store takes years, and old devices may never update. Cross-signing lets a new CA serve those clients immediately. Let's Encrypt is the best-known case: its ISRG Root X1 was cross-signed by IdenTrust's DST Root CA X3. DST Root CA X3 expired on 2021-09-30, Let's Encrypt's default chain stopped using the cross-sign on 2024-02-08, and the cross-signed certificate itself expired on 2024-09-30. Each step broke some outdated clients, which shows that a cross-sign is a bridge, not a permanent fix.

Example

The two paths a Let's Encrypt certificate could take before 2024:

Path A: example.com -> intermediate -> ISRG Root X1 (self-signed, in modern stores)
Path B: example.com -> intermediate -> ISRG Root X1 (cross-signed) -> DST Root CA X3

The leaf and intermediate are identical in both paths; only the last links differ.

Common misconceptions

• A cross-signed certificate uses a different key. It carries the same subject and public key as the original CA certificate, which is exactly why both paths verify.
• Cross-signing means two CAs validated your domain. Only the issuing CA validated it; the cross-signer vouches for the CA, not for your site.
• An old root expiring only affects old devices. When DST Root CA X3 expired, some OpenSSL 1.0.2-based clients failed even on updated systems, because they stopped at the expired path instead of trying the valid one.