When two saved Postman certificate entries both match a URL, which one does CertificateList.resolveOne select?

middleshould knowfreq 45%

answer

It is a find, not a filter
Order in the list is the policy
Specificity is never scored
The scan stops at the first true

basics

~10 s

First match wins. CertificateList.resolveOne is a find, returning the first entry whose canApplyTo accepts the URL; later matching entries never apply, are never merged, and are not ranked by how specific their patterns are.

solid answer

~40 s

CertificateList.resolveOne(url) is implemented as a find: it walks the entries in order, asks each one's canApplyTo(url), and returns the first that answers true. The scan then stops. Three consequences matter. Position is the policy — there is no scoring of how specific a pattern is, so a catch-all sitting above a host-specific entry shadows it completely. Later entries never apply — they are not consulted, not merged and not offered as a fallback. And a request presents exactly one entry or none; there is no bundle. Arrange the list like a routing table: narrow entries first, any catch-all last. When the wrong identity goes out, reordering the list — not editing patterns or renaming entries, since name is decoration — is what changes the outcome.

`CertificateList.resolveOne(url)` is implemented as a **`find`**: it walks the entries in order, asks each one's `canApplyTo(url)`, and returns the **first** that answers true. The scan then stops. Three consequences matter. **Position is the policy** — there is no scoring of how specific a pattern is, so a catch-all sitting above a host-specific entry shadows it completely. **Later entries never apply** — they are not consulted, not merged and not offered as a fallback. And a request presents **exactly one** entry or none; there is no bundle. Arrange the list like a routing table: narrow entries first, any catch-all last. When the wrong identity goes out, reordering the list — not editing patterns or renaming entries, since `name` is decoration — is what changes the outcome.

code

javascript · 10 lines

javascript

const { CertificateList } = require('postman-collection');

const list = new CertificateList({}, [
  { name: 'catch-all', matches: ['https://*/*'],
    key: { src: '/certs/default.key' }, cert: { src: '/certs/default.crt' } },
  { name: 'payments', matches: ['https://payments.example.com/*'],
    key: { src: '/certs/pay.key' }, cert: { src: '/certs/pay.crt' } }
]);

list.resolveOne('https://payments.example.com/charges').name; // 'catch-all'

go deeper

for a junior

Recall that only one certificate entry is ever used for a request, and that the list is scanned in order from the top downwards.

for a middle

Explain that CertificateList.resolveOne is a find: the first entry whose canApplyTo accepts the URL wins, nothing is merged, and pattern specificity is never ranked.

for a senior

Show how you arrange a real list, narrow entries above broad ones, and how you recognise the wrong-identity symptom when a catch-all quietly shadows a specific entry.

for a principal

Own the convention for curating and reviewing certificate lists across teams, since ordering is the only policy the mechanism offers and a reordering is easy to miss.

resolveOne takes the first hit, not the best hit

CertificateList is the Postman SDK's collection of saved Certificate entries, and CertificateList.resolveOne(url) is the call that picks one for an outgoing request. It is implemented as a find: it walks the list in order, asks each entry's canApplyTo(url), and returns the first entry that answers true. The moment one matches, the scan stops.

Three things follow, and each is a common misconception in reverse:

Position is policy. The order of entries in the list is the entire tie-break. There is no scoring of how specific a pattern is.
Later entries never apply. An entry after the first match is not consulted, not merged and not offered as a fallback — even if it is the one a human would call obviously correct.
Exactly one, or none. A request presents the single selected entry, or no certificate at all. There is no bundle of several matching entries for the other end to choose from.

Expectation versus mechanism

What people expect	What actually happens
The most specific pattern wins	The first matching entry wins; specificity is not ranked
A later entry overrides an earlier one	The earlier entry is used; the later one is never reached
Matching entries are combined	One entry is selected, or none is
A non-matching entry blocks the rest	Non-matching entries are skipped and the scan continues
A better-named entry is preferred	`name` takes no part in selection at all

Ordering a list on purpose

Because order is policy, a list wants to be arranged the way a routing table is:

Narrow first. Entries whose patterns name a single host, or a single host and path prefix, belong at the top.
Broad last. Any catch-all entry belongs at the bottom, where it acts as a default rather than a shadow over everything beneath it.
Remember the scheme gate. An entry can never win for a non-https URL, because canApplyTo rejects that before the patterns are tested. A 'broad' entry is only broad across https targets.
Deduplicate. Two entries whose patterns overlap for the same host is the setup that produces the surprise; the fix is usually deleting one, not adding a third.

The symptom this produces

The run does not report a conflict. Nothing says 'two entries matched and I took the first'. What you see instead is one of two things:

The wrong identity is presented, and the far end rejects or mis-authorises the caller.
No certificate at all, because the entry that won points at files that could not be read — a read failure only warns, and the scan has already stopped, so the second matching entry is not tried instead.

That second case is worth saying explicitly in an interview: the first match wins before anything is known about whether its files exist. Selection and file resolution are separate steps, and failing the second does not send you back to redo the first.

How to answer it compactly

