TLS clients typically ship with a store of well over a hundred certificate authorities. Explain the security property that follows from that, why revocation is the weak part of the model, and what a system can do when 'any public CA' is too broad a trust set.

## The property: trust is a disjunction A client accepts a server certificate if it chains to *any* anchor in its trust store. That is a logical OR over a set that, on a typical operating system or browser, contains well over a hundred organisations across many jurisdictions - and each of them has signed intermediates, which may in turn have signed more. Two consequences follow directly. First, your security level is the **minimum** across that entire set, not the maximum: it takes one negligent, breached or coerced authority to produce a certificate for your domain that every client will accept. Second, in the base model there is **no binding between a name and its issuer**: nothing about your domain says which authority is allowed to issue for it, so a certificate from an authority you have never heard of is as acceptable as one from your own. That is why mis-issuance - rather than cryptographic weakness - is the realistic failure mode of the public certificate system. ## Why revocation does not fix it The obvious answer to a bad certificate is to revoke it, and revocation is the part of the model that works least well. - **Lists** of revoked certificates are large, grow monotonically, and are cached, so they are stale exactly when it matters. - **Online status queries** add a network round trip on the connection path, create an availability dependency on the issuer's infrastructure, and leak to that issuer which sites a client visits. - **The soft-fail problem** is decisive: an attacker positioned to intercept your connection is also positioned to drop the status query. If the client treats 'no answer' as acceptable - which almost all do, because hard-fail turns any status-service outage into a global outage - then revocation is advisory against exactly the attacker it was meant to stop. - **Stapling**, where the server supplies a recent signed status itself, removes the privacy leak and the extra round trip, but a client that does not *require* it is back to soft-fail, and an attacker simply omits it. The structural fix is to shorten the window instead of trying to signal within it: certificates valid for days, issued and renewed automatically. Expiry becomes the revocation mechanism, requires no client cooperation and cannot be blocked by an attacker. The price is that issuance must be fully automated, and that anything with a manual renewal process becomes an outage generator. ## Narrowing the trust set When the whole public authority set is too broad for a given relationship, the answer is to move from an open world to a closed one - to enumerate the issuers or keys that are acceptable for this specific peer. - **A private CA.** For internal service-to-service traffic, run your own issuing hierarchy and configure clients to trust only your roots for those peers. The acceptable set drops from hundreds of organisations to one you operate, and you can issue very short-lived certificates because you control both ends. - **Name-constrained intermediates.** An intermediate can be constrained to a specific set of domains, so even if it is misused it cannot vouch for anything else. Support for enforcing constraints varies by client, which is part of why the technique is used more inside private hierarchies than across the public system. - **Pinning.** A client hard-codes the acceptable public key or issuer for one specific service. This is the tightest control and also the most dangerous operationally: the pin must be rotated before the key is, you need backup pins, and a bricked pin in a shipped client is an outage that a server-side change cannot repair. Pin the key or the issuing CA rather than the leaf, keep an overlap window, and only where the value justifies the operational burden - a mobile client talking to its own backend, not a general-purpose browser. Each of these is the same move: replace 'anyone the world trusts' with a finite set your configuration owns. ## Detection: issuance transparency Certificate Transparency addresses the residual problem that you cannot prevent every authority from mis-issuing. Issuance is submitted to public append-only logs, clients can require proof that a certificate was logged, and domain owners monitor the logs for certificates naming their domains that they did not request. Be precise about what this is: it does not stop mis-issuance, it makes mis-issuance **discoverable**, and only if someone is watching. In the ordering of controls, narrowing the trust anchors is structural separation - the attacker's certificate is simply not in the accepted set; transparency logging is the detection rung at the bottom - a heuristic that depends on monitoring, response time and someone acting on the alert. It is genuinely valuable, and it is not a substitute for the rungs above it. A domain owner who publishes issuance restrictions and monitors logs has a real, if reactive, control; one who does neither has none. ## Mutual authentication The same model runs in the other direction when the server authenticates the client with a certificate. The important difference is that you usually control both ends, so the closed-world options are actually available: a private CA, a small trust set, short lifetimes, automated rotation. That is why certificate-based client authentication is practical between your own services and painful with a public trust set. One boundary to state clearly: client-certificate authentication identifies the *connecting peer*, not the human user behind it. A service that authenticates its caller cryptographically still needs a separate user identity and authorisation decision, because the connection identity says which workload is calling, not on whose behalf.