When dealing with TLS connections, it is important to understand how a client (in most cases this is a web browser) will be acting. Let's quickly check some of the steps that are happening when a TLS connection is made.

A web server will send its certificate down to the requesting client during the TLS handshake. But it is not only a single certificate but usually a complete chain of certificates.
There is the server certificate , in many cases an intermediate CA certificate and finally a Root CA.
When you check your browser this will look like this:

So the client now needs to verify each of the certificates. It will start with the server certificate and work its way up to the root CA.
This process is described here in this picture. The client will check the certificate (is it revoked, is it expired, is the CN matching the hostname), the issuer of the certificate and will validate it using the public key of the issuer.

Now it is clear that to actually perform this check, all of the certificates needs to be present at the client. So what happens when a server is not "nice" and only send the server certificate? This is usually a configuration mistake at the server's side where the server certificate is put in the web servers configuration but not the intermediate certificate.

Well , hopefully we have the intermediate certificate in our local store, otherwise the client will not be able to continue to validate the complete chain.
But there is something that the client can do to find the missing certificate:
In many certificates there is a field called "Authority Information Access". This field contains things like the OCSP URL to validate the certificate but can also have an entry where to download the signing certificate. Checking your certificate , this should look like this:

If you check the value of the AIA (Authority Information Access) field you will see a URL called "CA Issuers".
So this is the place where we will find our intermediate certificate! Huzzah!
This means, even if the server did not send us his complete chain, we still have a chance now to be able to validate the certificate chain.

This behavior of automatically fetching the missing intermediate certificate is done by browsers but usually not by any other TLS clients such as email clients (IMAPS,SMTPS) or command line utilities such as curl or wget.

This issue is very often also spotted, when you have  https proxies or next gen firewalls that deal with TLS decryption. In that case you only have the chance to manually check for the missing certificate and then import it into your device's certificate store.