Trust the CA

Install the proxy's certificate so HTTPS can be decrypted on the client.

For the proxy to decrypt HTTPS, the client has to trust the certificate it presents. That means installing the proxy's certificate authority (CA) as a trusted root on the client's OS or browser.

Why this is needed

When the proxy decrypts an HTTPS host, it presents the client a certificate it signed itself, on the fly. The client only accepts that certificate if it already trusts the CA that signed it. So trusting the CA once is what lets every decrypted host validate — without it, the client throws certificate errors and HTTPS won't open.

The CA is self-signed and generated by the proxy on first run. Per-host leaf certificates are minted on demand and cached, but they all chain back to this one root, so you only ever trust one thing.

Heads up: The CA's private key lets its holder impersonate any HTTPS site to a client that trusts it. Only install it on clients you control and are actively debugging, and remove the trust when you're done.

Get the CA

iOS / iPadOS

  1. Open https://busymate.net/ca.mobileconfig in Safari and install the profile when prompted.
  2. Settings → General → VPN & Device Management → install the downloaded profile.
  3. Settings → General → About → Certificate Trust Settings → enable full trust for the Busymate root.

Both steps matter — installing the profile isn't enough on its own; the trust toggle is what allows decryption.

macOS

Fetch the PEM and add it to the keychain as a trusted root:

bash
curl -o busymate-ca.pem https://busymate.net/ca.pem
security add-trusted-cert -d -r trustRoot \
  -k ~/Library/Keychains/login.keychain-db busymate-ca.pem

If you're running a local instance, the proxy logs at boot whether its CA is already trusted on the Mac and prints the command to run if not.

Android

  1. Download the PEM from https://busymate.net/ca.pem.
  2. Settings → Security → Encryption & credentials → Install a certificate → CA certificate, and pick the downloaded file.

Note: Modern Android only trusts user-installed CAs for app traffic if the app opts in. System browsers and curl-style clients honour it; many apps don't, by design.

Other clients (raw bundle)

Development tools can fetch the CA programmatically. GET /ca/bundle returns the CA certificate and private key as JSON:

bash
curl -u "<cert-bundle-user>:<cert-bundle-pass>" \
  https://proxy.busymate.net/ca/bundle
json
{ "certPem": "-----BEGIN CERTIFICATE-----\n...", "keyPem": "-----BEGIN PRIVATE KEY-----\n..." }

Because this returns the private key, the endpoint is password-protected and every fetch is logged. Use the plain PEM at /ca.pem if you only need the public certificate.

Hosts that never decrypt

Some hosts are deliberately never intercepted, no matter what your SSL-proxy settings say — they're certificate-pinned and would break if MITM'd:

  • Apple PKI — pkis.apple.com, ocsp*.apple.com, crl*.apple.com, valid.apple.com, ppq.apple.com
  • The DigiCert OCSP / CRL responders Apple's chain uses
  • Anything under *.busymate.net (the team's own Supabase-backed backends)

These pass through as raw tunnels so certificate pinning and the dashboard's own Realtime connection keep working. This is intentional and not a misconfiguration.

Next

Connect a clientWhat gets decrypted