5

Assume the verification of a TLS certificate chain. Suppose the chain has certificates A-B-C-D where D is the root certificate and A is signed by B, B by C, C by D.

Suppose the intermediate certificate B is found to be already built into the browser. That is, A is checked, it found to be valid (and signed by B) and B is built into the browser.

(1) Does the verification of the chain end there or does it continue on until we get to D?

(2) When a server presents it's certificate chain to the browser, does it present the root certificate D as well or does in only present A-B-C?

6

(1) Does the verification of the chain end there or does it continue on until we get to D?

it depends on a certificate chaining engine (CCE) implementation. Different platforms have different implementations which may not support all recommended/mandatory validation logic described in RFC5280.

Certificate trust requires an end of chain point which is presented in a self-signed form (we call such certificate as Root CA certificate). Since certificate B is not self-signed (it is signed by C), the A-B-C-D chain is not trusted until C and D are fetched and validated. So, the answer to this question is: the chain continues validation to the root.

If we talk about Microsoft implementation (just an example which I'm familiar with), their CCE builds one or more chains (as much as possible) without performing immediate validation. They just fetch certificates and attempt to perform basic rules to bind each certificate at the correct place in the chain. When all chains are built, each of them are validated according to rules described in RFC5280. Once validated, there might be a case that there are multiple trusted and valid chains. CCE uses its own selection logic to select only one chain from a collection of chains.

When we talk about cetrtificate stores in browsers, they are used to:

  1. establish a trust to a particular trusted root CA (Trusted Root CA store). These certificates MUST be presented in a self-signed form. Otherwise, they cannot be used as chain endpoint and the trust is not established (even though, the intermediate certificate is installed in the root store).
  2. help CCE to quickly build the chain without having to download missing certificates from internet, because they are available locally. Some brwosers completely lack an ability to process Authority Information Access extension, which means that SSL client is able to fetch CA certificates only from two sources: SSL handshake, local certificate store.

(2) When a server presents it's certificate chain to the browser, does it present the root certificate D as well or does in only present A-B-C?

it depends on a web server implementation. A reference from RFC 5246 §7.4.2:

certificate_list This is a sequence (chain) of certificates. The sender's certificate MUST come first in the list. Each following certificate MUST directly certify the one preceding it. Because certificate validation requires that root keys be distributed independently, the self-signed certificate that specifies the root certificate authority MAY be omitted from the chain, under the assumption that the remote end must already possess it in order to validate it in any case.

RFC suggests that root CA certificate MAY or MAY NOT be sent to client. As the result, when developing SSL client you should expect that root certificate may be shipped along the chain. Two major web servers: Apache and IIS by default DO NOT send root certificate during SSL handshake.

  • Since the certificate chain must be parsed up to the very end (i.e., until the root certificate); what is the significance of intermediate certificates being stored in the browser? I thought they are there so the verification of a chain can terminate once an intermediate certificate exists in the browser's trusted store. – Minaj Jul 24 '16 at 8:54
  • I explained the purpose of certificate store in browsers. Read my post again. – Crypt32 Jul 24 '16 at 8:56
  • oh, gotcha. Thanks ! On another note; while you dont say so explicitly, your answer suggests there could (or should?) exist browser implementations which parse the chain until an intermediate certificate which is stored in the browser. I base this comment on your first point ..."it depends on a certificate chaining engine (CCE) implementation. Different platforms have different implementations which may not support all recommended/mandatory validation logic described in RFC5280." – Minaj Jul 24 '16 at 9:06
  • Major industrial web browsers (Microsoft IE/EDGE, FireFox, Safari, Chrome and Opera) conform RFC rules in most important parts (though, neither of them fully conform RFC in regards to revocation checking). However, there might be other browsers that implement their own RFC-noncompliant cert validation logic. – Crypt32 Jul 24 '16 at 9:15
  • Now, for another dumb question -- Does an RFC define standards which are still undergoing vetting (thus up for comments from the public), or does it represent standards that are already being used in protocols, software, etc. I ask this question based on your reference to several RFCs here, e.g., RFC5280. – Minaj Jul 24 '16 at 23:16
-1

1) If the intermediate certificate (B) is trusted - that is, it is a valid signing certificate, not expired, not tampered with, and not revoked - then it being in the trust store is enough that the TLS client doesn't need to continue up the chain in order to verify the leaf certificate.

However, that "not tampered with" thing requires having a trusted certificate have signed the intermediate certificate. Now, the intermediate cert could be self-signed, just like the root certs are, in in addition to being part of a chain up to the root certs. In that case (assuming the signature checks out), there's no need to verify the chain above the intermediate cert.

Some clients may not even bother verifying that the certificate has a valid signature on it (it's in the trust store, so it's trustworthy, in theory) or that it hasn't been revoked (a lot of older browser didn't check for revocation by default, assuming they'd be updated with an updated list of revoked certs no longer being in the trust store instead). In practice, though, you should assume both these things (valid signature even if it's self-signed, and not revoked) are checked by most clients.

2) That depends entirely on the server. It's typical to serve everything except the root cert, but some servers send the entire chain. If you use a site like Qualys SSLLabs, it'll show you the certificates that the server sends. This site appears to send two certs - a wildcard leaf for *.stackexchange.com and a "Server CA" intermediate, but not the root cert (which is a DigiCert EV root CA, and signed the intermediate cert). However, some other sites do send the full chain; SSLLabs will flag it if you do so, but usually it's just kind of wasteful.

  • 1
    Check out this situation: An intermediate certificate such as B is signed by another valid certificate C. However, the certificate D which signs C is invalid. This means, that by checking only up to B, we run a risk of accepting a bad certificate chain. – Minaj Jul 24 '16 at 3:13
  • @Minaj: The scenario doesn't make sense. If certificate C is not signed by a trusted (or has-a-valid-chain-to-a-trusted) certificate, then C is not valid. If C is not valid, then it cannot grant validity to B. Now, if C (or B) is self-signed and in the trust store, then you don't need to go any further up the chain; C (or B) is acting as its own certificate authority, you trust it to do so, and it doesn't matter if it is validly cross-signed by other CAs or not. – CBHacking Jul 25 '16 at 5:28
  • Say we have a shorter chain A-B-C and B is in the trust store. How could the browser know B has not been just revoked by C without building the whole chain and checking C's CRL/OCSP? Afterall, the certificiate policies in the root certificate should be honored. – billc.cn Jul 29 '16 at 12:51

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.