Where the refusal happens
OkHttp validates the peer certificate inside its own TLS layer. An app that pins adds a CertificatePinner to the client builder, and the pinner is consulted while the connection is still being established. If the presented chain does not satisfy the configured pin, the call fails with an SSLPeerUnverifiedException and no HTTP request is sent.
That timing is the important detail. A pinning rejection is a client-side decision about the connection, not a server-side decision about your request. Nothing you change in a header or a body affects it, because the object that would have carried those values was never created.
Two symptoms follow. The first is that the app works on a real device against the real domain and fails everywhere else, because the only certificate that satisfies the pin is the one the production server presents. The second is that the failure appears at connection time. A tool that reports a socket close during the handshake, with no HTTP status, is looking at the pin rather than at the API.
Tell a pin failure from its neighbours
Several failures look similar from a distance and need different responses.
- A pin rejection never produces a status line. The connection ends before a request is written, so any log that shows a parsed HTTP response rules pinning out for that attempt.
- A trust failure on an unknown issuer is not a pin. The default trust manager rejecting a private certificate authority produces its own exception and appears even in builds with no pinning code at all.
- An HTTP 401 or 403 means the connection succeeded. The handshake completed and the server processed a request, which places the problem in authentication or signature validation rather than in the transport layer.
- A timeout or a reset after the handshake has completed points elsewhere. Pinning is decided before the request is sent, so a failure that occurs while waiting for a response is not a pin failure.
- A cleartext or proxy policy refusal is a separate client rule. OkHttp and the Android network security configuration both enforce rules that have nothing to do with certificate identity.
Where the request is still visible
Pinning removes nothing from the request itself. It only restricts which peer the client will talk to. Once a connection is permitted, the full request passes through the OkHttp interceptor chain before the socket write, and a breakpoint or a hook at that layer sees the method, path, query, headers and body exactly as the app built them.
That is also the layer where a signature is computed, if the app signs its requests with an interceptor. The signing input is the assembled Request object, which exists independently of which certificate the client accepted. Reading it does not require the connection to succeed. An interception point placed before the write shows the signed material even when the transfer itself is refused.
For a different reason, the server side is also informative. The API receives requests from the genuine app all day, so the shape of a valid request is recoverable from the app's own traffic rather than from your attempts to reproduce it.
What the reconstruction has to account for
A client that will run outside the app cannot inherit the app's pin set, because the pin set names certificates presented by the production endpoint. What it can do is reproduce the request faithfully and let the caller decide how the connection should be trusted. Separating those two concerns is the point of the exercise, and it is why a pinned app is still a tractable extraction target.
The parts that need care are the ones the pinner sits next to. If the client builder also installs a custom trust manager, a client certificate or a connection spec, those settings describe how the app expects to reach the server and are worth recording. The connection spec in particular decides the protocol and cipher configuration, and a reconstruction that ignores it can produce requests that a server accepts while looking different at the transport layer. Android certificate pinning traffic analysis sets out how that study is carried out.
Record four things before leaving the transport layer: the pinned host list, the trust configuration, the connection spec, and the interceptor order. The first three describe the tunnel. The fourth describes how the request is assembled inside it, and OkHttp interceptor reverse engineering covers the chain in detail.
Related work
Reviewed 28 September 2026 · SReverse research desk