skip to content

Why can a Newman run present a different client certificate than the one passed with --ssl-client-cert?

level: middleimportance: should knowfreq 38%

answer

  1. The flag adds, it does not override
  2. Position in the list decides it
  3. First matching entry wins the call
  4. Appended last, matching every URL

basics

~20 s

The flag does not override anything. Its entry is appended to the end of the run's certificate list with a match pattern covering all URLs, and the first matching entry is used, so any earlier host-scoped entry wins.

solid answer

~50 s

`--ssl-client-cert` is an **addition, not an override**. The run keeps a certificate list in which each entry pairs the files to present with a match pattern, and the entry used is the **first one whose pattern covers the URL** — nothing merges and nothing prefers the more specific rule. Newman pushes the command-line certificate to the **end** of that list with an `<all_urls>` pattern, so it can answer for any host but is only ever *reached* when no earlier entry did. A host-scoped entry already in the list therefore wins outright for its host, and the flag becomes a catch-all for everything else. The tell is a flag that appears to do nothing for exactly one host while working everywhere else. The fix is to change the shadowing entry, or to supply a list rather than the single flag.

code

bash · 4 lines
bash
newman run ./collection.json \
  --ssl-client-cert-list ./certs.json \
  --ssl-client-cert ./fallback.pem \
  --ssl-client-key ./fallback.key

go deeper

for a junior

Be ready to say that passing a client certificate on a Newman command line adds one entry to the run's certificate list rather than forcing that certificate onto every call.

for a middle

Explain the mechanism: the entry is appended at the end with an all-URLs match, and the first entry whose pattern covers the URL is the one used, so a host-scoped entry wins.

for a senior

Show how you confirm which identity was actually presented — from the server side rather than the command you typed — and how you unshadow the certificate you intended without adding another catch-all.

for a principal

Own the design point: one broad fallback identity for a whole run is a blunt default. Argue for scoped entries when several identities are in play, and for making the selection reviewable.

## What the flag hands the run `--ssl-client-cert` points a terminal run at a client certificate on disk, normally alongside `--ssl-client-key` for the private key and `--ssl-client-passphrase` when that key is encrypted. It looks like an override — you named a certificate, so surely that certificate is the one presented. It is not an override. It is an **addition**, and where the addition lands is the whole answer. ## Where the entry lands, and why last place decides it The run keeps a **certificate list**. Each entry pairs the files to present with a **match pattern** saying which URLs it applies to. When a certificate is needed, the list is walked and the **first entry whose pattern covers the URL** is the one used; nothing merges, nothing scores, nothing prefers the more specific rule. Into that list, a command-line `--ssl-client-cert` is **pushed at the end**, with a match pattern of `<all_urls>` — a pattern that covers everything. Both halves matter: - **`<all_urls>`** means the entry is willing to answer for every host, so it can never be skipped for being too narrow. - **End of the list** means it is only ever *reached* when no earlier entry answered first. So an entry that names one host is consulted before the appended catch-all and wins for that host. The command-line certificate is a **fallback for hosts nothing else claimed**, not a preference. ## Single flag versus a host-scoped entry | | `--ssl-client-cert` on the command line | A host-scoped entry in the list | |---|---|---| | Match pattern | `<all_urls>` — every URL | only the hosts it names | | Position | appended at the end | ahead of anything appended | | Practical role | fallback when nothing matched | wins outright for its hosts | | Usual source | one certificate for a whole run | a certificate list handed to the run (`--ssl-client-cert-list`) | ## What it looks like when it bites - The flag appears to do **nothing at all** for one particular host, while working fine for every other host in the same run. - The server's log shows a **different client identity** than the certificate you passed, or rejects the call outright as an unknown client. - Removing the flag changes nothing for the affected host — the strongest single clue, because it proves that host was never being served by the flag in the first place. - Two engineers get different results from the same command, because one of them has a list file the other does not. ## Getting the certificate you intended 1. **Find out what is already in the list before your flag is appended.** The command line is the last contributor, not the only one. 2. **If a host-scoped entry shadows yours, change that entry** — point it at the paths you actually want, or drop it for this run. Adding another catch-all cannot outrank it. 3. **If the run genuinely needs per-host behaviour, supply a list rather than the single flag.** The single flag can only ever be the entry at the end; it has no way to express "this host only". 4. **Confirm from the far side.** Client-certificate selection is invisible from the caller's own output, so verify against what the server recorded rather than against the command you typed. ## Why this is a handover problem, not a certificate problem In the application, per-host certificate configuration is something you set once and then forget; the call simply presents the right identity. Moving to a terminal, that configuration has to be handed over — and the easiest way to hand it over, the single flag, has a **different precedence** from the per-host arrangement it is replacing. The mistake is not typing the flag wrong. The mistake is assuming that naming a certificate on a command line means naming *the* certificate, when it means adding one more at the bottom of a list you may not have inspected.

  • How would you make the certificate you passed on the command line the one actually presented?
    Not by adding another catch-all — it would land at the end too. Either change the host-scoped entry that shadows it to point at the paths you want, or drop that entry for this run. If the run genuinely needs different identities per host, supply a certificate list; the single flag can only ever be the last entry.
  • What does the appended entry's all-URLs match pattern imply for hosts you never intended to cover?
    It is willing to answer for every URL the run touches. Once no earlier entry matches, that certificate is offered to whatever host comes next, including third-party hosts a collection happens to call. It is a broad default rather than a targeted one, which is a good reason to prefer scoped entries when more than one identity is in play.

It is the last name on a duty roster marked 'covers everyone': anyone rostered for a specific desk is called first, and the catch-all only answers what nobody else claimed.

saying these in an interview costs you the question

  • Says a command-line certificate always overrides saved entries
  • Thinks the most specific match pattern wins the resolution
  • Assumes certificate entries merge rather than being picked
  • Believes the flag replaces the run's certificate list entirely
  • Blames the file paths without inspecting the list's other entries