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):
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:
More info on CDP's and AIA's here.
So in this example, here's how the client verification works for a scenario where the whole chain isn't presented up front:
- A client visits website.com over https and is presented the 'Website' certificate.
- The client verifies this is not a trusted root and is not self-signed. Finding an AIA for the 'Issuer' certificate, it downloads this certificate and verifies the public key of this certificate signed the 'Website' certificate.
- The client verifies that the 'Issuer' certificate is not a trusted root and is not self-signed. Finding an AIA for the 'Policy' certificate, it downloads this certificate and verifies the public key of this certificate signed the 'Issuer' certificate.
- The client verifies that the 'Policy' certificate is not a trusted root and is not self-signed. However, it finds that the issuer of this certificate is one of the trusted roots and verifies the public key of the root certificate signed the 'Policy' certificate.
For each certificate in the chain, CDP's are checked for Certificate Revocation Lists (CRL's), to ensure there are no revocations.
If the client at any point had found a trusted certificate, the 'Website' certificate has been verified as issued by a trusted root and non-revoked. Other checks (like validity period) may still result in the certificate being invalid.
If at any point the client found a self-signed, non-trusted certificate, the 'Website' certificate has not been verified as issued by a trusted root. Normally the client will pop up a warning at this point.
Yes, this means you could potentially have a trusted certificate that was not self-signed, but it's not a common scenario.
*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). 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.