In the ecosystem Android connection security is built on a complex trust architecture, the foundation of which is digital certificates. These cryptographic files authenticate servers, applications, and devices themselves, ensuring secure data transfer using TLS/SSL protocols. Understanding where these keys are physically and logically located is necessary not only for cybersecurity specialists, but also for ordinary users who encounter connection errors or the need to manually install root certificates.
The architecture of storing cryptographic materials in the Google operating system has undergone significant changes in recent years. If in early versions of the platform all data lay in relatively accessible sections of the file system, then modern Android 12, 13 and 14 use isolated spaces and hardware security modules. Certificate storage is now distributed between the system partition, user area and a specialized chip, which makes it difficult to directly access files without gaining superuser privileges.
In this article we will analyze in detail the paths to configuration files, storage formats and methods for managing trusted certification authorities. You will learn how the system distinguishes between pre-installed roots and manually added keys, and also why some certificates may disappear after rebooting the device.
System store of trusted certification authorities
The main array of trusted roots necessary for the operation of the browser Chrome, store Google Play and most system applications reside in a secure system partition. These certificates are signed by the device manufacturer or firmware vendor and are considered completely trusted by default. Access to this area on regular devices is closed for writing, which prevents the substitution of root keys by malware.
Physically, the system certificate files are located along the path /system/etc/security/cacerts. This directory stores hundreds of files in PEM or DER format, whose names are a hash of the certificate's subject (Subject Name Hash). For example, a file named 8d89cda1.0 corresponds to a specific certificate authority, such as DigiCert or Let's Encrypt.
Starting with Android 7.0 (Nougat)applications trust only these system certificates by default. This means that any custom keys set through Settings are ignored by regular applications unless the developer has explicitly enabled their use in the network security configuration. This measure has significantly increased security against man-in-the-middle (MitM) attacks.
⚠️ Attention: An attempt to manually replace or delete files in a directory
/system/etc/security/cacertswithout root access and an unlocked bootloader will result in a system signature verification error (Verification Failed) and the inability to boot the device.
To view the contents of this storage on the device with superuser rights, you can use a file manager with root access or a terminal command. However, simply copying the files is not enough: the system dynamically loads them when the service starts KeyStore, and the changes take effect only after a reboot.
If you are developing an application and need to add your root certificate for testing, use the network_security_config XML configuration file instead of trying to modify the system partition.
User storage and manual import
When the user independently installs a certificate, for example, to connect to a corporate Wi-Fi protocol EAP-TLS or to debug traffic via Charles Proxy, the file ends up in a separate user storage. Logically, these keys are separated from the system keys so that the user can easily delete them if they are compromised or expire.
In modern versions of Android, the path to user certificates is located in a protected data area: /data/misc/user/0/cacerts-added. The number 0 in the path indicates the main user ID; if additional profiles are created on the device, the path will change accordingly (for example, /data/misc/user/10/...). Files here are also named using the subject hash, but have an extension .0 or similar indicating the type of trust.
- 🔐 User installed certificates require a screen lock (PIN, password or pattern) to confirm the installation.
- 📂 When performing a factory reset (Factory Reset) all user certificates are permanently deleted, unlike system ones.
- 👁️ Starting with Android 11, the user cannot simply view the list of installed root certificates of third-party applications without special debugging permissions.
The import process is initiated through security settings or by opening a file with the extension .crt, .cer or .p12. The system requests the certificate name and password (if the container is encrypted), after which it places it in the appropriate directory and updates the database KeyStore.
Hardware security module and Keystore
The most critical cryptographic keys, including those used for biometric authentication and application data protection, are stored not in the file system, but in dedicated hardware module. This component is called Trusted Execution Environment (TEE) or, in newer implementations, Android StrongBox.
StrongBox is a separate chip with its own processor, RAM and secure data storage, physically isolated from the main processor of the device. Even if the operating system is completely compromised and root access is obtained, it is impossible to extract private keys from StrongBox - the chip will simply refuse to issue them without proper authorization.
| Storage type | Location | Protection level | Availability when Root |
|---|---|---|---|
| System CA | /system/etc/security |
High (OEM signature) | Read only |
| User CA | /data/misc/user/0/cacerts |
Medium (screen password) | Read/Write |
| App Keys (Keystore) | TEE / StrongBox Chip | Maximum (Hardware) | Not available |
Developers can request the creation of keys directly inside a secure element by specifying parameters in the code via KeyGenParameterSpec. In this case, the key material itself never leaves the secure perimeter of the chip; signing or encryption operations are performed inside the module, and only data is transferred to input and output.
How to check the presence of StrongBox on the device?
Use the adb command: `adb shell pm list features | grep keystore`. If you see `android.hardware.security.strongbox`, then your device supports top-tier hardware storage.
File formats and encodings
When working with certificates on Android, it is critical to understand the differences in file formats, as the system may reject the import if the expected type does not match. The most common format for root certificates is PEM (Privacy Enhanced Mail), which is a Base64-encoded text representation of data surrounded by headers.
A PEM file looks like a block of text starting with a line -----BEGIN CERTIFICATE----- and ending -----END CERTIFICATE-----. It contains encoded information about the public key, owner and signature of the certification authority. Android successfully imports such files if they have the correct structure and are not damaged.
Another popular format is DER (Distinguished Encoding Rules). This is a binary representation of the certificate that takes up less space but is not human readable in a text editor. Certificates are often distributed as containers PKCS#12 (extensions .p12 or .pfx), which can contain not only the certificate, but also a password-protected private key.
⚠️ Attention: If you are trying to install a certificate for HTTPS debugging and receive a "Failed to install" error, make sure that the file does not have a double extension (for example,
cert.crt.txt) and the file encoding does not contain specific BOM characters, which are sometimes added by Windows text editors.
To convert formats, you can use the utility OpenSSL on your computer before transferring the file to your smartphone. The command to convert from DER to PEM is as follows:
openssl x509 -inform der -in certificate.cer -out certificate.pemOnce converted, the file is generic and is more likely to be processed correctly by the Android Credential Manager regardless of the firmware version.
Always check the file extension before importing: Android prefers .pem or .crt for root certificates, while .p12 is required for client certificates with a private key.
Certificate management via ADB and terminal
For advanced users and developers, it is possible to manage the certificate store via the command line interface ADB (Android Debug Bridge). This allows you to automate the process of installing roots on test devices or emulators without the need to manually press buttons on the screen.
However, it is worth considering security restrictions: starting with Android 11, direct writing to system partitions via ADB is blocked even in debugging mode. To install a user certificate programmatically, use the command adb push in combination with the installation_intent, or special scripts that emulate user actions.
- 🛠️ To view the list of installed user certificates, you can use the command:
adb shell ls /data/misc/user/0/cacerts-added/. - 📤 Installing a certificate via ADB requires transferring a file and calling an Activity installation:
adb shell am start -n com.android.settings/.SecuritySettings(the path may vary). - 🔍 You can check the fingerprint of the certificate with the command:
openssl x509 -in cert.pem -noout -fingerprint -sha256.
When debugging network requests, developers often use Android Studio emulators. In them, the process is simplified: just place the file cert.pem in a folder ~/.android/cacerts on your computer, and the emulator will automatically pick it up at startup, adding it to the trusted roots.
☑️ Preparing to install the certificate via ADB
Compatibility issues and security updates
The trusted certificate ecosystem is not static: certificate authorities periodically revoke their roots due to compromise or expiration. Google releases regular security updates that modify the contents of the system storage. /system/etc/security/cacerts.
If your device stops opening certain sites or applications throw an SSLHandshakeException error, the reason may be the removal of an outdated root certificate (for example DST Root CA X3 from Let's Encrypt, which expired in 2021). In such cases, the system blocks the connection because the chain of trust is broken.
Users of older versions of Android who no longer receive security updates from the manufacturer may find that their store contains revoked certificates. This creates a security risk as the device may trust compromised authorities. The only solution in this situation is to manually update the root store or install a third-party browser with its own certificate store, for example Firefox.
⚠️ Attention: Settings interfaces and exact file paths may vary slightly depending on the manufacturer's shell (MIUI, OneUI, ColorOS). Always check the latest documentation for your specific device model, as customization may hide standard certificate management menus.
For enterprise environments that use internal certificate authorities, it is critical to distribute new root certificates to all employee devices in a timely manner. A delay in updating can lead to a massive failure of access to internal mail and company resources.
Use the Certificates application (CertInstaller) or third-party managers from Google Play to easily view the details of installed certificates, such as the expiration date and signature algorithm.
Where exactly is the cacerts.bks file located on Android?
File cacerts.bks (Bouncy Castle Keystore) was historically used in older versions of Android and some Java applications. In the modern system, it is replaced by a set of individual files in /system/etc/security/cacerts. However, some older applications may still look for this file in /data/misc/keychain/ or inside their APK.
Why is the installed certificate not visible in the list of trusted ones?
Most likely, the certificate is installed as "Custom" and the application is only checking "System" roots. Starting with Android 7, apps ignore user certificates by default. Check the presence of the file network_security_config.xml in the application manifest.
Is it possible to export installed certificates back to a file?
Standard Android tools do not allow exporting user certificates back to a file for security reasons. This will require root access and copying files from /data/misc/user/0/cacerts-added/ with subsequent conversion from DER to PEM.
How to delete all user certificates at once?
Go to Settings → Security → Encryption and credentials → Remove credentials. This operation will clear the user key store, but will not affect the system roots.
Does an unlocked bootloader affect the operation of certificates?
Yes, on devices with an unlocked Bootloader, some applications (banking, Google Pay) may refuse to work or trust the system storage, considering the environment compromised, even if the certificates have not been changed.