Removing Certificate Pinning (Unpinning)
Some apps use certificate pinning: the certificate is installed and the proxy is running, yet the app stubbornly trusts only the certificate bundled inside it, and the moment it sees the proxy certificate it throws an error and refuses to connect. This article shows you how to select such an app and remove its certificate validation with one click, so that it trusts the proxy certificate again and HTTPS traffic can be decrypted normally.
1. When to Use This Capture Approach
Come to this step when any of the following happens:
- The certificate has been installed as described in Certificate Installation and the proxy is configured correctly, but a particular app simply can't get online / keeps reporting network errors.
- Every other app works fine, and only this one loses connectivity once the proxy is enabled — most likely because it uses certificate pinning.
- You want to capture this app, but it doesn't trust the proxy certificate, the handshake is cut short, and you can't even see the ciphertext in the request list.
The key distinction in one sentence: removing certificate pinning only makes the app willing to trust the proxy certificate; it doesn't perform decryption itself — the proxy still does that. If what you want is to pull plaintext directly out of the program's internals, that's a different matter — see Application-Layer Capture.
2. Prerequisites
- The proxy certificate is already installed and trusted — if not, see Certificate Installation first.
- A proxy session is already running: unpinning builds on proxy capture, so get other apps captured first, then deal with this stubborn one. See Proxy Capture.
- Prepare the corresponding environment for your target:
- Desktop programs: they can be listed and selected directly.
- iOS apps: the device is ready and the app is of a re-signable type; if you're unsure how to connect a device, see iOS Capture.
- Android apps: the device is rooted; for connecting the device and capturing, see Android Capture.
3. Step-by-Step
- Open the "Remove Certificate Pinning (Unpin)" panel and switch to the tab matching your target: Desktop Programs / iOS Apps / Android Apps.
- Select the target to process:
- Desktop programs: check them in the process list; you can filter by process name or PID, and multi-select is supported.
- iOS apps: pick the device first, then choose from the app list; you can also enter the bundle ID manually.
- Android apps: pick the device first, then choose from the app list; you can also enter the package name / process name / PID manually.
- Toggle the two switches as needed:
- Automatically handle child processes (desktop): in some applications, child processes are the ones sending and receiving network requests; enable this to handle them too and avoid missing traffic. It's recommended to keep it on for multi-process desktop apps.
- Restart target: restart the app once before processing, so that requests sent during its early startup are covered as well. Check this if you want to capture the few requests fired "the moment it opens".
- Click Start. The panel gives real-time feedback on the result: on success it tells you how many targets / processes were handled; if the app uses an uncommon networking component and isn't supported yet, it explicitly tells you instead of leaving you waiting.
4. Verification: Confirming It Now Yields Plaintext
Once processing is done, go back to the proxy session and have the app send a request again (refresh the page, re-enter a feature):
- The app that used to error out / lose connectivity now works normally: it no longer fails to connect as soon as the proxy is on.
- Its traffic now appears in the request list: request line, request headers, and body are all there.
- TLS shows "Decrypted": the response is readable plaintext (such as JSON), instead of the state where the handshake was cut short and nothing could be seen.
If the traffic shows up but the content is still ciphertext (not a rejected handshake, but something that can't be decrypted), that's usually not a certificate pinning problem; get the plaintext from inside the program instead — see Application-Layer Capture.
5. Can't Process It / Still Can't Connect? Check Item by Item
| Symptom | Most likely cause | What to do |
|---|---|---|
| The panel says this app isn't supported yet | It uses an uncommon networking component | Try a different approach and get plaintext from inside the program: switch to Application-Layer Capture |
| Processing succeeds, but only requests made after startup are captured; the first few are missed | The app had already been running for a while when you processed it | Check Restart target and process again to cover requests from early startup |
| A desktop app has been processed, but some traffic is still missing | Its network requests are sent by child processes | Turn on Automatically handle child processes and process again |
| Unpinning doesn't work for Go / Rust programs or desktop Java programs | Such programs usually don't need unpinning | They mostly read the system certificate store — just install the certificate into the system trust store; see Certificate Installation |
| iOS apps won't list / can't be selected | The device isn't connected properly, or the app isn't of a re-signable type | Prepare the device and environment as described in iOS Capture, or enter the bundle ID manually |
| Android apps won't list | The device isn't rooted | Prepare a rooted device as described in Android Capture |
Next Steps
- Now that decryption works, how to read these requests, switch views, and decode them: see Viewing and Decoding Data.
- The full workflow for capturing a specific app on iOS / Android: see iOS Capture and Android Capture.
- To get plaintext directly from inside the program (bypassing the certificate route): see Application-Layer Capture.
- For private / in-house protocols that you want the tool to recognize: see Custom Protocol Decoding.
Top comments (0)