How would you govern WireMock's browser-proxy CA and --trust-all-proxy-targets across many suites?

## Two flags, two directions of trust Browser proxying puts WireMock in the middle of a conversation, and there are two independent trust decisions in that position. `--ca-keystore`, together with the certificate served at `GET /__admin/certs/wiremock-ca.crt`, governs the **client side**: what the stage-crew call-sheet client has to accept before it will talk to WireMock at all. `--trust-all-proxy-targets` governs the **upstream side**: what WireMock itself is willing to accept from the real service it proxies to. Teams that conflate the two reach for the second while debugging a failure caused by the first. It changes nothing about the symptom and silently removes a check, which is the worst possible combination, and it is common enough that a governing policy should name both flags explicitly rather than talking about *TLS problems* in general. ## Option A: every server mints its own CA Each WireMock instance signs with a CA of its own, and each job fetches the certificate from the server it just started, before the suite runs. - **What it buys.** Trust is scoped to the process that fetched it. When the job ends, the trust store goes with it, and no signing key is shared between teams or environments. - **What it costs.** Every suite needs a fetch-and-install step, in every language and runtime that talks to the stub. That is real wiring, and it is exactly the step people skip on a laptop and then reproduce badly in the pipeline. - **Where it fits.** Ephemeral CI jobs and containers, where a per-job trust store is the natural shape anyway. ## Option B: one pinned WireMock `--ca-keystore` Every stub server starts with the same CA keystore, so one certificate is distributed once: baked into a base image, shipped with the harness, added to a shared trust store. - **What it buys.** No per-run fetch. A client image is built already accepting the estate's stub CA, and a new suite works with no extra step at all. - **What it costs.** A signing key that now exists in more than one place. A CA can vouch for **any** host name, so that keystore is a secret with a real blast radius; it needs an owner and a rotation date, not a home in a repository next to the mappings. - **Where it fits.** A large estate where the per-job step is the thing that keeps breaking, and only with the key handled as a secret. ## What WireMock's `--trust-all-proxy-targets` actually relaxes When WireMock proxies onward to an HTTPS upstream, it is a client too, and it forms an opinion about the certificate that upstream presents. WireMock's `--trust-all-proxy-targets` tells it to stop forming that opinion. The legitimate use is narrow and real: a test upstream that serves a certificate nothing in your world knows about, in a suite whose purpose is not certificate validation. The governance problem is that the flag is equally effective as a way to make a red build go green without understanding it. Enabled by default in a shared launcher script, it means no suite in the estate can ever notice that a staging upstream's certificate has gone wrong, and the first place anyone learns is production. ## The policy worth writing down 1. **Trust is installed per job**, into a store that is created for that job and thrown away with it. Never into a runner's system trust store, and never into a developer's machine-wide store. 2. **A pinned CA keystore is a secret.** It has a named owner, lives where your other secrets live, and carries a rotation date that somebody is accountable for. 3. **WireMock's `--trust-all-proxy-targets` is opt-in per suite**, with the reason recorded next to the launch configuration. A default-on setting in a shared script is the anti-pattern. 4. **The fetch is scripted, not documented.** A step that reads WireMock's `GET /__admin/certs/wiremock-ca.crt` from the instance the job started is reproducible; an instruction in a wiki is not. 5. **The choice between A and B is made once, per environment class**, rather than drifting per team. Mixed regimes are how a machine ends up trusting a CA nobody remembers installing. ## Signals the policy has failed - A developer machine trusts a stub server's CA permanently, so the browser accepts anything that CA signs, long after the test run is over. - The same CA keystore appears in three repositories, and no one can say which copy is authoritative or when it was last replaced. - A launcher script sets WireMock's `--trust-all-proxy-targets` unconditionally and nobody can name the upstream it was added for. - Suites disagree: some fetch the CA per run, some rely on a baked-in one, and a new service fails in a way that depends on which image it inherited. - A certificate expiry takes out every suite at once, which is the estate telling you that the pinned option was chosen without the rotation half of it. ## What this is not This is a decision about distribution and ownership, not about how certificate validation works. The mechanics you are governing are small and specific: which keystore WireMock signs with, which endpoint hands out the matching certificate, and whether WireMock checks the upstream. Keep the discussion on those three, and the policy stays enforceable.