2

Suppose I have the following trust chain in my trust store:

ROOT_CERT
|
|---INTERMEDIATE_CERT_1
     |
     |---INTERMEDIATE_CERT_2

I know that any certificate that is signed by INTERMEDIATE_CERT_2 will be trusted - but are the following statements also true:

a) Any certificate directly signed by ROOT_CERT is trusted?

b) Any certificate directly signed by INTERMEDIATE_CERT_1 is trusted?

2

Yes to both.

Usually you will only have the root in the trust store and the entity providing the leaf cert will also provide the necessary intermediate certs, and the verifier will build a chain linking the leaf to a trusted root ("the" trusted root if only one root is trusted).

Of course the certs need to have the correct key usage constraints etc. e.g. a certificate only used to sign OCSP responses cannot issue certificates, etc.

1

In short: Yes to both.

Explanation

What follows is a very simplified explanation. More details linked below.

When CAs sign certificates, they do not only sign the public key of a website e.g., but actually a whole lot of metadata. This meta data e.g. includes when the certificate expires or so. In our case, this is saved in a data format defined as X.509.

It also includes certain "constrains", i.e. limits on what the cert can do. The Wikipedia article lists an overview, but what is important for our case is: It also says whether that cert can sign other "(sub)certs" and thus "certify" them or no.

Both the root CA and intermediate CAs/certs have this set. Thus, they are allowed to sign other certs.

A chain of trust

What browsers then do is take the cert delivered by the website (for https://example.com e.g.) and try to build a so-called certificate chain, i.e. "chain" that cert up until it reaches the root cert. You already draw it, but you missed that last cert I've just talked of, which is usually called the leaf certificate. (Likely, because of the tree data structure )

ROOT_CERT (isCA=yes)
|
|---INTERMEDIATE_CERT_1 (isCA=yes)
     |
     |---INTERMEDIATE_CERT_2 (isCA=yes)
         |
         |---LEAD_CERT valid for example.com (isCA=no)

Obviously, the leaf cert must not have the permission to sign other certs.

Practice

In practice this allows many many things you would not think of when we would only have one CA and then the leaf cert that is directly signed by then. E.g. CAs sometimes re-sell their selling infrastructure and allow other companies to sign their own certs with an intermediate certs. (but there are still technical and legal things they have to adhere to, e.g. AFAIK they just offer an API)

Or, as the private keys for root certs are e.g. usually kept in HSMs, for productive use they use an intermediate CA, so they could switch that out if they really gets in trouble (their intermediate CA is compromised).

Or you could even do crazy things such as cross-signing, where one CA signs the root for another CA, so it gets faster acceptance in browser. Let's Encrypt e.g. did this – and also has an interesting and well-documented structure of their intermediate certs, if you want to see a "real world" example.

More details

If you want to read more, I really recommend you to look into:

  • thanks for the very detailed explanation and links :) – user2521119 May 28 at 10:45
  • @user2521119 Thanks, so if you like it, feel free to accept it as an answer and/or upvote it. – rugk May 29 at 19:15

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.