Can NetPeek trust the certificate automatically?
No. iOS requires you to install the profile and explicitly enable full trust in Settings; NetPeek cannot do that for you.
Manual
HTTPS Inspection on iOS: Install & Trust the NetPeek CA
To inspect HTTPS plaintext on iPhone you must manually install and fully trust the NetPeek on-device CA; only hosts on the MITM list are decrypted. The CA is generated on the device and is not uploaded by NetPeek; iOS cannot trust it automatically. After install and full trust, add the target host to the MITM list and send a new request.
Install and trust
To read HTTPS content you must install and trust the CA certificate NetPeek generates on-device. You do this manually — iOS forces the step through Settings.
- After starting capture, open http://127.0.0.1:8080 in a browser and download the CA profile.
- Install the profile under Settings → General → VPN & Device Management.
- Enable full trust for the NetPeek certificate under Settings → General → About → Certificate Trust Settings.
- Add the target host to the MITM host list.
- Send the request again; existing capture rows are not retroactively decrypted.
The certificate is only for on-device debugging and is never uploaded. Upstream certificate checks default to observe (fail-open): problems are recorded without breaking connectivity, so you can debug misconfigured servers.
MITM host list
For performance and stability, NetPeek only decrypts (MITM) the domains you specify; the rest pass through transparently. The list supports wildcards:
+host/ a bare host = decrypt that host;*= decrypt everything.-*host*= explicitly do not decrypt (blacklist, higher priority than wildcards).- Swipe a row → "Add MITM / Add MITM blacklist" to maintain it quickly.
The app's own backend (control-plane) domain is always forced direct, never decrypted, and never written to the capture database — a safety red line.
Why HTTPS is opaque by default
The whole point of HTTPS is that a party in the middle can't read it. Seeing plaintext means explicitly authorising NetPeek to be that party:
- NetPeek generates a CA on the device; the private key never leaves it and is never uploaded.
- iOS makes you install the profile by hand, then separately switch on full trust under Certificate Trust Settings — a step the system won't let an app do for you.
- Only the hosts you add to the MITM list are decrypted; everything else passes through untouched.
- Deleting the profile ends the ability to decrypt, immediately.
Common reasons plaintext still doesn't appear
- The certificate is installed but full trust was never enabled in Certificate Trust Settings — by far the most common cause.
- The host isn't in the MITM list.
- The app pins its certificate and rejects anything unexpected. That's it working as designed; use a build with pinning disabled.
- Traffic is on QUIC/HTTP3 — turn on Block QUIC in MITM options so it falls back to TCP.
Choosing an upstream certificate policy
- Off: skip upstream validation. Most permissive, useful against internal servers with irregular certificates.
- Observe: validate and record problems without interrupting the capture — the recommended default.
- Enforce: block connections whose upstream certificate isn't trusted; self-signed and enterprise-CA sites will fail.
FAQ
Is the CA certificate uploaded?
No. It is generated on the device; the private key never leaves the phone and is used only for the HTTPS debugging you enable.
Why is HTTPS still not readable after trust is enabled?
Common causes: full trust not enabled in Certificate Trust Settings, host missing from the MITM list, SSL pinning (use a debug build with pinning disabled), or QUIC/HTTP3 (enable Block QUIC in MITM options to fall back to TCP). After adding a host, send a new request — existing rows are not retroactively decrypted.