DATE
March 27, 2026
Mobile application security testing has become a non-negotiable part of any serious penetration testing engagement. Android devices, by design, restrict user-installed certificates from being trusted by applications that target API level 24 and above. This means that simply installing Burp Suite's CA certificate through the device settings is no longer sufficient for intercepting HTTPS traffic from modern Android apps. To get around this, security professionals need to install the certificate as a system-level CA, which requires root access and a deeper understanding of Android's file system.
This guide walks you through exactly how to do that, with every command you need to execute it cleanly and efficiently.
If you are looking to take your organization's mobile security posture seriously, the team at Redfox Cybersecurity offers comprehensive mobile application penetration testing services tailored to real-world threat scenarios.
Starting with Android 7.0 (Nougat), Google introduced network security configuration changes that caused apps to ignore user-installed CA certificates by default. This is a security improvement for end users, but it creates a significant friction point for penetration testers trying to intercept and analyze HTTPS traffic.
When a CA certificate is installed at the system level, it is trusted by the entire operating system, including all applications. This allows Burp Suite to act as a man-in-the-middle proxy and decrypt TLS traffic that would otherwise pass through undetected.
There are two common paths to achieving this. The first involves pushing the certificate directly to the system partition using ADB and root access. The second involves using Magisk to mount a modified system image. This guide covers both approaches.
Before running any commands, confirm the following are in place:
Hardware and software requirements:
To verify ADB recognizes your device:
adb devices
You should see output similar to:
List of devices attached
emulator-5554 device
If the device shows as unauthorized, check the device screen and accept the RSA key fingerprint prompt.
Open Burp Suite and navigate to Proxy > Options > Import/export CA certificate. Select the option to export the certificate in DER format and save it to your working directory as cacert.der.
Alternatively, you can export it directly from the Burp Suite web interface by visiting the following URL in a browser configured to use Burp as a proxy:
http://burpsuite
Or navigate to:
http://127.0.0.1:8080/cert
Save the downloaded file as cacert.der.
Android's system certificate store expects certificates in PEM format with a specific filename derived from the certificate's subject hash. Convert the DER file to PEM using OpenSSL:
openssl x509 -inform DER -in cacert.der -out cacert.pem
Next, generate the subject hash using the legacy algorithm that Android uses:
openssl x509 -inform PEM -subject_hash_old -in cacert.pem | head -1
This will output an 8-character hash, for example:
9a5ba575
Rename the certificate file using this hash with a .0 extension:
mv cacert.pem 9a5ba575.0
Replace 9a5ba575 with the actual hash you received in the previous step. This naming convention is critical. Android will not recognize the certificate if it is named incorrectly.
Now push the renamed certificate file to the device using ADB:
adb push 9a5ba575.0 /sdcard/
The certificate is now on the device's external storage. It still needs to be moved to the system certificate directory.
This is where root access comes in. Gain a root shell on the device:
adb shell
su
The prompt should change, indicating elevated privileges. Now remount the system partition as writable:
mount -o remount,rw /system
On newer Android versions (Android 10+), the system partition may be protected differently. If the above command fails, try:
mount -o rw,remount /
Now copy the certificate from external storage to the system CA store:
cp /sdcard/9a5ba575.0 /system/etc/security/cacerts/
Set the correct permissions on the file:
chmod 644 /system/etc/security/cacerts/9a5ba575.0
Verify the file is in place:
ls -la /system/etc/security/cacerts/ | grep 9a5ba575
Reboot the device to apply the changes:
reboot
After the device restarts, the Burp Suite CA certificate will be recognized as a system-trusted certificate and your proxy will be able to intercept HTTPS traffic from all apps.
Professional mobile application penetration testing goes far beyond certificate pinning bypasses. If your organization needs a thorough security assessment, Redfox Cybersecurity's penetration testing services deliver actionable results across Android and iOS platforms.
Once the device reboots, navigate to:
Settings > Security > Encryption and Credentials > Trusted Credentials > System
Scroll through the list and confirm that PortSwigger appears as a trusted CA. Alternatively, use ADB to confirm from the command line:
adb shell ls /system/etc/security/cacerts/ | grep 9a5ba575
You can also test interception directly by configuring your device's Wi-Fi proxy to point to your Burp Suite instance and visiting any HTTPS site in the browser.
On devices with read-only system partitions (common in Android 10+ with Dynamic Partitions), the remount approach may not work. In these cases, Magisk provides a cleaner and more stable solution.
Create the Magisk module directory structure on the device:
adb shell
su
mkdir -p /data/adb/modules/burp_cert/system/etc/security/cacerts
Copy the certificate to the module path:
cp /sdcard/9a5ba575.0 /data/adb/modules/burp_cert/system/etc/security/cacerts/
chmod 644 /data/adb/modules/burp_cert/system/etc/security/cacerts/9a5ba575.0
Create the required Magisk module metadata file:
cat > /data/adb/modules/burp_cert/module.prop << EOF
id=burp_cert
name=Burp Suite CA Certificate
version=v1
versionCode=1
author=pentester
description=Installs Burp Suite CA as system certificate
EOF
Reboot the device:
reboot
Magisk will overlay the certificate into the system partition at boot time without actually modifying it. This method survives OTA updates better and is reversible by simply disabling the module in the Magisk Manager app.
Android 14 introduced additional restrictions around system certificate updates. Google moved the CA certificate store to an APEX module called com.android.conscrypt, which is updated independently of the OS. This means the traditional /system/etc/security/cacerts/ path may no longer be the effective trust store.
To address this, you need to write the certificate directly to the APEX certificate directory:
adb shell
su
# Create a temporary writable overlay
APEX_DIR="/apex/com.android.conscrypt/cacerts"
mount -t tmpfs tmpfs /apex/com.android.conscrypt/cacerts
cp /system/etc/security/cacerts/* /apex/com.android.conscrypt/cacerts/
cp /sdcard/9a5ba575.0 /apex/com.android.conscrypt/cacerts/
chmod 644 /apex/com.android.conscrypt/cacerts/9a5ba575.0
Note that this is a temporary overlay that will not survive a reboot. For a persistent solution on Android 14, the Magisk module approach combined with a custom script that re-mounts the APEX directory at boot is currently the most reliable method.
The complexity of modern Android security architecture is exactly why organizations turn to professional services. Redfox Cybersecurity keeps up with every evolution in the mobile security landscape so your testing engagements produce real findings, not false negatives caused by misconfigured tooling.
Installing the CA certificate handles the OS-level trust issue, but many applications implement certificate pinning at the code level. Even with a trusted system CA, these apps will reject Burp Suite's certificate.
Install Frida on your host machine:
pip install frida-tools
Download the appropriate frida-server binary for your device's architecture from the Frida releases page and push it to the device:
adb push frida-server /data/local/tmp/
adb shell chmod 755 /data/local/tmp/frida-server
adb shell su -c "/data/local/tmp/frida-server &"
Use the universal SSL unpinning script:
frida -U -f com.target.application -l ssl_unpinning.js --no-pause
There are several community-maintained Frida scripts for SSL unpinning, with the most widely used maintained by the apk-mitm and objection projects.
Objection wraps Frida and provides a more convenient interface for common tasks including SSL unpinning:
pip install objection
objection -g com.target.application explore
Once inside the objection shell:
android sslpinning disable
This patches common pinning implementations at runtime without modifying the APK.
Certificate not appearing in system trust store after reboot: Confirm the filename hash was generated using the -subject_hash_old flag and not the default SHA-256 hash used in newer versions of OpenSSL.
Permission denied when remounting system partition: Some devices with Verified Boot (dm-verity) enabled will prevent system partition modifications even with root access. Disable dm-verity or use the Magisk overlay approach.
Apps still not trusting the certificate after installation: Check whether the application has a custom network_security_config.xml that overrides system trust. Decompile the APK with apktool and inspect the manifest and the res/xml/network_security_config.xml file if it exists.
ADB shell losing root after reboot: This is expected behavior on some configurations. Re-run adb shell followed by su after each reboot.
Installing Burp Suite's CA certificate as a system-level certificate on Android is a foundational skill for any mobile penetration tester. As Android's security model continues to evolve, the techniques required to maintain effective interception capabilities are becoming more involved. Understanding the underlying mechanics, from certificate naming conventions and partition mounting to APEX modules and Frida instrumentation, separates testers who get results from those who hit walls.
Keeping up with these developments takes dedicated research and hands-on experience. That is why working with specialists makes a meaningful difference in the depth and accuracy of a mobile security assessment.
Whether you are preparing for a compliance audit, validating the security of a consumer-facing application, or conducting a red team exercise, Redfox Cybersecurity brings the expertise to surface the vulnerabilities that matter. Explore their full range of penetration testing and security services and get in touch with the team to discuss your next engagement.
Redfox Cyber Security Inc.
8 The Green, Ste. A, Dover,
Delaware 19901,
United States.
.jpg)
.avif)
.jpg)