A good answer names the method, the implementation shape and the consequence in one breath: CertificateList.resolveOne is a find over the entries, so the first whose canApplyTo accepts the URL is used, later matches never apply, nothing is merged, and reordering the list is how you change the outcome. Then add the two failure modes above, and note that name is decoration.

Out of scope

Which files an entry points at, and what happens when they cannot be read, is the entry's own mechanism rather than the list's. What the far end does with the identity it is handed, and whether validation should ever be relaxed, are different subjects entirely and are better named as such than answered here. Selection is a small, deterministic rule: scheme, then patterns, then position — and position is the only tie-break there is.

## resolveOne takes the first hit, not the best hit `CertificateList` is the Postman SDK's collection of saved `Certificate` entries, and `CertificateList.resolveOne(url)` is the call that picks one for an outgoing request. It is implemented as a **`find`**: it walks the list in order, asks each entry's `canApplyTo(url)`, and returns the **first** entry that answers `true`. The moment one matches, the scan stops. Three things follow, and each is a common misconception in reverse: - **Position is policy.** The order of entries in the list is the entire tie-break. There is no scoring of how specific a pattern is. - **Later entries never apply.** An entry after the first match is not consulted, not merged and not offered as a fallback — even if it is the one a human would call obviously correct. - **Exactly one, or none.** A request presents the single selected entry, or no certificate at all. There is no bundle of several matching entries for the other end to choose from. ## Expectation versus mechanism | What people expect | What actually happens | |---|---| | The most specific pattern wins | The first matching entry wins; specificity is not ranked | | A later entry overrides an earlier one | The earlier entry is used; the later one is never reached | | Matching entries are combined | One entry is selected, or none is | | A non-matching entry blocks the rest | Non-matching entries are skipped and the scan continues | | A better-named entry is preferred | `name` takes no part in selection at all | ## Ordering a list on purpose Because order is policy, a list wants to be arranged the way a routing table is: 1. **Narrow first.** Entries whose patterns name a single host, or a single host and path prefix, belong at the top. 2. **Broad last.** Any catch-all entry belongs at the bottom, where it acts as a default rather than a shadow over everything beneath it. 3. **Remember the scheme gate.** An entry can never win for a non-`https` URL, because `canApplyTo` rejects that before the patterns are tested. A 'broad' entry is only broad across `https` targets. 4. **Deduplicate.** Two entries whose patterns overlap for the same host is the setup that produces the surprise; the fix is usually deleting one, not adding a third. ## The symptom this produces The run does not report a conflict. Nothing says 'two entries matched and I took the first'. What you see instead is one of two things: - The **wrong identity** is presented, and the far end rejects or mis-authorises the caller. - **No certificate at all**, because the entry that won points at files that could not be read — a read failure only warns, and the scan has already stopped, so the second matching entry is not tried instead. That second case is worth saying explicitly in an interview: the first match wins **before** anything is known about whether its files exist. Selection and file resolution are separate steps, and failing the second does not send you back to redo the first. ## How to answer it compactly A good answer names the method, the implementation shape and the consequence in one breath: `CertificateList.resolveOne` is a `find` over the entries, so the **first** whose `canApplyTo` accepts the URL is used, later matches never apply, nothing is merged, and reordering the list is how you change the outcome. Then add the two failure modes above, and note that `name` is decoration. ## Out of scope Which files an entry points at, and what happens when they cannot be read, is the entry's own mechanism rather than the list's. What the far end does with the identity it is handed, and whether validation should ever be relaxed, are different subjects entirely and are better named as such than answered here. Selection is a small, deterministic rule: **scheme, then patterns, then position — and position is the only tie-break there is.**

Can a later entry act as a fallback when the winning entry's files cannot be read?
No. `resolveOne` has already stopped at the first match, and the file read happens afterwards. A read failure only warns, so the request goes out with no certificate; the scan is never resumed and the second matching entry is not tried.
How do you make a catch-all entry safe to keep in the list?
Put it last. Since `resolveOne` returns the first match, a catch-all at the top shadows every specific entry below it, while at the bottom it behaves as a default. Remember too that it can never apply to a non-`https` URL, because the scheme test rejects those first.

It behaves like a firewall or routing table read top to bottom: the first rule that matches decides, and a broad rule placed above a specific one quietly swallows every packet the specific one was written for.

saying these in an interview costs you the question

Expects the most specific pattern to win
Thinks a later entry overrides an earlier match
Believes several matching certificates are merged or bundled
Assumes the entry name influences which one is chosen
Expects a fallback when the winning entry cannot be read

When two saved Postman certificate entries both match a URL, which one does CertificateList.resolveOne select?

§ answer

basics

solid answer

code

§ go deeper

▾level notes4 levels

▾deep dive~3 min

resolveOne takes the first hit, not the best hit

Expectation versus mechanism

Ordering a list on purpose

The symptom this produces

How to answer it compactly

Out of scope

▾common follow-ups2 questions

▾analogy~20 s

▾red flags5 flags

resolveOne takes the first hit, not the best hit

Expectation versus mechanism

Ordering a list on purpose

The symptom this produces

How to answer it compactly

Out of scope

answer

go deeper