How are browsers able to find and construct an alternate trusted chain path?

Question

We had a web server that had the wrong SSL certs installed yet the browser was able to find another trusted path to a root and supply the page properly over HTTPS. We also have proprietary software clients that use SSL outside of browsers that connect to the same server yet these failed SSL validation. My question is what is the mechanism in browser logic that allows it to find alternate paths to a trusted root?

Answer 1

In SSL/TLS the server is supposed to show its certificate as part of a chain. Theoretically, the server should make sure that the sent chain is correct, and the client is "morally entitled" to reject the connection if the exact chain sent by the server fails to validate. However, clients are allowed to make extra efforts; if they can validate the certificate with another chain, then it is OK to continue.

Therefore, one cannot formally blame some clients for failing to validate the server's certificate if the server sends a flawed chain.

When a client tries to build an alternate chain, it will use some or all of the following methods:

• The client may have locally installed intermediate CA certificates (in Windows system, the "intermediate CA" store is meant for that).
• The certificates sent by the server may be reused (but maybe not in the same order).
• The client may have access to some LDAP server or equivalent in which some certificates may be looked up by subject name (this may happen in Windows / Active Directory setups). The initial plan for X.509 was that there should be a worldwide Directory, like some sort of generalized DNS, but it never happened.
• The client may try to download other intermediate CA certificates by following the URL found in the Authority Information Access extensions of the certificates.

This last method is what will usually work. A well-issued certificate will contain an AIA extension with an URL pointing to the certificate for the CA which issued it. That certificate may itself contain an AIA extension pointing to the upper-level CA, and so on, up to the root. As long as all URL are publicly accessible, network is up and running, and no sysadmin got into his pathetic excuse for a mind to block that mechanism (I have seen it done, unfortunately), then the chain will be successfully rebuilt. Modern Windows systems do that automatically.

But remember that SSL clients are allowed not to behave that way. An important point to notice is that URL-following relies on HTTP. A Web browser knows HTTP; that's kind of a core feature of a browser. However, a stand-alone application that uses some SSL library may not be as able to issue random HTTP request, or even simply willing to do so. Some SSL libraries provide the protocol support but rely on the caller to actually provide network connectivity (the caller opens and operates the TCP connection, the library being purely on the computational side of things). Depending on how the application is designed and its SSL implementation, you may or may not succeed at pushing the extra certificates where necessary.

It is much better if the server is properly installed in the first place.

Answer 2

Browser usually cache intermediate certificates which they've seen once. This can be tested if you use firefox against a server which missing a common intermediate certificate. If the browser has seen this missing certificate already it will allow the connection. But, if you use a fresh firefox profile and retry it will complain, because the certificate caching is done per profile.

In my opinion this is a bad behavior because the it causes an unreliable behavior of the browser. It is very common for admins not to realize that there HTTPS setup is broken when tests with their browser don't complain because they have the missing intermediate certificate cached.