Android: client certificates for servers behind an mTLS proxy

[Hirasawa69]

I access my T3 server through Caddy with client_auth { mode require_and_verify }. In my setup, desktop and mobile browsers work after installing a client certificate, but pairing in the Android app fails with “Transport error.” I’d like to use the native app with that same proxy requirement.

Related: #5639 and #3736. This proposal concerns presenting a client certificate, rather than trusting a private server CA or adding proxy headers.

Would you approve this direction and an Android-only initial scope?

• Choose an installed identity through Android’s system KeyChain picker after a failed pairing attempt when a TLS probe observes a certificate request, then retry pairing.
• Change or remove the selection in environment settings. Bindings apply to a host and port and are shared by environments using that address; only the alias is persisted.
• Support pairing and chat through React Native’s networking clients. Attachment uploads/downloads and video playback remain unsupported through the mTLS proxy in this prototype; iOS is outside the proposed scope.

I have an unpushed local prototype. It installs an Expo module into React Native’s OkHttp factory, with separate TLS contexts for bound origins, hostname verification during the handshake, and connection invalidation when a binding changes. Factory clients use no HTTP disk cache.

In my phone testing against Caddy, pairing, WebSocket chat, reconnect, and changing/removing the certificate worked. The prototype also includes unit tests for origin binding, rebinding races, and picker request handling.

I realize the contribution guide asks for agreement before implementation; this was a local experiment. I’ll wait for explicit direction and scope approval before opening a PR. Would this be useful, and should the initial scope be smaller?

(Drafted with Claude Code / Claude Opus 5.5.)

[nickypro]

I hit the same problem (nginx with ssl_verify_client optional and a basic-auth fallback, so the Android app gets a 401 before pairing starts) and have an implementation in my fork, rebased on today's main: compare view.

It takes the direction proposed above: Android's KeyChain picker, only the alias stored, scoped to the HTTPS host and port, an OkHttp socket factory installed in MainApplication before React Native and Expo create their clients, and existing connections closed when the choice changes. Server trust, hostname checks and pairing are unchanged. Two differences:

• The picker is in a collapsed Advanced settings section on Add environment and in the environment's Connections row, rather than appearing after a failed pairing attempt.
• It also covers chat attachments (upload, download, open) and video, which go through Expo FileSystem and Expo Video instead of React Native's OkHttp client.

Collapsed	Expanded

It's about 2k lines with tests (17 native TLS tests against MockWebServer, plus JS tests), so I'm happy to split it: transport and picker first (pairing and chat), media after. I can also fold it into @Hirasawa69's prototype. Would you approve this direction, and at which scope?

(Drafted with Claude Code / Claude Opus 5.5. The implementation was written with Codex / GPT-6 and rebased with Claude Code.)

[Hirasawa69]

Thanks, @nickypro — I tested a local Android build of your branch (f2b7aa02f4) on a physical phone against Caddy with require_and_verify.

Pairing, chat, image upload/view/download, video upload/playback/download, and reconnecting after a cold start passed. The test video played through to the end, and its original, server-side, and downloaded copies had matching SHA-256 hashes. Removing the certificate selection prevented connection; selecting it again restored it.

I'd be happy to consolidate on your implementation. Maintainers, would you approve this Android KeyChain direction, and should the initial PR cover pairing and chat only or include media too?

(Device checks performed via ADB and reply drafted with Codex / GPT-6 Astra in T3 Code.)

[nickypro]

Rebased onto today's main: compare view.

@Hirasawa69 has since run it on a physical phone against Caddy with require_and_verify. Pairing, chat, image and video upload/download/playback, reconnecting after a cold start, and removing and re-selecting the certificate all passed, and they're happy to consolidate on this branch.

Would you approve this direction? If so, I'll open a PR for pairing and chat first, with attachments and video as a follow-up, or as one PR if you prefer.

(Drafted with Claude Code / Claude Opus 5.5.)