30

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?

epsilon8
  • 425
  • 1
  • 4
  • 8

5 Answers5

33

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.

Polynomial
  • 132,208
  • 43
  • 298
  • 379
  • 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
  • 2
    when you cross sign, there should be two different certificates right? See https://letsencrypt.org/certificates/. Also see the answer by @compcert below. – Khanna111 May 09 '17 at 23:54
  • 5
    This answer could be better worded. You don't have "a cert signed by both", you have two certs, one from each CA. – Ben Aveling Feb 21 '20 at 08:04
  • One more use case: your intermediate expires in three years but your root expires in 12 months. Create a new root, sign the intermediate, and include both intermediate certs (old and new) in your cert chains. This gives your clients time to trust the new CA. – GLRoman Sep 02 '21 at 00:04
  • 3
    @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 Jan 30 '22 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. – Ben Aveling Jan 31 '22 at 11:49
11

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!

compcert
  • 611
  • 8
  • 16
  • 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: http://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: https://letsencrypt.org/certificates/. – Khanna111 May 09 '17 at 23:50
  • https://scotthelme.co.uk/cross-signing-alternate-trust-paths-how-they-work/ is also instructive. – mti2935 Jan 06 '22 at 14:19
1

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

Myke B
  • 11
  • 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. – Ben Aveling Feb 21 '20 at 08:02
1

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.

Coderer
  • 141
  • 2
0

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.

mti2935
  • 19,868
  • 2
  • 45
  • 64