# MoveCertificate puts a proxy certificate into the Android system store

> MoveCertificate is a Magisk, KernelSU and APatch module that moves a certificate you installed as a user certificate into the Android system certificate store, on Android 7 through 16, so that a traffic inspection proxy is trusted by every app on the device rather than only by the browser you installed it into. The module ships the usual root module scripts, a certificate name table, an update channel and a small web page for listing and removing the certificates it installed.

**ys1231/MoveCertificate** — 支持Android7-16移动证书，兼容magiskv20.4+/kernelsu/APatch, Support Android7-16, compatible with magiskv20.4+/kernelsu/APatch

- Repository: https://github.com/ys1231/MoveCertificate
- Website: https://github.com/ys1231/MoveCertificate
- Stars: 2,003 · Forks: 190
- Language: TypeScript
- License: Apache-2.0
- Published: 2026-10-16 · Updated: 2026-10-16 · Language: en
- Canonical page: https://hysenlabs.com/projects/ys1231-movecertificate

## The reason a user certificate is not enough

The module's job is one line in the README, moving user certificates to system certificates, with support for Android 7 to 16. The context is the standard problem in Android traffic inspection. A certificate installed through the system settings ends up in the user credential store, which the browser trusts and which most applications do not, so an app under test simply refuses the connection and you see a TLS error with no useful information. Putting the certificate in the system store changes that, because the system store is the store the platform consults for every application, and a proxy that intercepts on the device's own network interface then works for the app. The README also points at an appproxy VPN tool as something this pairs with, and it notes that if the phone is an official image you may need the module, while a self-built image can bake the certificate in or move it manually.

## Two routes, and the second one is the fiddly one

The usage section puts the simple route first and recommends it explicitly. Export the certificate, push it to the phone, install it through the system settings as usual, and reboot, with no format conversion needed at all. The manual route is for the case where you want the certificate in the system store directly, and the README warns that this method overwrites existing certificates and is meant for a machine with several computers and built-in certificates, and that in normal situations you do not need it. The specific trap is spelled out, that a HASH.0 file exported directly by Reqable may not work and you are advised to export the crt instead and use the system settings install, because even if the certificate file moves successfully the system cannot recognise it if the encoding is wrong. That sentence is the most useful line in the document for anybody who has spent an afternoon on this.

## The manual path, in openssl commands

The manual path is a sequence of openssl invocations, and each step exists for a reason. The first step computes the subject hash of a PEM certificate, and the second converts it to DER, which is the format the Android system store uses:

```shell
# pem 证书 Android 系统使用 der 所以移动后的证书格式需要转成 der
## 1. 计算 pem
openssl x509 -inform PEM -subject_hash_old -in cacert.pem
## 2. 转 der
openssl x509 -in cacert.pem -outform der -out cacert.der
### 2.1 或者 crt
openssl x509 -in cacert.crt -outform der -out cacert.der
mv cacert.der 02e06844.0
```

If you already have the DER form, the hash is computed from it and the file is renamed to the hash with a .0 suffix, and the README also points out the shortcut of extracting the certificate from the user directory on the phone after installing it there, which removes the need to think about the conversion at all. Once you have the file named 02e06844.0, or 02e06844.1 if you want it to coexist with an existing one, it is pushed to the device and the device is rebooted:

```shell
adb push 02e06844.0  /data/local/tmp/cert/
```

## The module format, and the files that do the work

The repository is laid out as a root module, and the file names are the standard ones. There is module.prop with the module metadata, customize.sh for the installation-time work, action.sh for what runs when the user triggers the module from the manager, service.sh for the service mode, post-fs-data.sh for the early boot stage, uninstall.sh for the cleanup, and system.prop for the property overrides. The sh/ directory holds the shell functions those scripts call, cert_names.json is the table of certificate names, update.json is the update channel, META-INF/ carries the packaging metadata for a flashable zip, and changelog.md records the changes. The whole thing is packaged with a single command from the README:

```shell
./buildzip.sh all
```

The compatibility target is stated in the description, Magisk 20.4 or newer, plus KernelSU and APatch, and the Android range is 7 to 16, with the releases at v1.6.0, v1.6.1 and v1.6.2 in August and September 2026.

## The web page for seeing and removing what was installed

