Android emulator is not able to trust Charles proxy certificate

Question

I'm following this tutorial to monitor the https traffic on an Android version 7 emulator.

One thing I found strange is that the certificate I download from chls.pro/ssl is different from the certificate I encountered when visiting a website through Charles proxy.

Here's the certificate I got from chls.pro/ssl

This certificate can be viewed from Setting -> Security -> Trusted credentials -> USER tab.

And here's the certificate I found when visiting any websites though Charles proxy:

As you can see from the pictures, their fingerprints are different.

This makes my Android emulator not able to trust the certificate when visiting a website through Charles proxy.

Why are the certificates different?

How can I view the https traffic on the Android emulator?

I'm using the latest Charles proxy, which is version 4.5.6.

============================= Edit ==================================

The security warning is caused by the browser on the emulator.

I originally used "Browser" version 7.1.2 to visit a website.

After I replace it with Chrome, the security warning no longer appears. And I'm able to view the https traffic between Chrome and the website.

But I still can't view the https traffic between the Android app and the server.

Here's the error message:

And here's my network_security_config.xml

<?xml version="1.0" encoding="utf-8"?>
<network-security-config>
    <base-config>
        <trust-anchors> 
            <!-- Trust user added CAs -->
            <certificates src="user" overridePins="true" />
        </trust-anchors> 
    </base-config>
</network-security-config>

============================= Edit ==================================

The apk file of the Android app is downloaded from google play.

Here's what I've done with the apk file

1. Get the apk file with Apk Extractor .

2. Use apktool d ${APK_FILE}.apk to extract the file.

3. Modify its network_security_config.xml and AndroidManifest.xml

4. Run apktool b ${APK_FILE} to restore the extracted files back to an apk file.

5. Run apksigner sign -ks my-key.keystore ${APK_FILE}/dist/${APK_FILE}.apk to sign the apk file.

6. Put the apk file to the Android emulator and install it.

I'm not sure if the above steps would cause the app not able to trust Charles certificate.

This is the original network_security_config.xml before I modify it.

<?xml version="1.0" encoding="utf-8"?>
<network-security-config>
    <base-config cleartextTrafficPermitted="true" />
    <domain-config cleartextTrafficPermitted="false">
        <domain includeSubdomains="true">appapi.appname.com</domain>
    </domain-config>
</network-security-config>

Answer 1

Why are the certificates different?

The first certificate shown there is Charles's 'certificate authority' (CA) certificate. It's self-signed (note how the 'Issued By' details are the same as the certificate's details), and doesn't apply to a specific domain.

The second certificate is a certificate for a website, issued by & signed by Charles's CA certificate, with a single specific domain as its subject (not shown), and which can be used to verify a connection to that specific domain.

The way that certificate trust works is that you trust a set of CA certificates, and whenever you receive a certificate you want to verify, you look at who issued that certificate, and see if you trust them based on the CAs you have (in some cases there are a few steps in the chain of trust, so you walk up it until you either find a certificate you trust or you get to the root and give up).

Does that make sense? In practice, Charles has generated one CA up front, which you need to trust, and then it generates new certificates on demand for each individual domain that needs one and signs them with its CA, and then you should trust those because you trust Charles.

How can I view the https traffic on the Android emulator?

The certificates shown aren't the cause of your problem, so it's hard to give any more details. There's some manual configuration required for Charles. Can you add any more information about what you've done, and the errors you're seeing?

If you're not wedded to Charles specifically, HTTP Toolkit might be helpful as an alternative approach. It's an open-source tool I've been working on, because Charles can be painful to setup like this. It's does all the same things, but the certificate setup is totally automated so you won't hit this problem.