A Postman request that should present a client certificate sends none, so how do you diagnose it?

## The three mechanisms that can swallow a certificate When a Postman-driven request should present a client certificate and does not, there are three mechanisms to check. They are best checked in this order, because each short-circuits the next. 1. **The URL is not `https`.** `Certificate.canApplyTo` returns `false` for any non-`https` URL **before** it ever tests the entry's `matches` patterns. No pattern, however broad or however carefully written, can rescue a plain `http` call. 2. **A different entry matched first.** `CertificateList.resolveOne` is a `find`: the first entry whose `canApplyTo` accepts the URL is taken and the scan stops. If a broad entry sits above the specific one, the broad one is used and the specific one never applies. 3. **The files did not resolve.** `key.src` and `cert.src` are **file paths**, read at send time by a `fileResolver`. A read error **only warns** — the request is sent anyway, with no certificate attached. ## Why the run looks healthy The reason this is an interview question at all is that none of the three produces a client-side failure: - A non-`https` URL is a perfectly ordinary request; it succeeds or fails on its own merits. - Selecting a different entry is not an error condition; the list did exactly what it is defined to do. - A missing key or certificate file is a **warning**, not a thrown error. So the run is green, a response arrives, and the only real signal is on the far side: a caller that was not identified. A candidate who says 'it would have failed loudly if the certificate were missing' has the model backwards, and that is usually the thing being tested. ## A diagnosis order that terminates | Check | What you are looking for | Mechanism behind it | |---|---|---| | Scheme of the URL actually sent | `http` where you assumed `https` | the scheme test precedes the pattern test | | Position of the intended entry | another matching entry above it | `resolveOne` is a first-match `find` | | Patterns on the intended entry | host or path not covered | `matches` decides coverage | | Paths in `key.src` / `cert.src` | file missing on the sending machine | a read failure warns and continues | | The run's warnings | a file-read warning at send time | the only local evidence there is | Work top to bottom and stop at the first hit. Each row can independently explain the symptom, and fixing a lower row while an upper row is still true changes nothing you can observe. ## The environment axis Because `key.src` and `cert.src` are resolved by the sending process, one configuration behaves differently in different places: - On a laptop the files exist at the authored paths; in a container or on a build agent they usually do not. - Relative paths depend on the directory the run was started from, so the same entry can work and fail on one machine. - A setup that recently moved between environments and 'stopped presenting the certificate' is almost always this, rather than a change to the entry itself. ## Confirming rather than guessing 1. Capture the **fully assembled URL** that went out, not the saved request text, and read its scheme. 2. Read the certificate list **top to bottom** and work out which entry `canApplyTo` would accept first for that URL — that is the entry in play, whatever anyone intended. 3. Confirm the winning entry's `key.src` and `cert.src` resolve **on the machine doing the sending**, from the same working directory. 4. Look for a **file-read warning** in the run output. Its presence proves the third mechanism; its absence rules it out. 5. Only then change one thing at a time — the scheme, the ordering, the patterns, or the paths — and re-run. ## What not to conclude - **Do not reach for relaxed validation.** Whether and when validation may be relaxed is a separate discipline, and it is not a fix for a certificate that was never selected in the first place. - **Do not start at the handshake.** What the two ends agree with each other is a different subject; all three mechanisms above happen on your side, before anything is negotiated. - **Do not assume a second matching entry covers for the first.** Selection stops at the first match, and a later failure to read files does not resume the scan. The compact senior answer is: **check the scheme, then the list order, then the file paths** — because the scheme test short-circuits the pattern test, the list takes the first match, and a failed file read only warns.