HTTPS Decryption Issues
First, rule out plain cert-trust
Most “HTTPS doesn’t work” reports are actually the CA not being trusted yet — check Certificate Problems before anything below.
Certificate pinning
If the CA is properly trusted but one specific app still fails TLS while everything else works, that app is almost certainly pinning certificates — checking the server’s exact certificate (or public key) instead of trusting anything signed by a trusted CA. This is a deliberate anti-MITM defense, and it means TonyProxy (or any proxy inspector) fundamentally cannot decrypt that app’s traffic without modifying the app itself.
- For an app you built: temporarily disable pinning in debug builds, or add an explicit exception for TonyProxy’s CA.
- For a third-party app: there’s generally no supported workaround. Some reverse-engineering communities publish pinning-bypass patches for specific apps, but that’s outside what TonyProxy itself can do.
App Transport Security (ATS) on iOS
ATS blocks weak/legacy TLS configurations by default. This is unrelated to TonyProxy’s CA trust — if a request fails specifically with an ATS-style error (not a cert-trust error), it’s the app’s own Info.plist ATS exceptions, not something TonyProxy controls.
TLS handshake errors even with the CA trusted
- Confirm you trusted the CA for the correct TonyProxy environment (Dev/Sandbox/Production each mint their own — see Certificate Problems).
- Some networking libraries (older Java, some embedded/IoT stacks) use a bundled trust store instead of the OS one — the OS-level trust step won’t reach them.
- Check the JA3 fingerprint and TLS version shown in the transaction detail (if visible) for clues about which TLS stack the client is using — unusual stacks are more likely to need library-specific configuration rather than OS-level trust.