In a Karate feature file, what does `* configure ssl = true` do, and does it make Karate verify the server's TLS certificate?

## What the key really switches on `configure ssl` does not mean "use HTTPS" — an `https://` URL already does that. It means "stop using the JVM's default trust behaviour and use the SSL context I am describing here". The three accepted value shapes are: | value | effect | |---|---| | `true` | Karate's own SSL context, trusting every certificate | | a string, e.g. `'TLSv1.2'` | same, with that string used as the TLS algorithm | | a map | the full form: key store, trust store, algorithm, and `trustAll` | In every one of those shapes, `trustAll` is **true unless you say otherwise**. That single default is the whole answer to the interview question and the thing most candidates get backwards. ## Why the default is trust-all The key exists because test environments run on certificates that nothing trusts — self-signed, issued by an internal CA the runner does not know, hostname mismatched because you are hitting a service by its container name. `configure ssl = true` is the one-line escape from all of that, and it is a legitimate thing to write in a test suite. What it is not is a statement that TLS works. That is the trade you are making, and it is worth saying out loud in an interview. ## The map form, and the two things it is for The map is the interesting shape, and it does two separable jobs: 1. **Presenting a client certificate** (mutual TLS): `keyStore`, `keyStorePassword`, `keyStoreType` — typically a `.p12` read from the classpath. This is the common reason to reach for the map at all. 2. **Choosing what to trust**: `trustStore`, `trustStorePassword`, `trustStoreType`, plus `trustAll`. Those combine freely. Supplying a trust store while leaving `trustAll` at its default still trusts everything — the trust store is simply never the deciding factor. If the point of the exercise is to prove the server presents a certificate your trust store accepts, the map needs `trustAll: false` alongside it. ## Configuring it more than once Each assignment to `configure ssl` replaces the previous value rather than merging into it. A scenario that starts with `configure ssl = true` and later configures a map to add a client certificate is describing two complete states, not a base and an overlay — so every setting the second one needs has to be in that second map. Treat it the way you treat `configure headers`: the latest assignment owns the whole setting. And like every `configure` key, where you put it decides how far it reaches: the config file for a whole suite, a `Background` for one feature's scenarios, a single scenario for one story. ## The operational consequence people miss A suite that sets `configure ssl = true` globally will keep passing after: - the environment's certificate expires; - the certificate is swapped for one issued by a different authority; - a proxy is inserted that terminates TLS and presents its own certificate; - the hostname stops matching the certificate's subject. None of those failures reach the test suite, because the client was told not to look. That is usually the right trade for functional API tests against a test environment, but it means a green suite is not evidence about TLS. If certificate validity matters, it needs its own check — one scenario, without trust-all, that would fail when the certificate does. ## It is one key among a family, and it behaves like the rest Nothing about `ssl` is special in how it is set. It takes the same two forms as every other setting — the step `* configure ssl = ...` and the JavaScript `karate.configure('ssl', ...)` that a config file uses — and both reach the same key parser. Two ordinary consequences follow, and both catch people out on this key in particular: 1. **A typo is loud, a wrong shape is not.** `configure sll = true` throws `unexpected 'configure' key: 'sll'`, because the key switch has no permissive fallback. But a map with a misspelled sub-key — `trustall` for `trustAll`, say — is not a key error at all: the sub-key is simply never read, and the setting keeps its default of trusting everything. The failure mode of a mis-typed trust setting is therefore silence, in the insecure direction. 2. **`= null` clears it like any other key.** `* configure ssl = null` drops the whole SSL configuration for the rest of that scenario, returning the client to its default behaviour. It clears only `ssl`; the timeouts, headers and retry settings are untouched. Because the setting lives on the HTTP client rather than on the request, changing it partway through a scenario governs the calls that follow — which is what makes a scenario that starts unencrypted and then switches on a client certificate possible to write at all. ## A short answer worth giving "It replaces the default SSL context with Karate's, which trusts every certificate. `trustAll` defaults to true, so it is the opposite of verification — that is why a self-signed certificate stops failing. For mutual TLS or real verification you pass a map with key store and trust store settings, and you have to set `trustAll: false` yourself."