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 Root CA is fine."

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 ~/Library/Application Support/probe_ca/ (macOS) or %LOCALAPPDATA%\Probe\probe_ca\ (Windows) and never leaves that directory.

Each time a client opens an HTTPS connection through the proxy:

1. Probe sees the CONNECT api.example.com:443 request.
2. 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.
3. Your client checks the leaf's chain, finds your Probe Root CA in its trust store, and accepts the handshake.
4. Probe decrypts the request, shows it in the Detail panel, then opens its own TLS connection to the real origin and forwards the bytes.
5. 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).

Pinned apps still won't decrypt

Even with the Probe Root CA installed and trusted, some apps refuse to accept any certificate outside their own bundled list. Probe surfaces these automatically — see Pinning Detection.

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 that directory: the key is a regular file on disk owned by your user account.

What you should not do:

• Don't share your probe_ca directory with anyone else.
• Don't install someone else's Probe Root 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.

Each device needs its own install

Installing the CA on your Mac trusts traffic from apps running on the Mac. It does not cover your iPhone, even if both are on the same Wi-Fi. Every device whose traffic you want to inspect needs the CA installed on that device's trust store.

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>:9098

You'll get a landing page that auto-detects the visiting device and offers the right format:

• iOS / iPadOS → a signed .mobileconfig profile containing the CA
• Android → a DER-encoded .der file (Android won't accept PEM through the system installer)
• macOS → a PEM certificate as a .crt file, for Keychain
• Windows → a PEM certificate as a .crt file, for the Windows certificate store

Direct URLs are also exposed if you need to script the download:

Path	Format	For
/download/ios	.mobileconfig profile	iPhone, iPad
/download/android	DER (.der)	Android phones, tablets
/download/macos	PEM (.crt)	macOS Keychain
/download/cert.pem	PEM (.crt)	Anything that wants PEM
/download/cert.der	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.

Tip

The IP address Probe expects you to use is shown in the toolbar status card next to the Start/Stop button. It's the LAN address phones can route to — not 127.0.0.1, which only works for the host itself.

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 a certificate whose subject starts with Probe Root CA (.
• 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.

Upgrading from an older build

A CA made by an older Probe build (any name other than Probe Root CA) is replaced automatically: on the first launch after updating, Probe generates a new Probe Root CA and retires the old one (its private key is deleted). That means one reinstall on every device:

• This Mac / PC — use Install & Trust in the Setup Guide. The in-app install also removes the older Probe certificate from the System keychain (macOS) or your Trusted Root store (Windows).
• Phones and simulators — delete the older Probe profile or certificate, then install the new one from the Setup Guide or http://<host-ip>:9098/.

After that one reinstall the CA stays the same across updates.

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

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.

Install on your device

macOSAdd to Keychain Access and set Always Trust.

WindowsInstall into Trusted Root Certification Authorities.

iOS / iPadOSInstall the profile, then enable trust in Settings.

AndroidUser store, system store, and Network Security Config.

Next steps

HTTPS InterceptionDeeper dive on the proxy + TLS handshake.

Mobile SetupPoint a phone at Probe over Wi-Fi.