In a Postman certificate entry, do key.src and cert.src hold the key material itself or file paths?

juniorshould knowfreq 40%

answer

Nothing in the entry is key material
The clue is in the property name
Something must read from disk later
A file that cannot be read only warns

basics

~10 s

File paths. A Postman Certificate's key.src and cert.src name files a fileResolver must read at send time, so the entry references key material rather than carrying the bytes itself.

solid answer

~40 s

They are paths. In the Postman SDK a saved client certificate is a Certificate object carrying name, matches, key, cert and passphrase; key.src and cert.src are strings naming files on a filesystem, not the key or certificate bytes. The SDK object is inert — the files are opened at send time by the runtime, through a fileResolver it is given. Two things follow. First, the entry is machine-local: it travels as a reference, so another laptop, container or build agent needs the same files at the same paths. Second, and this is the part interviewers push on, a read failure does not fail the request — it only emits a warning, and the call goes out with no certificate attached. A green run is therefore not evidence that a certificate was presented.

They are **paths**. In the Postman SDK a saved client certificate is a `Certificate` object carrying `name`, `matches`, `key`, `cert` and `passphrase`; `key.src` and `cert.src` are strings naming files on a filesystem, not the key or certificate bytes. The SDK object is inert — the files are opened at send time by the runtime, through a `fileResolver` it is given. Two things follow. First, the entry is machine-local: it travels as a reference, so another laptop, container or build agent needs the same files at the same paths. Second, and this is the part interviewers push on, a read failure does **not** fail the request — it only emits a warning, and the call goes out with no certificate attached. A green run is therefore not evidence that a certificate was presented.

code

json · 6 lines

json

{
  "name": "internal-api",
  "matches": ["https://api.internal.example/*"],
  "key": { "src": "/etc/pki/client.key" },
  "cert": { "src": "/etc/pki/client.crt" }
}

go deeper

for a junior

Be ready to say that key.src and cert.src are file paths, not the key or certificate bytes, and that something has to read those files when the request is actually sent.

for a middle

Explain that the read happens at send time through a fileResolver, in the process doing the sending, and that a failed read produces a warning rather than an error.

for a senior

Show how a path-based entry behaves differently on a laptop, in a container and on a build agent, and how you confirm the files resolved instead of assuming a green run means they did.

for a principal

Own how certificate files reach every environment that runs the suite, so a warning-only failure is caught by your own checks rather than discovered by the service on the far side.

What a certificate entry actually holds

In the Postman SDK a client certificate is a Certificate object, and the set a run may draw on is a CertificateList. A single entry is small and fixed:

name — a human label for the entry. It plays no part in selection.
matches — the URL patterns this entry is allowed to be used for.
key — an object whose src property names the private key file.
cert — an object whose src property names the certificate file.
passphrase — the passphrase belonging to that key, carried on the same entry.

The load-bearing word in key.src and cert.src is src: a source, meaning a place to read from. The entry is a reference to files on a filesystem, not a container for key material. Nothing in it is the key; nothing in it is the certificate. Both are strings that some component will later hand to a file reader.

Who does the reading, and when

The SDK object is inert — it describes a certificate, it does not open anything. The read happens at send time, in the process that actually performs the request, through a fileResolver: the file-reading interface the runtime is handed so it can turn key.src and cert.src into bytes. Two consequences follow immediately:

If no fileResolver is supplied to the run, there is nothing that can turn a path into bytes at all.
The paths are resolved on the machine and in the process doing the sending, against whatever that process treats as its working directory — not on the machine where the entry was authored.

Property	What it stores	Who consumes it
`key.src`	a path to the private key file	the `fileResolver`, at send time
`cert.src`	a path to the certificate file	the `fileResolver`, at send time
`passphrase`	the passphrase for that key	the requester, together with the key
`matches`	URL patterns	`Certificate.canApplyTo`, during selection
`name`	a label	people reading the list

The failure mode: a read error only warns

This is the part that produces the interview question. If the file named by key.src or cert.src cannot be read — it does not exist, the path is relative to a different directory, the process lacks permission — the request is not failed. A warning is emitted and the call goes out without the certificate. From the client's point of view the run looks entirely normal: the request was built, sent and answered.

That asymmetry is worth stating out loud, because it inverts the usual debugging instinct:

A missing configuration file in most tools is a hard error. Here it is a warning.
The visible symptom appears on the far side — a caller that was not identified — not in your own output.
A green run is not evidence that a certificate was presented.
Nothing retries, and no other entry is substituted in its place.

What follows in practice

Certificate lists are machine-local configuration. Because the entry stores a path, moving it between laptops, containers or a build agent moves the reference, not the files. The other machine needs the same files at the same paths, or the paths must change with it.
Relative paths are a trap. They are resolved by the reading process, so the same entry behaves differently depending on the directory the run was started from. Absolute paths remove that variable.
The passphrase is a value on the entry, not another path. It travels with the entry; key.src and cert.src only point.
Whether those files are protected on disk is a different subject. The mechanism here is only that the entry names them.
Auditing a list means auditing a filesystem. Reading the entries tells you what should be presented; only the sending machine tells you what can be.

