The client does not trust the proxy's certificate

[JamesPierce82]

As stated in the Topic, I am receiving an error for a specific domain stating:
"Client TLS handshake failed. The client does not trust the proxy's certificate for DOMAIN (tlsvs1 alert unkown ca)".

This error only appears to occur on specific domains for the app it is being generated from. Is this an example of Certificate pinning? Or have I perhaps configured something wrong along the way?

Looking for some direction on how to resolve the error as the data I am hunting seems to be being sent when that error is triggering.

[mhils]

Yes, this very much looks like certificate pinning. The client actively communicates with a TLS alert that it does not trust the cert.

If you're on Android and it's your own application, you need to add user-added CAs to your network configuration manifest.

[JamesPierce82]

ah, that's what I was worried about. Thank you very much for the quick reply!

Unfortunately as the app I am working with is not my own, It looks like I will need to attempt some additional work using apk-mitm or objection as suggested in the Certificates documentation.

Disappointing that i need to do more work, but exciting to be so close! By chance do you have any recommendations or suggestions on any "gatchas" to avoid during this next part?

[jorcelinojunior]

Have you made any progress? I'm having the same problem on android :(

[kevin0t]

Maybe Try running the app on an emulator with Android 7 or below or use root on it. By root method you could use magisk modules like lsposed -sslunpinning or JustTrustMe.

[ZaptorZap]

Something loosely related, but I was curious to peek into traffic coming from the Nintendo Switch instead. Ran into the same issue as the title, although admittedly, I didn't and certainly couldn't install any CA certificates. The connection test succeeded though, and I could peer into the HTTP GET that makes: address and all. All I've done was enable proxying on the Switch's internet settings and set the host as my computer. No homebrew involved here.

I escalated to trying to transparently proxy, but I just keep running into #3139 despite the fact that my machine (Debian Bullseye running ./mitmproxy) shouldn't even be proxying. mitmproxy quickly runs out of leeway and throws exceptions relating to too many open files, and the Switch fails at even testing its own connection. Really unsure of why this is happening. I'm quick to blame the iptables listed on the docs, but I'll admit I have zero expertise in what I'm doing here.

[jidanni]

When making such messages, the app should be as helpful as possible.

The client does not trust the proxy's certificate

Which client. Be specific.

Which proxy. Be specific.

Note the app might be running under several layers of other apps. So be sure it says clearly what things it is talking about.

[selfstduy]

How to solve the hot problem

[bengabp]

pls how to solve this issue, im still getting the same message for linkedin for youtube

[strarsis]

The client must trust the CA cert used by mitmproxy, so you have to add the CA cert to the client trust store (Note: Firefox uses its own by default, independent from system store, there is an option to make it (also) use the system trust store, btw.).

Also note that when mitmproxy is run as root (for using privileged ports as 443/80), the initially, by default automatically generated CA certificates are not those in the normal user folder (when mitproxy was previously ran as normal user), but in root home directory (/root/), and those are randomly generated, so for root those differ to normal user.