Install Burp CA as Android System Certificate

One of the most common roadblocks in Android application security testing is HTTPS traffic that refuses to show up in Burp Suite, even after the CA certificate has been installed. This almost always comes down to where the certificate was installed. Since Android 7 (Nougat), apps targeting API level 24 or higher ignore user-installed certificates by default and only trust certificates in the system store.

This guide walks through installing Burp Suite's CA certificate directly into the Android system trust store, covering rooted physical devices, emulators, and the Magisk-based approach needed for newer Android versions with read-only system partitions.

Why User-Installed Certificates Are Not Enough

When you install a CA certificate through Android's Settings menu under "Install from storage," it gets placed in the user certificate store located at /data/misc/user/0/cacerts-added/. This store is only trusted by apps that explicitly opt in through their Network Security Configuration, and by default, apps built for API 24 and above do not trust it.

The system certificate store, located at /system/etc/security/cacerts/, is trusted by every app on the device regardless of Network Security Config settings, unless the developer has implemented explicit certificate pinning on top of it. This is why moving Burp's CA into the system store is the standard approach for reliable, broad traffic interception during an assessment.

Exporting the Burp Suite CA Certificate

Before touching the device, export the certificate in the correct format from Burp Suite itself.

1. Open Burp Suite and navigate to Proxy, then Proxy Settings
2. Under TLS, click Import / export CA certificate
3. Select "Certificate in DER format" and save it as cacert.der

Converting the Certificate to PEM Format

Android's system store requires the certificate in PEM format with a specific filename based on its subject hash. Convert it using OpenSSL.

bash

openssl x509 -inform DER -in cacert.der -out cacert.pem

Generating the Correct Filename

Android names system certificates using the hash of the certificate's subject name, followed by .0. Generate this filename with OpenSSL.

bash

openssl x509 -inform PEM -subject_hash_old -in cacert.pem | head -1

This outputs a hash value such as 9a5ba575. Rename your certificate accordingly.

bash

mv cacert.pem 9a5ba575.0

Installing on a Rooted Device With a Writable System Partition

On older Android versions or devices where you can remount the system partition as writable, the installation is straightforward.

Remounting the System Partition

bash

adb root
adb remount

Pushing the Certificate

bash

adb push 9a5ba575.0 /sdcard/
adb shell "su -c 'mv /sdcard/9a5ba575.0 /system/etc/security/cacerts/'"
adb shell "su -c 'chmod 644 /system/etc/security/cacerts/9a5ba575.0'"

Rebooting the Device

bash

adb reboot

After reboot, check Settings, Security, Trusted Credentials, System tab to confirm the Burp CA now appears alongside the default system certificates.

Installing on Devices With Magisk Using a Systemless Approach

Most modern Android devices ship with a read-only system partition protected by dm-verity, which prevents direct writes even with root access. Magisk's systemless hosts and module system solves this without disabling dm-verity or triggering integrity checks.

Using the MagiskTrustUserCerts Module

Install the MagiskTrustUserCerts module through the Magisk Manager app. This module automatically copies any user-installed certificate into a systemless overlay that appears in the system store to every app on the device.

Once installed, simply install the Burp CA through Android's normal Settings menu as a user certificate.

bash

adb push cacert.der /sdcard/Download/

Then navigate to Settings, Security, Encryption and Credentials, Install a Certificate, CA Certificate, and select the file. The Magisk module handles moving it into the systemless system store automatically on the next boot.

Manual Systemless Overlay Without the Module

If you prefer a manual approach instead of relying on a third-party module, you can create the overlay yourself using Magisk's resetprop and mount namespace approach.

bash

adb shell su -c "mkdir -p /data/adb/modules/sagefox_cacert/system/etc/security/cacerts"
adb push 9a5ba575.0 /sdcard/
adb shell su -c "cp /sdcard/9a5ba575.0 /data/adb/modules/sagefox_cacert/system/etc/security/cacerts/"
adb shell su -c "touch /data/adb/modules/sagefox_cacert/module.prop"

Populate the module.prop file with basic metadata so Magisk recognizes it as a valid module.

