Your JMeter recording of an HTTPS journey fails with unknown_ca in the browser. What do you do?

HTTPS recording is the part of JMeter's recorder that fails most often, and almost always for the same reason: the browser is doing its job. A proxy that wants to read HTTPS has to terminate the connection and present its own certificate, and no browser accepts that from an authority it has never heard of. ## What JMeter generates, and when The keystore work happens when you press **Start**, not when you add the element. On that first press the recorder: 1. locates `keytool` — on the PATH, then under `java.home/bin`; if it cannot find it the recorder reports an error, and the `keytool.directory` system property (set in `system.properties`) tells it where to look; 2. creates a keystore, by default `proxyserver.jks` in JMeter's `bin` directory, containing a root CA whose distinguished name begins `CN=_ JMeter Root CA for recording (INSTALL ONLY IF IT IS YOURS)`; 3. exports that root certificate into the **launch directory** as `ApacheJMeterTemporaryRootCA.crt` — and `ApacheJMeterTemporaryRootCA.usr` for Opera; 4. pops up a dialog showing the certificate details so you can compare them against what the browser will show you. Generation takes a noticeable moment, during which the GUI is unresponsive and the cursor becomes an hour-glass. The keystore and key passwords are randomly generated and kept in the local preferences area, precisely so a shared password cannot be lifted from a config file and reused. ## Fixing unknown_ca `unknown_ca` is the browser refusing a certificate chain that ends in an authority it does not trust. The fix is to install the exported root CA: - **Firefox** — Certificates > View Certificates > Authorities > Import, choose `ApacheJMeterTemporaryRootCA.crt`, verify the details against the recorder's pop-up, and tick "Trust this CA to identify web sites". - **Chrome / Internet Explorer** — open the same `.crt` file, check the Details tab against the recorder's pop-up, then Install Certificate. - **Opera** — import `ApacheJMeterTemporaryRootCA.usr` under the Intermediate tab. Record in a private window where you can. It starts with no stored cookies, and some browsers refuse to persist a certificate override anyway. ## Why the log names hosts you never visited In **dynamic mode** — `proxy.cert.dynamic_keys`, default `true` — the recorder mints a certificate for each target host as it is needed, signed by that root CA. Once the CA is trusted, those per-host certificates are accepted without a prompt, and that is what makes embedded resources on other hosts recordable at all: browsers never prompt for an embedded image or script, they simply drop it. So a CDN or fonts host you never typed shows up in `jmeter.log` as a domain needing a certificate. If dynamic mode is off, the recorder falls back to a single key with no per-host certificate, and third-party embedded resources will not record. The **HTTPS Domains** field pre-generates certificates for hosts you name, and accepts wildcards such as `*.example.com`. The wildcard covers exactly one label: `abc.subdomain.example.com` matches `*.subdomain.example.com`, not `*.example.com`. ## The expiry trap `proxy.cert.validity` defaults to **7** days. That is deliberate — a trusted CA is a standing risk, and a short life bounds it — but it means a workflow that worked last week fails today with certificate errors. The recovery is mechanical: 1. remove the old JMeter CA from the browser's trust store; 2. delete `proxyserver.jks` from the JMeter directory; 3. start the recorder again, which regenerates the keystore and re-exports `ApacheJMeterTemporaryRootCA.crt`; 4. install the new certificate. Skipping step 1 is what produces the other classic symptom: the browser already holds a validated certificate for the domain, sees a different one, and refuses the page outright rather than prompting. ## Bringing your own keystore Defining `proxy.cert.alias` switches the recorder to a user-supplied keystore and stops it generating anything. `proxy.cert.directory` and `proxy.cert.file` (default `proxyserver.jks`) name the keystore either way — they are where JMeter writes the one it generates as much as where it looks for yours. `proxy.cert.keystorepass` and `proxy.cert.keypassword` really are ignored while JMeter generates, because it mints a random password instead and keeps it in the local preferences. The manual marks `proxy.cert.type` (`JKS`) and `proxy.cert.factory` (`SunX509`) ignored too, but the recorder still reads both to load the store and build its key managers in every mode. How a trust chain is built and what makes a CA trustworthy is not JMeter's subject; `proto-tls-certs` and `proto-pki` own that. ## Hygiene Once the JMeter CA is trusted, the browser accepts anything signed by it until it expires or is removed. Anyone who can read the keystore and its password can mint certificates that browser will believe. Keep it on a machine only you use, and remove the CA from the browser when the recording session is over.