Your inspection proxy's private root sits in every managed laptop's trust store: what can a key holder do, and what does it commit you to?

## What actually happens when you push a root A TLS client accepts a server certificate when it can build a chain from that certificate to a **trust anchor** already present in its store, and the certificate's names cover the hostname it asked for. Nothing in that check asks *who* the anchor belongs to or *why* it is there. A root your company generated and pushed to a laptop through device management is validated by exactly the same code path as a root shipped by the operating system vendor. That is the whole point of an inspecting proxy. The proxy terminates the client's connection, opens its own connection outward, and mints a certificate for the hostname the client asked for, signed by your root. Because the root is trusted, the browser is satisfied and the user sees nothing. ## The grant is not scoped to what you meant to inspect The common beginner model is that the root "works for traffic through the proxy". It does not. The scope of the grant is the **name space**, not the path. A certificate signed by that key for `pay.bank.example` is accepted by every device that trusts the root, whether the traffic went through your proxy, through a hotel wireless network, or through an attacker's hotspot in another country. The device carries the trust with it. The only technical narrowing available is the **name constraints** extension inside the root certificate itself, which a compliant validator enforces during path validation. Absent that, the grant is: any name, forever, until the root leaves the store or expires. ## Who the adversary is Once you hold this key, your threat model includes people who are not attacking your network at all: - an engineer on the platform team who leaves with a copy - an intruder in the cloud tenancy where the signing key lives - a supplier or contractor who was handed the key to stand up an appliance - a backup or configuration export that ended up somewhere less guarded than the proxy None of them need to be in your traffic path afterwards. They need to be in *a* traffic path in front of one of your laptops. For a remote-first company whose staff work from home networks, cafes and shared offices, that is not a demanding requirement. ## Why nobody outside will tell you Publicly trusted issuance is watched. Certificate Transparency logs record certificates issued by publicly trusted CAs, and domain owners monitor those logs for names they did not ask for. Browsers deliberately **exempt** chains that terminate in a locally installed root from Certificate Transparency enforcement and from built-in key pinning, precisely so that enterprise inspection works. That exemption is what makes your deployment function, and it is also what removes your outside early-warning system. A forged certificate from your root appears in no public log, triggers no domain owner's alert, and shows no error on the victim's screen. So detection of misuse is entirely internal, and only as good as the issuance record your own proxy keeps. ## The price you have signed up for Operating a private issuing authority is an institution, not a setting. The minimum a competent team is expected to name: | Obligation | What it looks like | |---|---| | Key generation | Created inside hardware, non-exportable, witnessed, with a signed record of who was present | | Custody | No single administrator can use or export the key alone | | Constraint | Name constraints in the root so a compliant client refuses names you promised never to mint | | Record | Every minted certificate logged with its names and time, shipped where the CA operators cannot rewrite it | | Retirement | A rehearsed path to distribute a replacement root and remove the old one from every trust store | And one honest caveat to carry into the interview: the trust store on the operating system is not the only store. Applications, language runtimes and container images frequently carry their own bundled certificate list, so both the rollout and the eventual removal are wider jobs than one device-management push. ## The answer an interviewer wants Say what the grant *is* (any name, on any network, silently), say who can exercise it (anyone with the key, not anyone on your network), say why you will not hear about misuse from outside (no transparency coverage for privately installed roots), and then name the custody obligations you accepted in exchange for the visibility. A candidate who describes only the visibility has answered half the question.