Why You Need a CA Certificate
HTTPS exists so nobody between your device and the origin server can read or tamper with the bytes flowing across the wire. That includes Probe.
If you start Probe and point your phone at it without installing the CA certificate, the traffic list still fills up — but every HTTPS request shows a CONNECT host:443 line and nothing else. No headers, no JSON body, no response. You see the TLS handshake happen and then an opaque encrypted tunnel.
To actually inspect HTTPS, Probe has to terminate the TLS connection on your device, look at the plaintext, then re-encrypt and forward to the origin. That’s a man-in-the-middle, and the only reason your client allows it is because you told the device’s trust store: “any certificate signed by this Probe CA is fine.”
How Probe’s MITM works
Section titled “How Probe’s MITM works”When you install Probe, it generates a unique CA on your machine the first time it runs. The CA’s private key lives in ~/.probe/probe_ca/ (macOS) or %USERPROFILE%\.probe\probe_ca\ (Windows) and never leaves that directory.
Each time a client opens an HTTPS connection through the proxy:
- Probe sees the
CONNECT api.example.com:443request. - It mints a fresh leaf certificate for
api.example.com, signed by your local CA. The leaf carries the right SAN entries and is valid for that hostname only. - Your client checks the leaf’s chain, finds your Probe CA in its trust store, and accepts the handshake.
- Probe decrypts the request, shows it in the Detail panel, then opens its own TLS connection to the real origin and forwards the bytes.
- The response makes the trip back the same way.
You see plaintext on both sides. The origin still gets a real, verified TLS connection from Probe. Neither end notices anything unusual unless the client pins certificates (see HTTPS Interception for that case).
Is this safe?
Section titled “Is this safe?”Trusting Probe’s CA gives the Probe app running on your machine the ability to forge certificates for any hostname — but only for clients on devices where you explicitly installed the CA. The CA private key is generated locally and never transmitted anywhere. If you want to confirm, look in the data directory: it’s a regular file on disk owned by your user account.
What you should not do:
- Don’t share your
probe_cadirectory with anyone else. - Don’t install someone else’s Probe CA on your device unless you trust them with your traffic.
- Uninstall the CA from a device the moment you stop using Probe on it (especially on phones you lend out or wipe).
When you’re done debugging, removing the CA from the device’s trust store immediately ends Probe’s ability to intercept future HTTPS connections from that client.
The CA download page
Section titled “The CA download page”Probe runs a tiny HTTP server on port 9098 specifically for serving the CA certificate. From any device on the same network, open:
http://<your-mac-ip>:9098You’ll get a landing page that auto-detects the visiting device and offers the right format:
- iOS / iPadOS → mobileconfig profile with the PEM CA
- Android → DER-encoded
.cer(Android won’t accept PEM through the system installer) - macOS → PEM
.pemfor Keychain - Windows → PEM
.pemfor the Windows certificate store
Direct URLs are also exposed if you need to script the download:
| Path | Format | For |
|---|---|---|
/download/ios | mobileconfig | iPhone, iPad |
/download/android | DER (.cer) | Android phones, tablets |
/download/macos | PEM (.pem) | macOS Keychain |
/download/cert.pem | PEM | Anything that wants PEM |
/download/cert.der | DER | Anything that wants DER |
The CA server stays up as long as Probe is running. If your phone can reach http://<your-mac-ip>:9098 in a browser, you can install the cert.
Check installation status
Section titled “Check installation status”Probe reads the host’s trust store directly to tell whether the CA is currently trusted, so you don’t have to guess.
- macOS — Probe queries the System and Login keychains for any certificate whose subject matches
Probe(coversProbe Root CAand the legacyGuide MITM ProxyCA from earlier builds). - Windows — Probe queries the per-user and machine-wide Trusted Root Certification Authorities stores.
Where the result is surfaced:
- The first-launch Welcome dialog only appears when the CA is not trusted. If it’s already trusted (e.g. you reinstalled Probe but the cert from a previous install is still in the keychain), the dialog is skipped silently.
- An in-app banner warns you when traffic is flowing but the CA isn’t trusted, so a forgotten install doesn’t waste a debug session.
If you’ve just installed the cert and traffic is still showing up as opaque CONNECT lines, the checker is the fastest way to confirm the OS sees what you installed. A negative result usually means the cert went into the wrong store (user instead of machine on Windows, login instead of system on macOS) — re-install following the per-platform guide below.
What “trust” really means
Section titled “What “trust” really means”Adding the certificate to a device’s keychain or certificate store is not the whole job on every platform. iOS specifically requires a second step: you install the profile in Settings, then enable trust under Certificate Trust Settings. Android distinguishes between the user store (which most apps ignore by default) and the system store (root-only). Windows defaults to per-user trust unless you run elevated.
Pick your platform below for the exact procedure. Each page ends with a quick “verify it works” check so you know HTTPS interception is actually live.