What this is not

This mechanism decides which files a call will try to present. It does not describe what the two ends of a connection then agree with each other, and it does not say whether presenting a certificate is the right design for a given service — those are separate subjects. Within this leaf the model stays simple: an entry is a pointer plus a set of URL patterns, the pointer is followed late, and following it can fail quietly.

## What a certificate entry actually holds In the Postman SDK a client certificate is a `Certificate` object, and the set a run may draw on is a `CertificateList`. A single entry is small and fixed: - `name` — a human label for the entry. It plays **no part** in selection. - `matches` — the URL patterns this entry is allowed to be used for. - `key` — an object whose `src` property names the **private key file**. - `cert` — an object whose `src` property names the **certificate file**. - `passphrase` — the passphrase belonging to that key, carried on the same entry. The load-bearing word in `key.src` and `cert.src` is *src*: a **source**, meaning a place to read from. The entry is a **reference to files on a filesystem**, not a container for key material. Nothing in it is the key; nothing in it is the certificate. Both are strings that some component will later hand to a file reader. ## Who does the reading, and when The SDK object is inert — it describes a certificate, it does not open anything. The read happens **at send time**, in the process that actually performs the request, through a `fileResolver`: the file-reading interface the runtime is handed so it can turn `key.src` and `cert.src` into bytes. Two consequences follow immediately: 1. If no `fileResolver` is supplied to the run, there is nothing that can turn a path into bytes at all. 2. The paths are resolved on the **machine and in the process** doing the sending, against whatever that process treats as its working directory — not on the machine where the entry was authored. | Property | What it stores | Who consumes it | |---|---|---| | `key.src` | a path to the private key file | the `fileResolver`, at send time | | `cert.src` | a path to the certificate file | the `fileResolver`, at send time | | `passphrase` | the passphrase for that key | the requester, together with the key | | `matches` | URL patterns | `Certificate.canApplyTo`, during selection | | `name` | a label | people reading the list | ## The failure mode: a read error only warns This is the part that produces the interview question. If the file named by `key.src` or `cert.src` cannot be read — it does not exist, the path is relative to a different directory, the process lacks permission — the request is **not** failed. A **warning** is emitted and **the call goes out without the certificate**. From the client's point of view the run looks entirely normal: the request was built, sent and answered. That asymmetry is worth stating out loud, because it inverts the usual debugging instinct: - A missing configuration file in most tools is a hard error. Here it is a warning. - The visible symptom appears on the **far** side — a caller that was not identified — not in your own output. - A green run is not evidence that a certificate was presented. - Nothing retries, and no other entry is substituted in its place. ## What follows in practice - **Certificate lists are machine-local configuration.** Because the entry stores a path, moving it between laptops, containers or a build agent moves the *reference*, not the files. The other machine needs the same files at the same paths, or the paths must change with it. - **Relative paths are a trap.** They are resolved by the reading process, so the same entry behaves differently depending on the directory the run was started from. Absolute paths remove that variable. - **The passphrase is a value on the entry, not another path.** It travels with the entry; `key.src` and `cert.src` only point. - **Whether those files are protected on disk is a different subject.** The mechanism here is only that the entry names them. - **Auditing a list means auditing a filesystem.** Reading the entries tells you what *should* be presented; only the sending machine tells you what *can* be. ## What this is not This mechanism decides **which files a call will try to present**. It does not describe what the two ends of a connection then agree with each other, and it does not say whether presenting a certificate is the right design for a given service — those are separate subjects. Within this leaf the model stays simple: an entry is a pointer plus a set of URL patterns, the pointer is followed late, and following it can fail quietly.

If the same certificate list is used on a build agent instead of a laptop, what breaks first?
The paths. `key.src` and `cert.src` are resolved by the process doing the sending, so the agent needs the same files in the same places, and relative paths shift with the working directory. When they do not resolve, the read only warns and the call goes out with no certificate.
Does the entry's name affect which certificate gets used?
No. `name` is a label for people. Selection is decided by `Certificate.canApplyTo` — the `https` scheme test first, then the `matches` patterns — and by the entry's position in the `CertificateList`, because `resolveOne` returns the first match.

The entry is a signpost, not a safe: it tells the runtime where to go looking, and if the place it points at is empty the journey still happens, just empty-handed.

saying these in an interview costs you the question

Thinks the entry embeds the private key bytes inline
Assumes a missing certificate file fails the request loudly
Believes paths resolve on the authoring machine, not the sender
Confuses the passphrase, a value, with a file path
Treats a green run as proof a certificate was sent

In a Postman certificate entry, do key.src and cert.src hold the key material itself or file paths?

§ answer

basics

solid answer

code

§ go deeper

▾level notes4 levels

▾deep dive~4 min

What a certificate entry actually holds

Who does the reading, and when

The failure mode: a read error only warns

What follows in practice

What this is not

▾common follow-ups2 questions

▾analogy~10 s

▾red flags5 flags

What a certificate entry actually holds

Who does the reading, and when

The failure mode: a read error only warns

What follows in practice

What this is not

answer

go deeper