skip to content

Traffic Capture

4 roadmaps11 questions

How this tool gets into the request path at all, and the separate machinery that decides which of the traffic it sees it may record or touch. Both are easy to get quietly wrong.

on this pageshow

explore

questions

11

What is the difference between ZAP's -certpubdump and -certfulldump, and which one does a browser need?

level: juniorimportance: must knowfreq 52%

answer

  1. two flags, and only one is safe
  2. one file is for trusting, one for being
  3. pub for the browser, full for ZAP
  4. the full dump appends a private key

basics

~20 s

-certpubdump writes ZAP's root CA certificate; -certfulldump writes that same certificate and then appends its private key. A browser needs the first. The second contains a secret, because the appended key is what signs certificates.

solid answer

~40 s

Both come from the `network` add-on, and both export the root certificate authority ZAP generated for itself. `-certpubdump` writes only the certificate; the option's own shipped help calls it *suitable for importing into browsers*. `-certfulldump` writes exactly the same PEM and then appends a `PRIVATE KEY` block, and its help says *suitable for importing into ZAP*. So the full dump is a strict superset of the public one, and the extra block is the signing key for the authority: whoever holds it can issue certificates that any machine trusting that root will accept. Hand a browser the public dump. Treat the full dump as a credential — the key is written in the clear, with no passphrase on it.

code

bash · 5 lines
bash
# For a browser: the certificate only
zap.sh -cmd -certpubdump /zap/wrk/zap_root_ca.cer

# For ZAP itself: certificate AND private key - treat as a secret
zap.sh -cmd -certfulldump /zap/wrk/zap_root_ca.key

go deeper

for a junior

Learn the pair by what each one is for: -certpubdump gives a browser something to trust, -certfulldump gives ZAP something to be. The second file holds a private key.

for a middle

Be able to say what is in each file: a certificate block in both, and an appended private-key block only in the full dump. That makes the full dump a strict superset, not a different format.

for a senior

Treat the full dump as a credential in your process: where it is written, who can read that path, and what happens to it after the run. Nothing warns you when the wrong file is shared, because the import still works.

for a principal

Decide the policy before anyone needs the file: which artifact gets published to people and machines that must trust the proxy, and what the handling rule is for the one that can sign as the authority.

## Two flags, one certificate, one secret ZAP intercepts HTTPS by generating a **root certificate authority** of its own and signing a certificate for each site you visit. Anything that is going to talk through the proxy has to trust that root, so the `network` add-on ships command-line options to export it. Two of them look interchangeable and are not: - **`-certpubdump <path>`** writes the root's **certificate** as PEM. Its shipped help text reads *"Dumps the Root CA public certificate into the specified file name, this is suitable for importing into browsers"*. - **`-certfulldump <path>`** writes the **certificate and the private key**. Its help text reads *"Dumps the Root CA full certificate (including the private key) into the specified file name, this is suitable for importing into ZAP"*. The project states the split itself, in the flags' own descriptions, and it is the cleanest statement of the difference: one file is for the thing that must *trust* the authority, the other is for the thing that must *be* the authority. ## What is actually in each file The relationship is not "less detail versus more detail". The full dump is written by first producing the public dump and then appending to the same file: | | `-certpubdump` | `-certfulldump` | |---|---|---| | `-----BEGIN CERTIFICATE-----` block | yes | yes | | `-----BEGIN PRIVATE KEY-----` block | no | yes, appended | | what it lets the holder do | verify certificates signed by the root | **sign new certificates as the root** | | its own help says | suitable for importing into browsers | suitable for importing into ZAP | So the full dump would also satisfy a browser — the certificate block is right there — which is exactly why the mistake is easy to make and easy to miss. Nothing fails. The browser finds what it needs, and a copy of the signing key has quietly travelled with it. ## Why the private key is the whole point A certificate is public by design; it is what you hand out so others can check a signature. The private key is the capability behind it. With the key, a holder can mint a certificate for any name, and a machine that was told to trust ZAP's root accepts it without complaint. That is the mechanism, and it is why the file needs handling as a credential rather than as configuration: - the key is written **unencrypted** — there is no passphrase on the exported block; - it lands wherever you pointed the flag, which in a container is usually a mounted working directory; - a shared build artifact, a log of the command, or a helpful "here is the CA, install this" message in a chat channel all move it somewhere you did not intend. ## Getting it right in practice 1. **Export the public dump for anything that has to trust ZAP** — a browser, a test client, a device under test. 2. **Export the full dump only when ZAP itself is the consumer**, which is the case the help text names, and keep it out of anything shared. 3. **Check what you actually attached** before handing a file to someone: open it and look for a `PRIVATE KEY` block. The filename tells you nothing; the blocks do. A related habit is worth forming: both flags are registered by the `network` add-on, not by core. Core still contains a deprecated certificate package that mentions the same three option names, so searching the core source for `-certfulldump` finds a hit and misleads you about where the capability lives. The class holding that hit is not in the program's built-in extension list, so it never runs; the live registration is the add-on's. ## The failure this prevents The common shape is a team that wants a colleague, a CI job or a device to trust the interception root, so somebody runs whichever dump flag they remember and shares the result. If that was the full dump, the signing key for an authority now sits in a place with a different audience from the one it was meant for — and because anything that trusts the root accepts what that key signs, it stays interesting to whoever finds it for exactly as long as the root is trusted anywhere. Nothing about the export is difficult; it is a single flag and a path. The part worth remembering is which of the two hands over a secret, and that the answer is not visible from the filename, the file size, or whether the import worked.

  • If the full dump also contains the certificate, why not always use it?
    Because everything that only needs to trust the root would then be handed the key that signs for it. The certificate block satisfies a browser either way, so nothing visibly fails — which is precisely why the wrong file travels unnoticed.
  • Which of the three certificate options reads a file rather than writing one?
    `-certload`, which imports a root into ZAP instead of exporting it. The two dump options only write, and the add-on carries on starting its listeners afterwards rather than exiting on the flag alone.
  • Does ZAP's root sign an intermediate certificate that also appears in the dump?
    No. The generator issues each site certificate directly from the root, so there is no intermediate to export. A dump contains one certificate, optionally followed by the private key — never a chain.

