Recording Web Traffic, HTTP(S) Test Script Recorder, and Certificate Setup: Core Concepts and Mental Model
Chapter 12 showed why a raw request list is not yet a workload: business grouping, loops, branches, state, data ownership, and transaction reporting must be explicit. The HTTP(S) Test Script Recorder can accelerate discovery of browser traffic, but its output is a rough draft. This chapter teaches the trust boundary and cleanup discipline needed to turn that draft into a small, correlated JMeter plan.
Learning objectives
- Explain the browser → JMeter recorder proxy → authorized target path.
- Understand why HTTPS interception requires a temporary JMeter CA trusted by the browser.
- Distinguish captured requests from designed virtual-user workload.
- Inventory filters, cookies/tokens, proxy settings, trust state, and recorded JMX before changing anything.
- Explain why raw browser concurrency/assets must not be replayed blindly.
- Define the cleanup path from raw capture to reviewed, parameterized, correlated JMX.
1. The practical problem: browser traffic is noisy and stateful
A browser navigation can create HTML requests, CSS/JavaScript/image requests, redirects, preloads, telemetry calls, cookies, and dynamic form values. A recorder sees the traffic that crosses its proxy; it cannot know which requests represent the business transaction, which token must be correlated, which values are secrets, or what concurrency/rate the production workload should use.
Therefore the recorder solves request discovery, not workload design.
localhost:8080 or
localhost:8443. Do not point the recorder at
production, public sites, corporate SSO, personal accounts, real
email, chat, banking, password managers, update services, or
unrelated browser tabs.
2. Mental model: recording is an authoring-only interception path
Recording sits only in the authoring path. The cleaned JMX is the load-test artifact; the browser proxy and temporary CA are removed before meaningful replay.
flowchart TD P[Disposable Firefox profile] -->|proxy 127.0.0.1:8888| R[JMeter HTTP(S) Test Script Recorder] CA[Temporary JMeter recorder CA<br/>trusted only in this profile] --> P R -->|HTTP/HTTPS request| T[Authorized localhost fixture] T -->|response| R R --> C[Captured HTTP Request samplers] F[Include / exclude filters] --> C C --> RAW[Immutable raw recording] RAW --> CLEAN[Filter + defaults + cookie manager + correlation + parameterization] CLEAN --> JMX[Reviewed JMX] JMX --> CLI[Bounded non-GUI replay] CLI --> E[JTL + jmeter.log + target evidence]
The disposable Firefox profile routes only this lab's browser traffic to the recorder. For HTTPS, that profile temporarily trusts JMeter's recorder root CA so JMeter can terminate the browser-side TLS connection and create a second TLS connection to the authorized target. The recorder stores matching requests as HTTP Request samplers. After recording stops, the trust is removed. The raw JMX is preserved as evidence; a copy is cleaned into the actual load-test plan.
3. What the temporary CA changes
JMeter generates dynamic server certificates signed by a JMeter-created root CA. Once a browser trusts that root CA, it will accept certificates generated by that CA for the intercepted hosts until the CA expires or trust is removed. Current JMeter defaults the recorder certificate validity to seven days.
This is deliberately powerful man-in-the-middle capability. In this course the CA is imported only into a disposable Firefox profile and the profile is deleted after recording. Do not install it into Windows/macOS/Linux system trust, organization-managed browser trust, or your normal browsing profile.
4. Two certificate roles in the lab
| Certificate/keystore | Purpose | Who trusts it? |
|---|---|---|
Fixture fixture.p12 |
Makes the local Java target serve HTTPS on 8443. | JMeter outbound HTTP client accepts the synthetic test server certificate; browser does not import it. |
ApacheJMeterTemporaryRootCA.crt +
proxyserver.jks
|
Lets recorder impersonate localhost to the proxied browser for authoring. | Only the disposable Firefox profile temporarily trusts the exported recorder CA. |
Do not confuse the fixture's server identity with the recorder CA. Deleting browser trust for the recorder CA does not stop the fixture, and deleting the fixture keystore does not remove recorder trust from a browser.
5. Recorder proxy versus JMeter outbound proxy settings
The HTTP(S) Test Script Recorder is JMeter's built-in proxy used for
capturing browser sessions. JMeter's -H/-P or
HTTP Request Defaults proxy settings are instead used when JMeter
itself must route outbound replay through an upstream proxy. They
are different layers.
For this loopback lab no upstream proxy is required.
6. Include/exclude filters decide what is stored
Recorder URL patterns are regular expressions matched against the full host+port+path+query string. If Include patterns exist, at least one must match. If an Exclude matches, the sampler is not stored. The browser request still passes through the recorder proxy; filtering is about capture storage, not network blocking.
For this lab:
Include: localhost:8443/.*
Exclude: .*\.(?i:css|js|png|gif|svg|ico)(\?.*)?
This keeps the business /begin and
/finish calls while dropping the synthetic static
assets.
8. Captured dynamic values must be correlated
The local /begin response emits dynamic hidden form
values flow_id and csrf. The browser POST
naturally sends the captured values, so raw recording will contain
literal values such as FLOW-00001. Replay must instead
extract the values from each user's fresh
/begin response and submit
${FLOW_ID}/${CSRF_TOKEN}.
This reuses Chapters 9–10: response → extractor → thread-local variable → downstream request.
9. Browser embedded resources do not define your business workload
Static assets can be relevant to page-delivery testing, but replaying every captured CSS/JS/image request as independent business samplers often creates noise and unrealistic browser behavior. JMeter is not a JavaScript-capable real browser.
Decide separately whether the performance question is API/business-call capacity, page resource delivery, CDN behavior, or end-user browser performance. This chapter's cleaned plan measures two application transactions, not asset delivery.
10. Captured concurrency is not desired workload concurrency
A browser may open concurrent connections for resources. Recorder grouping or sample arrival timing describes one authoring session, not a production arrival model. Do not convert “the browser opened six connections” into “the load test needs six users” or “six requests per second.” Workload concurrency/rate still comes from Chapters 4 and 7.
11. State to inventory before recording
| State | Read-only question |
|---|---|
| Generator | JMeter/Java versions; keytool available; recorder port free? |
| Browser profile | Dedicated profile directory? Existing cookies/logins/extensions disabled? |
| Proxy | HTTP and HTTPS proxy set to 127.0.0.1:8888? Is localhost bypass cleared? |
| Trust | Is JMeter recorder CA absent before start? Where will it be imported? |
| Recorder scope | Target controller, Include/Exclude patterns, grouping, embedded-resource setting? |
| Target | Exactly localhost:8080/8443 and synthetic fixture only? |
| Captured state | Any Authorization/Cookie/token/email/real host strings in raw JMX? |
| Refactored state | HTTP Request Defaults, Cookie Manager, correlation extractors, transactions, assertions? |
| Results | Raw recording, clean diff, JTL, jmeter.log, target event log? |
| Validity | Does clean replay use designed threads/loops/timers rather than captured browser timing? |
12. Non-destructive inspection first
-
Check
java -version,javac -version, andkeytool -helpbefore recorder startup. - Check whether port 8888 is already listening.
- Inspect the disposable profile's certificate authorities before import.
- Record the exact certificate fingerprint/details shown by JMeter before trusting it.
- Inspect Include/Exclude patterns before opening the browser.
- After capture, save the raw JMX read-only before refactoring.
- Run a secret/host scan on both raw and cleaned plans.
13. DevOps connection
Recording is analogous to generating a scaffold: it shortens discovery, but the artifact still needs code-review discipline. A production-quality JMX has explicit target defaults, state handling, data ownership, correlation, transaction boundaries, workload parameters, privacy review, and reproducible CLI evidence.
Knowledge check
What problem does the recorder primarily solve?
It discovers/captures HTTP(S) requests from an authoring browser session; it does not design the final workload.
Why is the recorder CA a sensitive security boundary?
A browser that trusts it will accept certificates signed by that CA, enabling interception by anyone who controls the corresponding recorder key material.
Do Exclude patterns block the browser request from reaching the target?
No. They prevent matching requests from being stored as recorded samplers; the proxied traffic still passes through.
Why must a cleaned replay plan add HTTP Cookie Manager?
The browser handled cookies during recording, but JMeter virtual users need their own cookie handling during replay.
Why shouldn't recorded asset concurrency determine virtual-user concurrency?
Browser connection behavior from one capture is not the production workload model; user/arrival concurrency must be designed from workload requirements.
Official references and version notes
- Component Reference — HTTP(S) Test Script Recorder — proxy, filtering, recording controller, certificate generation, CA trust, cookies, redirects, and UDV replacement.
- HTTP(S) Test Script Recorder tutorial — current recording-template workflow and browser proxy setup.
- Getting Started — Java/JDK requirement, keytool note for HTTPS recording, GUI/CLI conventions, and JMeter HTTP certificate behavior.
- Properties Reference — recorder and certificate properties such as proxy.cert.validity, proxy.ssl.protocol, proxy.pause, and redirect handling.
- Best Practices — using the recorder for rough drafts, variable replacement, and checking proxy routing.
- Apache JMeter downloads — current stable release and Java requirement.
Version-sensitive statements were rechecked against current Apache
JMeter primary documentation on 2026-09-05. The course baseline
remains Apache JMeter 5.6.3 with a Java 17 JDK
and no third-party JMeter plugins; JMeter 5.6.3 requires Java 8+.
A JDK is preferred here because HTTPS recording needs the
keytool utility. HTTP(S) Test Script Recorder is a
local HTTP/HTTPS proxy, default port 8888.
Include/Exclude patterns are regular expressions evaluated against
the full host/port/path/query string; requests still pass through
the proxy even when a filter prevents them from being stored. With
Java 8+ dynamic certificate mode, JMeter generates per-host
certificates signed by its temporary root CA; the default recorder
certificate validity is 7 days via
proxy.cert.validity. The exported
ApacheJMeterTemporaryRootCA.crt is created when
recorder certificates are generated and must be removed from
browser trust after use. Anyone who can access the recorder
keystore/private-key material while a browser trusts that CA has a
powerful interception capability, so the mandatory lab imports it
only into a disposable Firefox profile. During recording, the
browser manages cookies; the cleaned JMeter replay plan needs an
HTTP Cookie Manager. JMeter's HTTP samplers accept server
certificates broadly for test flexibility, so the synthetic
localhost target can use its own short-lived self-signed fixture
certificate without importing that target certificate into the
browser or OS trust store.
Keep the academy open
Support free, practical DevOps education.
Every lesson is designed to remain readable in a browser, downloadable from GitHub, and usable without a paid learning platform. Contributions help expand and maintain the curriculum.
0x716c4Ab160C4B66F31a28AE2448BfF68fc3a2ef0
Send only Ethereum/ERC-20 compatible assets to this
address.