Category Archives: Mobile

Using a custom root CA with Burp for inspecting Android N traffic

TL;DR: Follow these steps to intercept traffic using Burp with a self made root CA on Android (or any browser)

The problem

In a previous blogpost, we presented a Magisk module that easily integrates user certificates into the system CA store in order to bypass Android N’s new hardened security model. For instrumenting applications, this works pretty well, and it has become a standard module on our pentest devices. The flow is really easy:

  1. Set up your WIFI to use Burp as your proxy
  2. Go to http://burp
  3. Download & install the certificate
  4. Reboot

However, if we now open Chrome on the Android device, we get the following error: NET::ERR_CERT_VALIDITY_TOO_LONG.

If we take a look at the specifics of the certificate, we see that the certificate expires on Jan 11, 2023. A quick google search tells us that Google has chosen only to allow leaf certificates that expire within 39 months. This seems like a reasonable requirement, and after searching Portswigger’s site, the recommendation was to reissue the Burp CA certificate. Unfortunately, the problem persisted after doing so.

Burp also allows us to import a self made certificate + private key to be used instead of the automatically generated one. This sounds like an easy solution, as we can decrease the lifetime of the root CA, so it’s the next obvious step. In practice, it turns out to be a lot more difficult to get the configuration right than you would think. The goal of this blog post isn’t about all my failed attempts and why they failed, but about sparing you the trouble and giving you a working step-by-step guide to get this to work.

As a side note, this problem does not occur with the normal setup, where Burp’s root CA is added as a trusted user certificate. Chrome is only picky about “real” CA, which are evidently installed in the system root CA store. However, as I would like to have one certificate setup to rule them all, I searched for a solution…

The solution – Creating custom CA and importing it into Burp suite

I order to successfully install our custom root CA in both Burp and Android, we need to create a CA that has the v3_ca extension. The following steps are executed on a clean 14.04 Ubuntu installation. Granted, there are only a few steps to the processes, but that’s only because I’m not listing all my failed attempts.

# Keep it clean
> mkdir certificates && cd certificates

# Install openssl
> sudo apt-get install openssl

# Borrow the default openssl.cnf (location may differ, see note)
> cp /usr/lib/ssl/openssl.cnf ./

# Create a private key. 
# It's important to have the v3_ca extension and to supply the openssl.cnf file
> openssl req -x509 -days 730 -nodes -newkey rsa:2048 -outform der -keyout server.key -out ca.der -extensions v3_ca -config openssl.cnf
Generating a 2048 bit RSA private key
writing new private key to 'server.key'
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
Country Name (2 letter code) [AU]:BE
State or Province Name (full name) [Some-State]:NVISO CA
Locality Name (eg, city) []:NVISO CA
Organization Name (eg, company) [Internet Widgits Pty Ltd]:NVISO CA
Organizational Unit Name (eg, section) []:NVISO CA
Common Name (e.g. server FQDN or YOUR name) []:NVISO CA
Email Address []:NVISO CA

# Convert to der format
> openssl rsa -in server.key -inform pem -out server.key.der -outform der
writing RSA key

# Convert key to pkcs8 format
> openssl pkcs8 -topk8 -in server.key.der -inform der -out server.key.pkcs8.der -outform der -nocrypt

Note: The openssl.cnf may be in a different place. Alternatively, you can download the default config from the openssl website.

Let’s take a quick look at the generated certificate:

> openssl x509 -in ca.der -inform der -noout -text
 Version: 3 (0x2)
 Serial Number: 17570736880079538514 (0xf3d7cc1942ff0952)
 Signature Algorithm: sha256WithRSAEncryption
 Not Before: Jan 11 16:23:19 2018 GMT
 Not After : Jan 11 16:23:19 2020 GMT
 Subject Public Key Info:
 Public Key Algorithm: rsaEncryption
 Public-Key: (2048 bit)
 Exponent: 65537 (0x10001)
 X509v3 extensions:
 X509v3 Subject Key Identifier: 
 X509v3 Authority Key Identifier: 

X509v3 Basic Constraints: 
 Signature Algorithm: sha256WithRSAEncryption

The generated certificate has the v3_ca extension enabled, so we can import it into Android. Using our magisk module, you can install this certificate through the normal certificate installation flow, and after rebooting your device, the CA should be listed in the system CA store.


The next step is importing these files into Burp. Go to the proxy settings page and choose “Import / Export CA Certificate” -> “Import” -> “Certificate and priate key in DER format”. The correct files to choose are `ca.der` and server.key.pkcs8.der:


After installing the certificate, restart Burp just to be sure.

If everything worked, you’ll now have your custom root CA as a system certificate, and you can intercept all chrome traffic.

