openssl certificate chain output

Question

I was reading the "Security with HTTPS and SSL" guide for android developers and reading this paragraph.

The paragraph discusses the fact that servers do not always return the entire certificate chain during an SSL handshake, hey often return only the server certificate and the root CA of the chain. The chain are showed using openssl like: openssl s_client -connect egov.uscis.gov:443

This gave me some doubts:

• The paragraph states that browsers, in order to manage this server configuration, simply cache intermediate CAs when visiting sites which are in servers giving a complete certificate chain and when they visit another site which is in a server giving only the "leaf" and "root" certificates they use the cached intermediate CA's certificates to follow the chain. But what happens if a browser visits a site which is in a server returning only the server and the "roots" certificates at a time in which the browser haven't still cached certificates of the intermediate CA's? An authentication error would be triggered?

• How exactly does a browser follow the entire certification chain if it only receives the server and the root CA certificate? As far as I know the process is something like a recursive function which looks at the certificate signature, decrypt it, and checks if the result of the decryption coincides with the certificate of the current step. But, if only the server and the root CA certificates are gave, the process must stop with an error at the second passage, since (if more than one CA is involved in the certificate chain) the server certificate wasn't signed directly by the root CA...

I think I'm misunderstanding something in PKI verification procedure... Could you please clarify it to me and make me understand where I'm wrong?

------ EDIT

Thank you for the good answers, so you're telling me that when the article I linked states "it is not uncommon to configure a server to not include the necessary intermediate CA." it refers to the intermediate CA's certificates NOT INCLUDING the root CA right?

Answer 1

... often return only the server certificate and the root CA of the chain

While it is a common error to return only the server certificate sites usually not return the root CA (and this is also not claimed by the article you reference). In fact, any root CA will be ignored by the client since only the root CA local to the client should be used as a trust anchor and not some root CA send by the peer. See SSL Certificate framework 101: How does the browser actually verify the validity of a given server certificate? for more information.

... But what happens if a browser visits a site which is in a server returning only the server and the "roots" certificates at a time in which the browser haven't still cached certificates of the intermediate CA's? An authentication error would be triggered?

This depends. Some browsers will fail to validate the certificate. Others try harder, i.e. use Authority Information Access to find the missing intermediate CA. See AIA Fetching: Solving a Common SSL Misconfiguration for more information.

How exactly does a browser follow the entire certification chain if it only receives the server and the root CA certificate?

Again, the browser does not use a root CA send by the server at all but only uses locally trusted root CA. If the browser has no knowledge of the intermediate certificates and cannot find these with the described methods the certificate validation will fail.

Answer 2

There are three types of certificate involved in a standard TLS handshake:

• The server certificate for the server being accessed, transmitted by the server. This will have details of the domain(s) it is valid for, its expiry, etc. It will be signed by some Certificate Authority, who has their own signing certificate.
• One or more trusted root certificates, also known as "trust anchors", which are held by the browser (or whatever client you're connecting with). These represent third parties which are trusted to sign individual certificates.
• Zero or more intermediate certificates, transmitted by the server. These allow the browser to construct a "chain" of signatures if there is no direct link between the server certificate and a trust anchor.

In the simplest case, the server's certificate has been signed directly by one of the trust anchors held by the browser; the browser can verify that signature, and immediately trust the certificate.

However, if you are a new or small Certificate Authority, your signing certificate won't be directly trusted by browsers, so none of the certificates you issue will be either. To fix this, you get your signing certificate counter-signed by other Certificate Authorities. The browser needs to see proof that you've done this, in the form of an "intermediate certificate" transmitted by the server.

For example:

• You visit https://some-store.example.com using MyAwesomeBrowser
• It sends an SSL certificate signed by Cheapo Certificates PLC
• MyAwesomeBrowser looks at the certificate, and examines who it was signed by; it then looks in its trust store for a matching trust anchor - note that the server doesn't send the root certificate, or explicitly name it; it's deduced from the signing information in the server certificate itself
• MyAwesomeBrowser doesn't have Cheapo Certificates PLC in its trust store, so by default, the certificate - and therefore the website - won't be trusted

To fix this:

• Cheapo Certificates PLC gets Fancy Enterprise Security Corp to counter-sign their root certificate, producing an intermediate certificate
• The owner of some-store.example.com configures their server to send this intermediate certificate as well as their server certificate; if they don't do this, there's no guarantee that the browser will ever discover this intermediate certificate
• MyAwesomeBrowser checks that the server certificate matches the intermediate certificate, and then proceeds to verify the intermediate certificate is trusted
• MyAwesomeBrowser has a trusted root certificate for Fancy Enterprise Security Corp, so is able to verify the chain, and trusts the site

The caching described in the article you link, or the auto-discovery mentioned by Steffen Ullrich, effectively increase the pool of trust anchors the browser can use: if the browser has already received and verified the Cheapo Certificates PLC intermediate certificate, it can use it to trust other things in future. Just as the original root certificate wasn't transmitted by the well-configured server, the browser can work out when to use this cached/discovered intermediate based on the certificate it's presented with.