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?

  • 1
    "Wrong certificates, but the browser did it anyway" is a good example of how the word "trust" is used so totally wrong with certificates :-)
    – Damon
    Commented Aug 1, 2014 at 10:00
  • example of this situation: incomplete-chain.badssl.com. Browsers are happy, but everything else complains (curl, openssl, standard libraries, etc)
    – math2001
    Commented Dec 7, 2020 at 1:47

2 Answers 2


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.

  • AIA would be my guess, as the local cert store on the client was missing the correct chain. This setup also works outside of an LDAP/AD environment. Makes sense now. And once I put the correct certs on the server and in the clients local cert store the non-browser based client then validated the cert. Thanks for the excellent explanation :)
    – user53029
    Commented Jul 31, 2014 at 20:09

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.

  • Does this browser cache work outside of the local cert store or are they one in the same? Do they only cache intermediates or can they also cache root certs?
    – user53029
    Commented Jul 31, 2014 at 20:14
  • Only the built-in or specifically imported root-certs are used as trust-anchors (but more can be dynamically loaded with windows update). I don't know where the cached certficates are stored, it might be depend on the browser. It looks like there are stored in Firefox in the trust store as "Software Security Device". Commented Jul 31, 2014 at 20:25

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .