2

Let's say I want to validate an entity that presents an X509v3 certificate, "Leaf". Leaf is a cert signed by SigningCA. SigningCA's cert, "SigningCert", was signed by RootCA. RootCA's cert, "RootCert" is in my system's trust store.

  • I pull Leaf and see that it is signed by SigningCA. Specifically, the linkage is that in the "Authority Information Access" section of Leaf, 'CA Issuers' contains a URL that I can follow to pull down SigningCA's cert, SigningCert. So I go and pull that down and do validation. All is good.

  • But now I want to check that SigningCA is legit. It has it's own CA Issuers field pointing me to the cert of RootCA, RootCert.

Now my question: to validate, do I need to pull this URL, or is it sufficient that RootCert is in my trust store and has some property that allows for quick comparison against what I have already?

It seems (from some experimentation with browsers) that pulling the RootCert is not required, which makes me think that they are comparing some field in SigningCert to something present in all the certs in the trust store and reporting success if a match is found. If so, what is that thing?

AlwaysLearning
  • 123
  • 2

2 Answers2

2

It seems (from some experimentation with browsers) that pulling the RootCert is not required

The idea is that you ultimately (i.e. root) trust only a CA already known to be good (i.e. in the local trust store) and not just blindly trust any arbitrary CA certificate downloaded from the internet. Thus, pulling the root certificate from the internet is not only "not required" but it would be the wrong thing to do.

The process of determining which root CA is the correct one is essentially the same as with an intermediate CA certificate: make sure issuer CN and Authority Key Identifier (if exists) match and validate the signature. The important difference compared to an intermediate CA is that the root CA will be used as the ultimate trust anchor and therefore must be trusted already - which is not the case for something blindly downloaded from somewhere or given by the (not yet trusted) communication peer.

For more details on how certificate validation is done see SSL Certificate framework 101: How does the browser actually verify the validity of a given server certificate?.

Steffen Ullrich
  • 184,332
  • 29
  • 363
  • 424
  • OK, that makes sense, thankyou. So then we get to the root of my question which is how to know what cert in the store to go and look at. And (per @CBHacking's answer) that would appear to be by searching for root CA certs that match on Issuer or else those whose Subject Key Identifier matches the Authority Key Identifier in the intermediate CA cert. Do you agree? – AlwaysLearning Oct 17 '18 at 04:48
  • @AlwaysLearning: To find which root CA certificate is the correct one is the same process as finding out which intermediate CA certificate is the correct one: check issuer CN and Authority Key Identifier for a match and make sure the signature is valid. But the important difference is that the root CA will be the ultimate trust anchor and therefore must be trusted already - which is not the case for something blindly downloaded from somewhere or given by the communication peer. – Steffen Ullrich Oct 17 '18 at 04:53
1

You are correct that the root CA's certificate, already being present in the client's trust store, does not need to be retrieved from an external location. There are a few ways that a client could look up a CA cert in their trust store.

  • Common name (CN): the "Issuer" field of the cert gives the CN of the signer. While CNs don't have to be unique, in practice you should not have duplicate CNs in your trust store, so checking your trusted certificates for one(s) with that CN, and seeing if its public key verifies the cert in question, is still fast enough to be practical. For X.509v1 certs, this is the most practical approach.
  • Authority Key Identifier: This is an extension field that presents an identifier for the signing key (I believe it's most often simply a hash of the signer's public key bits). Again, duplicates are technically possible (multiple certs could share a key pair, though it means each cert holder could impersonate the other; the odds of this happening for independently-generated certs is astronomically low) but should not occur. In practice you can look up the signing cert of a v3 cert by searching for a cert with a Subject Key Identifier matching the to-be-validated cert's Authority Key Identifier.
Community
  • 1
CBHacking
  • 40,303
  • 3
  • 74
  • 98