There is a second component that is easy to miss. The MoveCertificate web is a web page used by the module to show the list of installed certificates, to inspect the detailed information of the certificates the module installed, and to delete an installed certificate with a long press. The webdev/ directory holds it and the README shows a screenshot of it in use. The reason it is worth building is that the manual route leaves a mess. A certificate moved into the system store survives a system update in ways that surprise people, and if you have installed three proxies over three weeks you have three trust anchors on the device with hashed filenames that tell you nothing, so a page that lists them and lets you remove one is the difference between a test device you can hand to somebody else and one you cannot.

## What the module does to the trust model of the device

The reason this tool is worth writing about carefully is that it changes the security posture of a device, and the change is significant. A user certificate is trusted by the browser that installed it and, on many Android versions, not by anything else. A system certificate is trusted by everything, which is what makes traffic inspection work and also what makes it dangerous. Anyone with the module can install a trust anchor that intercepts TLS for every application on the device, silently, and the applications have no way to notice. The module therefore belongs on a device you own and control, ideally one that is not carrying your real accounts, and the module's own uninstall script and the removal feature in the web page are the two tools for undoing it. The README's reference links point at the same ground, with the Magisk guides, the KernelSU module documentation, the Magisk-Modules-Repo movecert project, and a mobile pentesting note about installing a Burp certificate on Android 14 and later, which is the context this tool is built for.

## Where it stops, and what to use instead

The boundary is the root. On a device without Magisk, KernelSU or APatch there is no system partition to write to, so the module has nothing to act on and the only route is a self-built image with the certificate baked in, or a remount and a manual move as the README says for your own builds. That is a real limit for anyone testing a device they do not own, and it is why the alternative on a stock device is the in-app proxy that the application under test provides, or an emulator image where you control the system store yourself. The second limit is the encoding trap, which the README does not soften, because the failure is silent, the file is in the right place and the system still refuses it. The third is the coexistence question, since the hash naming scheme means a second certificate for the same subject becomes a .1 file, and the manual route overwrites existing certificates by design, which is why the settings route is listed first.

## Conclusion

MoveCertificate is the right tool if you are testing an Android application you own or have permission to test and need the proxy certificate to be trusted by the app rather than only by the browser, because the system store is the only place an app will look, and because the module handles the conversion and the naming that the manual route leaves as a source of silent failures. It is the wrong tool for an unrooted device, where the approach is not available at all, and the wrong tool for anything beyond a device you control, since a system-wide trusted certificate is exactly the capability a traffic interception tool needs. Before you use it, read the section on the format conversion, because a certificate that moved correctly but cannot be read by the system is the most common failure, and prefer the settings install route, which the README lists first precisely because it avoids the encoding problem entirely.

## FAQ

### What does the MoveCertificate module do?

It is a Magisk, KernelSU or APatch module that moves a user certificate into the Android system certificate store, so that a traffic inspection proxy is trusted by every application on the device rather than only by the browser that installed it. It supports Android 7 through 16 and requires Magisk 20.4 or newer.

### Why does my certificate still not work after it has been moved?

The most common reason is the encoding. The Android system store uses DER, and a HASH.0 file exported directly by some tools may not be usable, so the README advises exporting the crt, installing through the system settings where possible, or converting the file with openssl x509 -in cacert.pem -outform der -out cacert.der and renaming it to the subject hash with a .0 suffix before pushing it to the device.

### How do I install the MoveCertificate module?

The package is built with ./buildzip.sh all, and the module is flashed like any other, with the standard scripts for installation, action, service, early boot and uninstall. The README also documents a manual route that pushes the converted certificate to /data/local/tmp/cert/ with adb push and reboots the device.

### What is the MoveCertificate web page for?

It shows the list of installed certificates, lets you inspect the details of the certificates the module installed, and lets you delete an installed certificate with a long press, which matters because certificates moved into the system store are not easy to identify or remove by hand.

## Sources

- [License: Apache-2.0](https://github.com/ys1231/MoveCertificate/blob/main/LICENSE)
- [Project website](https://github.com/ys1231/MoveCertificate)
- [README](https://github.com/ys1231/MoveCertificate/blob/main/README.md)
- [Releases](https://github.com/ys1231/MoveCertificate/releases)
- [ys1231/MoveCertificate on GitHub](https://github.com/ys1231/MoveCertificate)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/ys1231-movecertificate