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?


It's about expanding trust, yes. If you trust both CA1 and CA2, and a cert is signed by both, you've got a very high level of trust because two seaparate 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 revokation 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
    Apr 22 '12 at 11:26
  • please check the edit
    – epsilon8
    Apr 22 '12 at 12:15
  • I'm pretty sure (though you'll probably want to dig into the specs to verify this) that there end up being two copies of the hash, each signed by a separate CA.
    – Polynomial
    Apr 22 '12 at 12:54
  • 1
    when you cross sign, there should be two different certificates right? See letsencrypt.org/certificates. Also see the answer by @compcert below.
    – Khanna111
    May 9 '17 at 23:54
  • 2
    This answer could be better worded. You don't have "a cert signed by both", you have two certs, one from each CA. Feb 21 '20 at 8:04

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!

  • 18
    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
    Apr 23 '12 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
    Jul 10 '12 at 15:58
  • 2
    A lucid explanation of Cross Signing is at: letsencrypt.org/certificates.
    – Khanna111
    May 9 '17 at 23:50

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".

  • 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. Feb 21 '20 at 8:02

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.