How is a certificate chain presented to the client

问题:

How is a certificate chain presented to the client?

I've come to the understanding that root stores only store self-signed certificates ("root" certificates).

Let A>B>...>R be certificates, where A>B means that B signs A's certificate resp. and R is a "root" certificate.

How does a server, with certificate A, present its certificate to a client having R in its root store?

Does the server send the whole chain, A>B>...(not R) to the client? Or does it only send certificate A, such that validation fails, if not the client has B>... stored "somewhere" and R in its root store?

回答1:

To explain things let us look at the future standard, TLS 1.3 as things will be similar in current lower versions.

Section 4.4.2 deals with certificates exchange. It ends with The server's certificate_list MUST always be non-empty. But the text above explains about this structure:

certificate_list

This is a sequence (chain) of CertificateEntry structures, each containing a single certificate and set of extensions.

and later:

The sender's certificate MUST come in the first CertificateEntry in the list. Each following certificate SHOULD directly certify the one immediately preceding it. Because certificate validation requires that trust anchors be distributed independently, a certificate that specifies a trust anchor MAY be omitted from the chain, provided that supported peers are known to possess any omitted certificates.

That directly answers your question: in this case, the server is supposed to send A, B, etc... but can omit R, the root final ceertificate (which I think is frequent).

As for order of certificates in the structure, the document tells us that:

Note: Prior to TLS 1.3, "certificate_list" ordering required each certificate to certify the one immediately preceding it; however, some implementations allowed some flexibility. Servers sometimes send both a current and deprecated intermediate for transitional purposes, and others are simply configured incorrectly, but these cases can nonetheless be validated properly. For maximum compatibility, all implementations SHOULD be prepared to handle potentially extraneous certificates and arbitrary orderings from any TLS version, with the exception of the end-entity certificate which MUST be first.

It is the same for the client, if it needs to send its certificate: it will need to send all the intermediary certificates, if any, to the server, which is normally configured with just a list of (top) CA.