It took quite some time to figure out the correct procedure, so I hope I’ve at least saved someone else from spending hours trying to figure it out.

And, in order to help anyone searching for the correct answer, here’s a short overview of the problems I encountered:

  • NET::ERR_CERT_VALIDITY_TOO_LONG (-> Make sure your certificate’s validity is not longer than 39 months)
  • Custom root CA won’t install correctly on Android (-> Make sure it has the v3_ca extension)
  • Burp import errors (-> Follow the steps above for correct setup)
    • Failed to import certificate: signed fields invalid
    • Failed to import certificate: Unable to initialize, extra data given to DerValue constructor
  • OS X / MacOS openssl: Error Loading extension section v3_ca (-> Copy the openssl.cnf file and manually add it as an argument with -config )


About the author

Jeroen Beckers is a mobile security expert working in the NVISO Cyber Resilience team. He also loves to program, both on high and low level stuff, and deep diving into the Android internals doesn’t scare him. You can find Jeroen on LinkedIn.

Intercepting HTTPS Traffic from Apps on Android 7+ using Magisk & Burp

Intercepting HTTPS traffic is a necessity with any mobile security assessment. By adding a custom CA to Android, this can easily be done. As of Android Nougat, however, apps don’t trust client certificates anymore unless the app explicitly enables this. In this blogpost, we present a new Magisk module, that circumvents this requirement, by automatically adding client certificates to the system-wide trust store, which is by default trusted by all apps.

Basic HTTPS interception

Intercepting HTTPS on Android is a very straight-forward job, which only takes a few steps:

  1. Set Burp as your proxy
  2. Visit http://burp
  3. Install the Burp certificate as a user certificate
  4. Intercept

After following these steps, you can view all HTTPS traffic that is sent through the user’s browser. A more detailed explanation can be found on Portswigger’s website.

In the past, this approach would even work for app traffic as the application would trust all installed user certificate by default. One way to prevent app traffic from being intercepted, is by installing certificate pinning. Certificate pinning means that on each SSL connection the certificates presented by the server will be compared to a locally stored version. The connection will only succeed if the server can provide the correct identity. This is a great security feature, but can be tricky to implement.

Enter Android Nougat

Starting with Android Nougat, apps no longer trust user certificates by default. A developer can still choose to accept user certificates by configuring the networkSecurityConfig attribute in the app’s AndroidManifest.xml file, but by default, they are no longer trusted.

A first approach would be to decompile, modify and recompile the application, which are quite some steps to perform. If the app turns out to have protection against repackaging files, this would also be very difficult. An example of this technique can be found on

A different approach is adding the user certificate to the system store. The system store is located at /system/etc/security/cacerts and contains a file for each installed root certificate.

Screen Shot 2017-12-15 at 16.07.58A very simple solution would be copying the user installed file (found at /data/misc/user/0/cacerts-added) to this folder. This is only possible, however, if the system is mounted as r/w. Now, while it is possible to remount /system and perform the necessary actions, this is a rather dirty solution and some root-detection algorithms will detect this modification.

Using Magisk

Magisk is a “Universal Systemless Interface, to create an altered mask of the system without changing the system itself.” The fact that Magisk doesn’t modify the /system partition makes it a very nice solution for security assessments where the application has enhanced root detection. By activating “Magisk Hide” for the targeted application, Magisk becomes completely invisible.

Magisk also supports custom modules that are fairly easy to create. In order to have any user certificate recognized as system certificates, we made a simple Magisk module which can be found on our github. The logic of the module is very basic:

  1. Find installed user certificates
  2. Add them to the /system/etc/security/cacerts directory

When installed, the content of the Magisk module is mounted on /magisk/trustusercerts/. This folder contains multiple files, but the most important one is the system directory. This directory is automatically merged with the real /system directory, without actually touching the /system partition. As a result, all certificates in /magisk/trusteusercerts/etc/security/ will end up in /system/etc/security.

Using the module is easy:

  1. Install the module
  2. Install certificates through the normal flow
  3. Restart your device

After installation, the certificates will show up in your system wide trust store and will be trusted by applications:



Of course, if the application has implemented SSL Pinning, you still won’t be able to intercept HTTPS traffic, but this little module makes Android Nougat apps perform the same way as pre-Android Nougat apps.

If you have any suggestions on how to improve this module, or any ideas on how to add the ability to disable SSL Pinning on the Magisk level, let us know!

Download Magisk Module from Github

About the author

Jeroen Beckers is a mobile security expert working in the NVISO Cyber Resilience team. He also loves to program, both on high and low level stuff, and deep diving into the Android internals doesn’t scare him. You can find Jeroen on LinkedIn.