Why is a configured Postman client certificate never presented when the request URL uses http rather than https?
answer
- Two tests, and the order matters
- One of them never runs for some URLs
- The patterns are not what excluded it
- Look at the scheme before the host
basics
~10 sPostman's Certificate.canApplyTo rejects any non-https URL before it ever tests the entry's match patterns, so a plain http call is short-circuited out of certificate selection no matter how well the patterns fit.
solid answer
~40 s`Certificate.canApplyTo(url)` in the Postman SDK answers one question — may this entry be used for this call — and it runs two tests in a fixed order. First the **scheme**: anything other than `https` returns `false` immediately. Only then does it consult the entry's `matches` patterns for the host and path. Because the first test short-circuits, the second is never reached for an `http://` URL, so an entry whose patterns are perfectly written still contributes nothing. That is why the classic symptom — a certificate configured, saved and visibly correct, yet never sent — is so often just a scheme problem. The fix is the URL, not the patterns: no amount of broadening `matches`, reordering the list or renaming the entry can make it apply while the target is plain `http`.
code
javascript · 11 linesconst { Certificate } = require('postman-collection');
const entry = new Certificate({
name: 'internal-api',
matches: ['https://api.internal.example/*'],
key: { src: '/etc/pki/client.key' },
cert: { src: '/etc/pki/client.crt' }
});
entry.canApplyTo('http://api.internal.example/orders'); // false
entry.canApplyTo('https://api.internal.example/orders'); // truego deeper
Remember that a client certificate is only ever attached to an https call. An http URL gets none, however carefully the entry was configured.
Explain the order inside Certificate.canApplyTo: the non-https rejection happens first and short-circuits, so the matches patterns are never evaluated at all for an http URL.
Diagnose from the URL that was actually sent rather than the saved request text, and recognise that editing patterns cannot fix what is really a scheme problem.
Decide where plain-http targets are allowed to exist at all, since any such target silently drops client identity no matter how the certificate list is configured.
## Two tests, and the order is the whole answer `Certificate.canApplyTo(url)` is the Postman SDK's answer to a single question: may this saved entry be used for this call? It performs two tests, in a fixed order. 1. **Protocol.** If the URL's scheme is anything other than `https`, the method returns `false` **immediately**. 2. **Patterns.** Only if the first test passed does it consult the entry's `matches` list to decide whether this host and path are covered. Because the first test short-circuits, the second is never reached for an `http://` URL. That is the mechanical reason a certificate which is configured, saved and visibly correct is never presented: the entry was excluded before its patterns were ever looked at. ## Why the scheme check comes first A client certificate is material a caller offers inside a protected connection. A plain `http://` request has nowhere to put it, so an entry that would otherwise match such a URL has nothing to contribute, and the SDK declines before spending any work on pattern matching. What the two ends then agree with each other is a different subject; this mechanism stops at selection. ## The table an interviewer wants you to draw | Target URL | Covered by `matches` | `canApplyTo` | Certificate presented | |---|---|---|---| | `https://api.example.com/orders` | yes | `true` | yes | | `http://api.example.com/orders` | yes | `false` | no | | `https://other.example.net/orders` | no | `false` | no | | `http://localhost/orders` | yes, by a broad pattern | `false` | no | The second row is the one people get wrong. Nothing about the entry is defective; the URL disqualified it before the entry was examined. ## How an http URL shows up when nobody intended one - A **local or staging target** was stood up on plain `http`, and the same entry is expected to cover it. - The URL is assembled from a **placeholder that expands to an `http://` prefix**, so the scheme is not visible in the saved request text. - Someone wrote the **pattern** with `https` but left the **request** on `http`, and reads the pattern as if it forced the scheme. It does not: `matches` is consulted only after the scheme test has already passed. - The host answers on **both** schemes, so the call succeeds and returns data — which hides the fact that no certificate went with it. ## Diagnosing and fixing it 1. Read the **scheme of the URL that was actually sent**, not the one saved in the request, since it may have been assembled from placeholders. 2. If it is `http`, stop: no change to `matches`, no reordering and no renaming will help. The entry cannot apply, by construction. 3. Move the target to `https` — then, and only then, are the `matches` patterns evaluated and the rest of selection proceeds. 4. If the URL is already `https` and still nothing is presented, the cause is elsewhere: the patterns do not cover this host, an earlier entry in the list matched first, or the key and certificate files did not resolve. ## The mental model to keep Think of `canApplyTo` as a gate with two doors in series, not as a scoring function. The first door asks about the transport; the second asks about the address. A candidate who describes it as 'the patterns decide' will be surprised the first time an `http` call goes out bare, and will spend the whole debugging session editing patterns that were never consulted. The compact statement is: **a non-`https` URL is rejected before `matches` is ever tested.** ## Boundaries worth naming in the answer - This is about **which entry may apply**, not about whether validation should ever be relaxed — that judgement is a separate discipline and does not belong in this answer. - It is also not about how a terminal-driven run receives such files; the mechanism here is the SDK's selection rule alone. - And it is not about what the far end does with an identity once it has been presented. Stated in one line for an interview: **the scheme test precedes the pattern test and short-circuits it, so an `http` URL can never select a client certificate.**
- The patterns on the entry already specify https. Doesn't that make the scheme test redundant?No. The scheme test runs first and short-circuits, so for an `http` URL the patterns are never consulted at all. The pattern's own scheme only matters once `canApplyTo` has already accepted the URL as `https`, and it is checked against the host and path from there.
- The URL is already https and the entry still never applies. What is left to check?Two things: whether the entry's `matches` patterns actually cover this host and path, and whether an earlier entry in the `CertificateList` matched first, since `resolveOne` stops at the first hit. If the entry does win, the remaining cause is `key.src` or `cert.src` failing to read, which only warns.
saying these in an interview costs you the question
- Says the matches patterns decide, ignoring the scheme test
- Edits patterns to fix a certificate missing on an http call
- Thinks an https pattern forces the request to use https
- Believes the certificate is selected then dropped later
- Assumes a local http target is exempt from the rule