How TLS certificate chain is verified

Question

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?

Answer 1

(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 the 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 browsers 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.

Answer 2

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.