bash

adb shell "echo -e 'id=sagefox_cacert\nname=SageFox CA Cert\nversion=1.0\nversionCode=1\nauthor=sagefox\ndescription=Burp CA systemless install' > /sdcard/module.prop"
adb shell su -c "cp /sdcard/module.prop /data/adb/modules/sagefox_cacert/module.prop"
adb reboot

This method gives you full control over the module without depending on external repositories, which matters in engagements where installing unreviewed third-party Magisk modules is not acceptable under client security policy.

Installing on Android Emulators for Testing

Emulators running Google APIs images typically have a writable system image, making certificate installation simpler than physical devices.

Starting the Emulator With a Writable System

bash

emulator -avd Pixel_6_API_33 -writable-system

Pushing and Installing the Certificate

bash

adb root
adb remount
adb push 9a5ba575.0 /system/etc/security/cacerts/
adb shell chmod 644 /system/etc/security/cacerts/9a5ba575.0
adb reboot

Emulator images without Google Play services (AOSP-based) tend to work more reliably for this approach, since Play Store images often enforce additional integrity checks that block direct system partition writes even in emulated environments.

Verifying the Certificate Is Trusted System-Wide

After installation, confirm the certificate is recognized correctly before starting your assessment.

bash

adb shell "ls /system/etc/security/cacerts/ | grep 9a5ba575"

Then open a browser or any non-pinned app on the device with the proxy configured, and confirm requests populate in Burp Suite's HTTP history without certificate warnings. A clean connection here confirms the CA is trusted at the system level, separate from any app-specific SSL pinning that may still need to be addressed separately.

What This Does Not Solve: Certificate Pinning

Installing the CA as a system certificate resolves standard TLS trust validation, but it does nothing against apps that implement certificate pinning, since pinning checks the certificate against a hardcoded value regardless of what the OS trusts. If traffic still fails to appear after confirming the system cert installation worked, the target app is very likely pinning its connections and will require a runtime bypass approach on top of this setup.

SageFox Cybersecurity's mobile testing team handles both layers as standard practice on every engagement, since system certificate installation alone only gets you partway to full traffic visibility on modern, security-conscious applications.

Common Errors and Troubleshooting

Certificate Not Appearing in System Trusted Credentials

Double check the filename hash was generated correctly and matches the exact output of the subject_hash_old command, since even a single character mismatch will cause Android to ignore the file silently.

Device Fails to Boot After Modifying System Partition

This typically happens when dm-verity is still enabled and detects the partition modification. Disable verity explicitly before attempting direct system partition writes.

bash

adb disable-verity
adb reboot
adb remount

Magisk Module Not Loading After Reboot

Confirm the module directory structure matches Magisk's expected layout exactly, and check the Magisk Manager app's log viewer for module load errors, which usually point directly to a missing or malformed module.prop file.

Best Practices for Certificate Installation During Assessments

• Always confirm which Android version and API level the target app compiles against before choosing an installation method
• Prefer the Magisk systemless approach over direct system partition writes on production-representative test devices, since it is easier to cleanly revert
• Keep a dedicated test device profile with the CA pre-installed to avoid repeating this process for every engagement
• Document the exact certificate hash and installation method used in your assessment notes, since client-provided devices sometimes require a different approach than your standard lab setup
• Always test on a device matching the target app's minimum supported Android version, since certificate trust behavior has changed significantly across Android releases

Key Takeaways

Installing Burp Suite's CA certificate as a system certificate on Android is a foundational step for any serious mobile application security assessment, since it ensures traffic interception works consistently across apps that ignore user-installed certificates. Whether you have a fully writable system partition, a Magisk-rooted device with dm-verity enabled, or an emulator, the underlying goal is the same: getting the certificate hash-named correctly and placed where every app on the device will trust it by default.

If your team needs reliable, consistent mobile traffic interception set up correctly across your testing device fleet, SageFox Cybersecurity's mobile penetration testing team builds this environment as a standard part of every engagement, so your assessment starts with full visibility instead of losing time troubleshooting certificate trust issues.