There are a few good answers to this one already, but I feel I should add, just for completeness, that the full chain doesn't always need to be presented to the client.

For our example of how this works, here's a certificate chain with FOUR(!) certificates, including the root and end-entity (note I'm not recommending such a design):

[![enter image description here][1]][1]

*As a note you can get this properties page on any windows machine by double-clicking on a .cer format certificate file in file explorer and selecting 'certification path'*

When a client visits the website, there are two ways this chain can be verified. The website can present the website, issuer and policy* certificates to the client directly. Alternatively, some clients can chase up extended properties on the certificates that provide an address to download the next certificate in the chain.

At least for Microsoft certificate clients, this certificate extension is called "Authority Information Access" (AIA), is similarly formatted to the CDP (CRL distribution point) field, and can be used to determine where the next certificate in the chain is located. You can see it on the 'details' tab of the same window that has the certification path, as below:

[![enter image description here][2]][2]

More info on CDP's and AIA's [here][3].

*If the client trusts the root, it should have a copy of the root certificate already - it needs to have been manually added to the list of trusted root authorities! ([this is also why some root CA's are still SHA1 and that's not a problem][4]). HOWEVER, **some** websites will still present the root certificate, because **some** software will expect a full chain including the redundant root. Expect this kind of nonsensicalness often whenever you're dealing with software that interfaces with certificates.


  [1]: https://i.sstatic.net/xRuy2.png
  [2]: https://i.sstatic.net/p56Fb.png
  [3]: https://www.sysadmins.lv/blog-en/designing-crl-distribution-points-and-authority-information-access-locations.aspx
  [4]: https://www.entrust.com/need-sha-2-signed-root-certificates/