Wikipedia says: For example, if a certificate issued to "example.com" and issued by "Intermediate CA1", and the visiting web browser trusts "Root CA", trust may be established in the following manner:

Certificate 1 - Issued To: example.com; Issued By: Intermediate CA 1

Certificate 2 - Issued To: Intermediate CA 1; Issued By: Intermediate CA 2

Certificate 3 - Issued To: Intermediate CA 2; Issued By: Intermediate CA 3

Certificate 4 - Issued To: Intermediate CA 3; Issued By: Root CA

What is meant by trust here?Can my browser trust an intermediate certificate so that the certificate chaining stops there and my brower can start a session with server?

2 Answers 2


What is meant by trust here?

"Trust" is a slightly ambiguous term in Security because different software will enforce different definitions / strength levels of trust. And when we start talking about the human factor of security, the definition changes again (ie "is that certificate trustworthy?" is very different from "is that admin trustworthy?").

With certificates, "trust" typically means

Can I trace the chain of signatures back to a trust anchor in which I have absolute faith?

Now, what is meant by "trust anchor"? The currently accepted practice is the idea of certificate pinning, where copies of trusted certificates are embedded in either an Operating System-level Trust Store, or directly in the binary of the app.

Examples of Operating System-level Trust Stores:

Any apps which use an OS' trust store will verify a certificate by following the signature chain until they hit a certificate which is in the trusted root certificate store (note that "root" here means "root of trust", these could well be intermediate CAs). This type of trust store allows users to manually add / remove trusted "root certificates", so you could stop the chain at Intermediate CA 1, if you wanted to.

The other type of certificate pinning is to embed the certificates (or often, only their fingerprints, or hashes) directly into the source code of the app. Chrome, Firefox, and other browsers work this way. In these cases, the only way to add / remove a pinned certificate is to download a security patch for the browser.

Actually, on further inspection, it appears that Chrome uses a hybrid approach: they embed fingerprints of trusted root CAs into the binary, and also respects the OS' trust store, if possible, for certs not in the binary (source).

Certificate Transparency

There's a new technology called Certificate Transparency (CT) which is still in early phases, but when it rolls out fully it will affect the definition of "trust" for certificates. The idea of CT is for neutral 3rd parties to maintain public logs of high profile public certificates that browsers can check as an extra verification that the certificates they have in their trust store are genuine. CT is meant to address the problems of slow revocation times, and fraudulent certificates. For example, when the CA DigiNotar has its CA Signing Key stolen in 2011, the attackers were able to issue themselves a new, authentic certificate for google.com. CT would prevent this since there is already a valid certificate for google.com in the public CT logs.

So while CT is aimed at solving some fairly narrow problems, it will also generally increase the trustworthiness of all certificates, and affect the process by which browsers validate certs.


With standard browser, it will most likely not work. However, nothing prevents such behavior with standalone applications (see Thomas Pornin's answer to SSL root certificate optional?), in such case one would talk of a trust anchor, ie. it is not a root certificate (it is not self-signed) but is nevertheless a trusted certificate usable as starting point to build the certification chain.

  • 1
    Re. "Trust Anchor" definition. RFC5280 says this: >>The selection of a trust anchor is a matter of policy: it could be the top CA in a hierarchical PKI, the CA that issued the verifier's own certificate(s), or any other CA in a network PKI. The path validation procedure is the same regardless of the choice of trust anchor. In addition, different applications may rely on different trust anchors, or may accept paths that begin with any of a set of trust anchors. << May 28, 2015 at 11:26

You must log in to answer this question.

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