What does WireMock serve at GET /__admin/certs/wiremock-ca.crt, and who needs it?
answer
- an admin endpoint that serves a certificate
- the public half, never the signing key
- browser proxying is what makes it necessary
- the client's trust store is the destination
- fetched per job from the instance you started
basics
~20 sIt serves the public CA certificate WireMock signs browser-proxy certificates with. A client proxied through WireMock must install it in its trust store, or the call fails before any stub is matched. The private key stays on the server.
solid answer
~40 sIn WireMock, `GET /__admin/certs/wiremock-ca.crt` is an admin endpoint that hands out the **certificate authority certificate** the server signs with while browser proxying. It is the public half only: the signing key never leaves the server, which is why the endpoint is safe to call from a test job. The consumer is the **client**, not WireMock. A call-sheet suite routed through a browser-proxying WireMock is offered a certificate minted for `calls.stagecrew.internal` and signed by that CA, and it will refuse the connection until the CA is in whatever trust store it reads — a JVM trust store, `curl --cacert`, a browser's own store. The usual pattern is to fetch it as a start-up step of the job and import it into a trust store that is thrown away with the job.
go deeper
Be able to say what the endpoint hands out and who consumes it: the CA certificate, fetched by the client, installed in the client's trust store. Knowing that the private key is never served is a good extra.
Explain why browser proxying forces a signed certificate per host, and therefore why a client is given the signer rather than a certificate. Say where trust lives for a JVM, a curl call and a browser.
Show the job step that fetches from the instance it just started and imports into a throwaway trust store, and explain why trust installed on a host does not reach a container running the suite.
Weigh fetching per run against distributing one pinned CA in a base image. The first has no shared secret and more wiring; the second is convenient and turns a keystore into something with a rotation owner.
## What the endpoint returns `GET /__admin/certs/wiremock-ca.crt` sits on WireMock's admin API alongside the mapping and request routes, and it returns one thing: the **certificate of the certificate authority** that this WireMock instance signs with. Three properties matter and they are easy to state: - It is the **public** certificate. The private key that does the signing stays in the server's keystore and is never served. - It is served by the **running instance**, so it reflects whatever CA that instance is actually using — a generated one, or the one supplied through WireMock's `--ca-keystore`. - It is fetched over the admin API like any other admin call, which means a job can script it rather than a human copying a file around. ## Why WireMock has a CA at all A WireMock instance that only answers on its own address needs one certificate, and `--https-keystore` supplies it. A WireMock instance running as a **browser proxy**, under `--enable-browser-proxying`, is in a different position: the client keeps asking for the real host — `https://calls.stagecrew.internal/call-sheets/v1/shows/42/calls` — and expects to negotiate TLS with *that* name. WireMock therefore mints a certificate for whichever host was requested and signs it. Signing is what makes one distributed certificate cover every host the client might ask for, and it is the whole reason the endpoint exists: the client cannot be given a certificate per host in advance, so it is given the signer instead. ## Who installs it, and where The server does nothing with this certificate. The **client** does, and *where* depends entirely on what the client reads: - A **JVM suite** reads a trust store. Import the fetched certificate into one and point the test process at it. - A **curl** call takes it directly through curl's own `--cacert` flag, pointed at the file fetched from WireMock. - A **browser** has its own store, which is usually not the same store a command-line tool uses. Working in one and failing in the other is the classic symptom. - A **container** reads whatever store is inside the image. Trust installed on the host machine does not travel into it. The practical shape in a pipeline is three steps: 1. Start WireMock with browser proxying enabled. 2. Fetch WireMock's `GET /__admin/certs/wiremock-ca.crt` from that instance. 3. Import it into a trust store created for this job, and run the suite against that store. Doing it in that order guarantees you trust the CA of the server you just started, rather than one left over from a previous run or copied from a colleague. ## When you do not need it It is worth being clear about the cases that never touch this endpoint, because reaching for it in one of them wastes an afternoon: - **Plain HTTP stubbing.** No certificate is involved anywhere, so there is nothing to trust. - **A `--https-port` listener with your own `--https-keystore`.** The client is dialling WireMock directly and must accept *that* keystore's certificate. The browser-proxy CA is a different certificate and installing it changes nothing. - **A client configured to skip verification entirely.** Some test clients can be told not to check, which makes the whole question moot — at the cost of the suite no longer exercising anything about trust. - **`--trust-all-proxy-targets`.** This one is genuinely confusing and it is the wrong lever: it governs what WireMock accepts from an upstream it proxies onward to, not what your client accepts from WireMock. ## Handling it without creating a hazard The certificate itself is harmless to publish — it is the public half. The hazard is in **where you install it**, because a client that trusts this CA will accept a certificate that CA signs for *any* host name. - Install into a trust store that belongs to the job or the container, and let it be discarded with them. - Do not add a stub server's CA to a developer machine's system store or a browser's permanent store, where it keeps applying long after the run. - If you pin one CA across the estate with WireMock's `--ca-keystore`, treat the keystore behind it as a secret with an owner, and remember the endpoint still returns the matching certificate from any instance using it. - Fetch from the instance you started, on an address you control, so you are not trusting the CA of some other server that happened to answer. ## The one-line version Browser proxying makes WireMock sign certificates; `GET /__admin/certs/wiremock-ca.crt` is how the client gets hold of the signer so those certificates mean something. Everything else about it — where to put it, how long to keep it, whether to pin one CA or fetch a fresh one — follows from that single sentence.
- If you supply your own CA with WireMock's --ca-keystore, does that endpoint still matter?Yes. In WireMock the endpoint returns the certificate of whichever CA the instance is signing with, so it stays the reliable way to obtain it from a running server. What changes is that a pinned CA can also be distributed ahead of time — baked into an image or a shared trust store — so a job may not need the fetch at all.
- Is anything sensitive exposed by serving that certificate over the admin API?The certificate is the public half, so publishing it leaks nothing; the signing key stays in WireMock's keystore. The care needed is on the client side: a machine that installs this CA will accept certificates it signs for any host name, so install it into a job-scoped or container-scoped trust store rather than a permanent system one.
It is the stub server's own badge printer. The badges it prints open doors only after reception has been told to accept badges from that printer.
saying these in an interview costs you the question
- Thinks the endpoint returns a private key or a whole keystore
- Installs the certificate on the server instead of the client
- Believes plain HTTP stubbing needs the CA certificate too
- Says WireMock's --trust-all-proxy-targets removes the need to trust the CA
- Expects WireMock to push its CA to clients automatically