The most common method of TLS authentication using these certificates depends on a [public key infrastructure](https://en.wikipedia.org/wiki/Public_key_infrastructure) that ties public keys to entities. Typically, TLS clients are configured to trust a set of [certificate authorities](https://en.wikipedia.org/wiki/Certificate_authority). These root CAs act as the set of trust anchors trusted by the client. Trust flows to all other entities in the ecosystem via a [chain of trust](http://en.wikipedia.org/wiki/Chain_of_trust) conveyed via a certificate chain. The issuance of the end-entity certificate is signed by an earlier certificate in the chain, which may itself be signed by an earlier certificate and so on until reaching the root certificate, which is self-signed, and whose trust is established by being configured by the client.

Relying on a PKI to provide trust has a number of disadvantages. For one, if a website loses control of its key, the certificate is no longer valid and must be revoked. Thus, in practice, TLS certificates contain instructions for determining whether or not they have been revoked, and clients can follow this to determine revocation status. The two main mechanisms for this are certificate revocation lists (CRLs) and OCSP. The problem with these online revocation checks is that [they don't work in practice](https://www.imperialviolet.org/2011/03/18/revocation.html). In short, online checks require being able to query a service (presumably run by the issuing CA) as to the revocation status of a certificate, but due to reluctance to have an availability requirement on these services, clients have generally accepted certificates when the online check times out. Soft-fail mechanisms are clearly vulnerable to active attacks, thereby limiting the effectiveness of certificate revocation schemes.