SSL & certificates

HTTPS is encrypted end‑to‑end. To inspect TLS payloads in ProxyHawk, you install a local Certificate Authority (CA) and selectively decrypt hosts you choose.

Proxy Hawk CA

ProxyHawk generates a self‑signed root CA (often labeled Proxy Hawk CA in Keychain). You export it from the app (PEM/DER) and trust it on:

Critical: Anyone who can use a machine that trusts this CA (or steal the CA private material) can perform TLS interception for traffic that trusts it. Remove the CA when you no longer need debugging. See Security & privacy.

SSL proxying modes

ProxyHawk supports two strategies (similar to other desktop proxies):

Mode Behavior
Decrypt only these hosts (recommended) Only hosts matching your patterns are MITM‑decrypted. Other HTTPS stays as a CONNECT tunnel (encrypted pass‑through). Safer for unrelated apps.
Decrypt all except… Broad decryption with explicit exclusions (e.g. streaming or banking hosts you add). Use when you mostly want full visibility.

You can add patterns from Settings → SSL proxying or from a traffic row (e.g. enable SSL proxying for this host).

Certificate pinning

Many mobile and desktop apps pin server certificates or public keys. If pinning is enforced, the client will refuse the connection when the proxy presents its MITM certificate—even if the Proxy Hawk CA is trusted at the OS level.

What you’ll see: Failed TLS, errors, or sentinel rows in the traffic list (e.g. SSL‑related status). This is expected for pinned apps; fixing it requires app‑side debug builds or disabling pinning in test environments—not something ProxyHawk can override safely.

Removing trust

When you finish testing: delete Proxy Hawk CA from Keychain / device trust settings, and remove any installed profiles. Rotate the CA in ProxyHawk if you suspect the private key could have been exposed.