The public dump is a photograph of the seal, enough to check that a letter was sealed with it. The full dump is the seal itself — whoever has it can stamp anything.

saying these in an interview costs you the question

  • Thinks the two dump flags differ only in verbosity
  • Shares the full dump so a browser can trust ZAP
  • Assumes the public dump contains the private key too
  • Believes the exported private key is passphrase protected
  • Says the dumps come from ZAP core rather than an add-on
open as a page

In an OWASP ZAP context, what is an include or exclude regex actually matched against?

level: middleimportance: must knowfreq 62%

basics

~20 s

A full, case-insensitive match against the URL with everything from the first question mark onward removed. A prefix will not match because the pattern must describe the whole string, and a rule written against a query parameter can never fire.

open as a page

In an OWASP ZAP automation plan, what do a context's urls and includePaths entries become?

level: middleimportance: should knowfreq 46%

basics

~20 s

Both become include regexes on the context, but by different routes. Each urls entry is checked as a URI and then gets a wildcard appended; each includePaths entry is added exactly as written, so a bare URL there matches only itself.

open as a page

In OWASP ZAP, what decides whether a URL is in scope, and what has no say in it?

level: middleimportance: should knowfreq 54%

basics

~20 s

Contexts decide it, and nothing else does. A URL is in scope when some context with its in-scope flag set includes it and no in-scope context excludes it. Exclusion crosses context boundaries, and scope has no storage of its own.

open as a page

In OWASP ZAP, which component provides the local proxy listener a browser points at, and what stays in core?

level: middleimportance: should knowfreq 42%

basics

~20 s

The network add-on provides it. Its LocalServer class binds the configured address and port, and ExtensionNetwork registers the -host and -port arguments. Core keeps deprecated proxy classes plus four live listener interfaces so older add-ons still compile.

open as a page

In ZAP's network add-on, what does a local server's ServerMode control, and what is its default?

level: middleimportance: should knowfreq 33%

basics

~20 s

ServerMode says whether a listener serves the control API, the proxy, or both. It defaults to API_AND_PROXY, so one socket does both jobs and a client proxying through ZAP can reach the API at the zap domain.

open as a page

In OWASP ZAP, where can a URL be excluded, and which part of a run does each place affect?

level: seniorimportance: should knowfreq 48%

basics

~20 s

Three places: a context's exclude list, which subtracts from scope; the session's per-subsystem lists for the proxy, the active scan, the crawlers and websockets; and the network add-on's global exclusions, read by the proxy, the crawlers and the active scanner.

open as a page

Does the same exclusion regex behave identically in every OWASP ZAP layer that reads it?

level: seniorimportance: should knowfreq 41%

basics

~20 s

No. Only the full-match anchoring is shared. A context matches case-insensitively with the query already removed, the proxy handler and the crawler match the whole URI case-sensitively, and the active scanner matches that same shared list case-insensitively.

open as a page

What does a matching pass-through entry do to an HTTPS connection through ZAP's network add-on?

level: seniorimportance: should knowfreq 28%

basics

~20 s

It stops ZAP acting as a proxy for that connection. On a matching CONNECT, ZAP answers that the connection is established, clears its handler pipeline and relays raw bytes, so nothing downstream ever sees the traffic.

open as a page

A containerised ZAP mints a new root CA each run; which flag stops that, and what must the file hold?

level: seniorimportance: nice to knowfreq 24%

basics

~20 s

Load a stored root with -certload. The file must be a PEM holding both a CERTIFICATE section and a PRIVATE KEY section, so only a -certfulldump export can be loaded back — a -certpubdump export is rejected.

open as a page

How would you standardise where OWASP ZAP scope is declared across many unattended pipelines?

level: principalimportance: nice to knowfreq 30%

basics

~20 s

Put the boundary in the plan's context block. It is the only scope layer a plan can express, so the only one that lives in the repository and gets reviewed. Bound the exceptions, and say what it cannot express: a query-keyed rule.

open as a page