In today's digital world, the security of a mobile device directly depends on the trusted root certificate used to encrypt traffic and authenticate applications. Users are often faced with the need to manually install or remove digital signatures when setting up corporate email, using specialized sniffers, or solving problems with access to banking sites.
However, the hidden architecture of the operating system Android is not always obvious to the average smartphone owner. The file system is divided into several logical segments, and certificates can be located in different directories depending on their type and installation method. Understanding where certificates are stored in Androidis critical for administering the device and eliminating security conflicts.
In this article we will look in detail at the structure of trusted certification authority stores, the differences between system and user data, as well as ways to manage them with and without superuser rights them.
Architecture of trusted certificate stores
The operating system uses a complex hierarchy to store cryptographic keys. By default, all pre-installed certificates are located in a protected section, access to which is restricted at the kernel level. This is done to prevent the system from being compromised by malware.
System keys are located in the directory /system/etc/security/cacerts. This is where the root certificates of the world's largest certification authorities are located, such as DigiCert, Let's Encrypt i GlobalSign. These files have the extension .0 and are hashed subject names pointing to the actual certificate files.
For users without root access, this folder is read-only through special utilities or file managers with special privileges. An attempt to change the contents of this directory without unlocking the bootloader or gaining full access will result in an access error.
Never delete files from the system cacerts folder manually without a backup copy - this can lead to the inability to connect to secure sites and the operation of most applications.
User certificates, installed manually by you are stored in a different location, ensuring they are isolated from system data. This allows you to easily roll back changes in the event of a configuration error.
User certificates and their locations
When you download a file format .cer, .crt or .p12 and install it through security settings, it ends up in a special credential store. The physical path to this data depends on the version Android, but it is logically separate from the system partition.
Starting with Android version 11 and higher, user root certificates are no longer trusted by default applications for security reasons. They are stored in an encrypted storage that can only be accessed by systems with elevated privileges or by the user himself through settings.
- 📁 System certificates:
/system/etc/security/cacerts - 🔐 User certificates (old versions):
/data/misc/user/0/cacerts-added/ - 🛡️ Keystore: isolated environment execution
It is important to understand that simple file managers without superuser rights will not show the contents of the folder /data. To view these files, you will need to use USB debugging (ADB) or specialized software.
⚠️ Attention: Installing custom certificates on modern versions of Android (11+) requires user confirmation each time you launch an application that uses these keys, unless the application has special exceptions.
How to view installed certificates through settings
The most secure and accessible way to manage trusted centers is to use the built-in system interface. You do not need third-party apps or a connection to a computer.
Go to the menu Settings → Security → Encryption and Credentials. In some shells, for example MIUI or OneUI, the path may differ slightly, but the keywords "Encryption" or "Security" remain unchanged.
Here you will see two main sections: “User Certificates” and “CA Certificates” (Certification Authorities). The first section contains only those keys that you added manually. The second section displays the system list, but you usually cannot edit it from here.
| Storage type | Write access | Requires Root | Impact on the system |
|---|---|---|---|
| System (System) | No (read only) | Yes | Global for all applications |
| Custom (User) | Yes (delete/add) | No | Limited, depends on the OS version |
| Keystore | Via application API | No | Isolated for a specific application |
To delete an unnecessary or compromised certificate, just click on its name in the list and select the "Delete" or "Clear credentials" option. This action immediately revokes trust in this certification authority for all user applications.
Clearing credentials through settings deletes only user certificates, system keys remain intact, which guarantees the operation of the OS.
Managing certificates via ADB and terminal
For advanced users and developers, it is possible to work with the storage via command line. The tool Android Debug Bridge (ADB) allows you to access the file system in read mode, and if you have root access, also write.
Connect the device to the computer, enable USB debugging and run the command to enter the shell:
adb shellNext, to view the list of installed user certificates, you can use the listing command. Please note that without superuser rights, you will only see symbolic links or an empty directory depending on the firmware version.
ls -la /data/misc/user/0/cacerts-added/If you need to install the system certificate manually (for example, to run specific enterprise software on an old device), you will need to remount the partition /system to read-write mode. This is a dangerous operation that requires an unlocked bootloader.
Risks of modifying the system partition
Changing files in /system can lead to a violation of the integrity of the system signature (SafetyNet/Play Integrity), which will cause banking applications and Google Pay services to stop working.
Using the terminal on the device itself (through applications like Termux) is also possible, but the functionality will be severely limited by security policies Selinux without obtaining root access su.
Compatibility issues and Android versions
Google is constantly tightening security policies with each new release of the operating system. What worked on Android 9 or 10 may be completely blocked on Android 13 or 14.
Starting with Android 11, apps targeting the new API layer ignore user root certificates. This is done to protect against "Man-in-the-Middle" attacks, where an attacker injects their certificate to intercept encrypted traffic.
- 📉 Android 10: Custom certificates work for most applications.
- 🚫 Android 11+: Applications ignore custom CAs by default.
- ⚙️ Android 14: Introduced a requirement for explicit trust verification for each applications.
Developers have to use workarounds, such as embedding a certificate directly into application resources or using network configurations (network_security_config.xml) to explicitly indicate which certificate authorities to trust.
⚠️ Attention: Settings interfaces and file paths may differ depending on the device manufacturer (Samsung, Xiaomi, Pixel). Always check the official documentation for your specific model, as custom firmware may change the directory structure.
☑️ Check before installing the certificate
Security and removal of compromised keys
Regular auditing of the certificate store is an important part of digital security hygiene. If you previously installed certificates for debugging traffic or testing applications, they should be removed after completion.
Leaving a user root certificate active creates a vulnerability. Any malicious application that gains access to the network could theoretically use this certificate to decrypt your HTTPS traffic if it can bypass additional checks.
To perform a full cleanup, go to Security Settings and select Remove all credentials or Clear key store. The system will ask for confirmation and possibly a PIN or pattern.
Remember that this operation will delete all Wi-Fi Enterprise certificates, VPN profiles, and digital signatures you added. You will have to reconfigure corporate access if it was dependent on these keys.
Regularly cleaning user certificates reduces the attack surface and prevents potential data interception by unscrupulous applications.
Frequently asked questions (FAQ)
Can system certificates be migrated to custom?
Technically, you can copy the file, but this will not give the desired effect on modern versions of Android. System certificates are signed by the device manufacturer or Google, while custom certificates are considered untrusted by default for critical applications. The digital signature verification mechanism (.apk) will not allow you to replace the system key with a user one without modifying the system.
Why does the bank write about a certificate error, although I have not installed anything?
This can happen for several reasons: an outdated date and time on the device, the presence of malware that has embedded its certificate, or the use of a corporate antivirus/VPN that replaces traffic. Check the list of user certificates in the security settings and remove any unknown entries.
Where are certificates stored for Wi-Fi with certificate authorization?
Such certificates are usually installed in the same user credential store. When setting up Wi-Fi Enterprise (802.1x), the system asks you to select a certificate from this list. Physically they are located in the same protected area /data/misc/keychain.
How to install a certificate without access to the settings menu?
If the interface is not available, you can try to rename the certificate file to the hash of its subject (for example, 9a5b3c....0) and place it in the folder /system/etc/security/cacerts via Recovery mode or ADB with root access. However, this method is outdated and not recommended for ordinary users due to the high risk of system failure.