In X.509 architecture what are the uses of cross signing certificates from other hierarchy?

Does it just expand trust?

So from the answer I am assuming that if CA3 is cross signed by CA2 (from another hierarchy) and CA1 (a parent in its own hierarchy) whose private key is used to encrypt the authentication hash in the certificate of CA3?

5 Answers 5


It's about expanding trust, yes. If you trust both CA1 and CA2, and a certificate is signed by both, you've got a very high level of trust because two separate entities that you trust have verified the cert.

It has the added bonus of increasing the ease of verification of trust, such as situations where you've got clients that trust CA1 or CA2 (but not both). In such a case, you can cross-sign a cert to be trusted by both. This allows more clients to verify trust without having to distribute separate certs for different CAs.

Another bonus is in situations where a CA's private key is leaked. Let's say CA1's key leaks and your cert is signed by CA1 and CA2. In the wake of the leak, CA1 issues a revocation for its public key and you can no longer trust anything issued by CA1. However, since your cert is cross-signed to CA2 as well, any client that trusts CA2 can still maintain a level of trust in your cert.

  • 8
    I think I said "trust" too much... o.o`
    – Polynomial
    Commented Apr 22, 2012 at 11:26
  • 2
    when you cross sign, there should be two different certificates right? See letsencrypt.org/certificates. Also see the answer by @compcert below.
    – Khanna111
    Commented May 9, 2017 at 23:54
  • 8
    This answer could be better worded. You don't have "a cert signed by both", you have two certs, one from each CA. Commented Feb 21, 2020 at 8:04
  • 4
    @BenAveling I think the answer is kinda wront as stating that "a cert is signed by both" is not a correct sentence, there are as you said two certificats and not only one certificat file signed by both the CAs
    – achabahe
    Commented Jan 30, 2022 at 15:45
  • 1
    "your intermediate expires in three years but your root expires in 12 months." Your intermediate cert should never have an expiry further into the future than the cert it was signed by. Commented Jan 31, 2022 at 11:49

The X.509 specs only support one signature. From the RFC concerning them:

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

To support multiple signatureValue's you'd have to do something like "signatureValue SEQUENCE OF BIT STRING" and make a few other changes too.

If you have an X.509 cert that's been signed by multiple CA's I'd love to see it and do a little asn1parse on it!

  • 19
    You can still have cross signing, where another CA signs your CA certificate with the same public key and the same Subject DN, it will be another cert with a different issuer. See last paragraphs of this section: tools.ietf.org/html/rfc5280#section-3.2
    – Bruno
    Commented Apr 23, 2012 at 16:51
  • 2
    @Bruno I remembered this question when I was at InfoSec earlier this year, and asked around. Amusingly, the Verisign tech guy was completely stumped by this concept. D'oh! Thanks for clarifying how it's done.
    – Polynomial
    Commented Jul 10, 2012 at 15:58
  • 2
    A lucid explanation of Cross Signing is at: letsencrypt.org/certificates.
    – Khanna111
    Commented May 9, 2017 at 23:50
  • scotthelme.co.uk/… is also instructive.
    – mti2935
    Commented Jan 6, 2022 at 14:19

The scheme Let's Encrypt used doesn't require two signatures in a single certificate. As far as I understand it, it looks like this:

This-CA Root

  • Intermediate Cert A (Public Key X, signed by CA Root)

Other-CA Root

  • Intermediate Cert A (Public Key X (same!), signed by Other-CA Root)

In this case there are two instances of the same Intermediate Cert A: one signed by your own CA Root, the other signed by Other-CA. They have the same RSA Key and all the fields equal, except for the signature (one signature per each instance of Intermediate CA). Client (like browser) is served with a certificate chain that has only one instance of Intermediate certificate, not both, and leads to one of two roots. This may be the only compatible way to "cross-sign".

  • 1
    Almost. Client is served both intermediate certificates, and if client trusts either intermediate certificate (because it trusts that certificate's root certificate), then it trusts your certificate. Commented Feb 21, 2020 at 8:02
  • @BenAveling Client is at least not always served both intermediate certificates. E.g. Let's Encrypt provides only one of the intermediates. As such with Let's Encrypt it's usually one intermediate and one path. You can probably make your server send both intermediates, but that's need to be additionally configured, and I wonder how it'll work...
    – x-yuri
    Commented May 14 at 15:06

Happy expiration day!

In honor of the occasion, I'd like to point out a great benefit of cross-signing that I don't see in other answers: continuity when roots expire. If you have cross-signed versions of the intermediate cert that issued your cert, when the old root expired, the OS can (hopefully, but not always -- see "Client Implementation") just go on accepting the cert by constructing an alternate path through the intermediate that was issued by the newer root.


Cross-signing provides multiple ways for clients to create certificate chains to trusted roots. There are several uses for this:

  1. Handling expired certificates. In September 2021, one of Let's Encrypt's root certificates (DST Root CA X3) expired. Even though millions of sites still had leaf certificates that chained-up to this expired root, most modern browsers continued to connect to these sites without a hitch, because Let's Encrypt cross-signed its certificates. This enabled browsers to build a different certificate chain, to a different trusted root (ISRG Root X1).

  2. Providing CA’s with a way to phase-in new root certificates. When a CA issues a new root certificate, it takes a while before the new root certificate makes its way into clients' trust stores. During this interim, the certificate chain served by the server can chain-up to the CA’s new root certificate - but if a client does not yet have the new root certificate installed, it can still chain to an older (more widely distributed) one, by way of a cross-signed certificate.

See What could cause classic "ERR_CERT_DATE_INVALID" when I can confirm no error from numerous other clients? for details on how browsers use cross-signed certificates in both of the above scenarios.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .