Overview
The Android Certificate Policy lets administrators install trusted certificate authorities and client identity certificates on managed Android devices.
Use this policy to support certificate-based services such as:
Client certificate authentication
Application and service authentication
Certificates are installed through the Swif agent using Android’s device-management framework. They are not delivered through the standard Android Management API policy document.
A single policy can contain multiple certificates. This allows a trusted CA certificate and an identity certificate issued by that CA to reach the device during the same policy run.
Requirements
Requirement | Details |
Supported platform | Android |
Minimum version | Android 9 or later |
Ownership types | Company-owned and BYOD |
Agent connectivity | The Swif agent must be online |
CA format | X.509 certificate in DER or PEM format |
Identity format | PKCS#12 bundle containing a certificate and private key |
Maximum file size | 64 KB after decoding |
On BYOD devices with a work profile, certificate availability is generally limited to the managed profile. Personal-profile applications may not be able to access or trust certificates installed for work.
Certificate Types
The policy supports two certificate types.
Type | Purpose | Supported file |
| Establishes trust for servers or certificates issued by the authority. | X.509 DER or PEM |
| Identifies the device or user during client certificate authentication. | PKCS#12 |
CA Certificate
A CA certificate is installed as a trusted certificate authority in the managed certificate store.
It can be used to validate services such as:
Internal HTTPS servers
Enterprise Wi-Fi authentication servers
VPN gateways
Private certificate authority infrastructure
Security warning: A trusted CA can allow certificates issued by that authority to be trusted within the applicable management scope. Deploy only certificates from controlled and verified certificate authorities.
Identity Certificate
An identity certificate contains:
A client certificate
Its associated private key
Optionally, intermediate certificates forming the certificate chain
Identity certificates must be supplied as a PKCS#12 bundle, commonly using a .p12 or .pfx extension.
Applications, Wi-Fi configurations, and VPN configurations can use the identity certificate for client authentication. A separate configuration may be required to reference the certificate’s alias.
How Installation Works
The Swif agent checks the policy during its periodic policy run.
During each run:
The agent reviews all certificates in the assigned policy.
Certificates that are not present are installed.
Certificates already held by the device are left unchanged.
CA and identity certificates in the same policy are processed during the same policy run.
Installation may not occur immediately after assignment. The device must be online and the Swif agent must complete its next policy run.
Important: Removing a certificate entry from the policy stops Swif from reinstalling it, but does not delete a certificate that is already installed on the device. Use the certificate uninstall command to remove it.
Create the Policy
Sign in to the Swif Admin Dashboard.
Go to Device Management > Policies.
Create a new policy.
Select Android Certificate Policy.
Enter a descriptive policy name.
Add one or more certificates.
Configure the certificate type and upload the certificate file.
For identity certificates, configure a unique alias and the PKCS#12 password.
Assign the policy to a test device or test group.
Allow the device to check in and complete a policy run.
Verify certificate installation and the required authentication workflow.
Expand the assignment after testing succeeds.
Recommended Configuration
There is no universal certificate configuration. Each deployment should use certificates issued specifically for the organization and intended service.
Use these general recommendations:
Setting | Recommendation |
Certificate Type | Select the type required by the service |
Certificate File | Upload only a verified certificate from a trusted source |
Alias | Use a stable, descriptive, unique identity alias |
Certificate Password | Enter the PKCS#12 password when the bundle is protected |
Policy contents | Include dependent CA and identity certificates together |
Identity reuse | Prefer a unique identity for each device or user |
Testing | Validate on representative company-owned and BYOD devices |
Avoid deploying one shared identity certificate and private key to an entire device fleet. Sharing a private key prevents reliable device attribution and increases the impact of credential compromise.
Policy Settings
Certificates
Contains the certificates that assigned devices must hold.
You can add one or more entries. Each entry includes:
Certificate Type
Certificate File
Alias, for identity certificates
Certificate Password, for identity certificates
The default list is empty. An empty policy does not install any certificates.
Certificate Type
Determines how Android installs and uses the certificate.
Value | Behavior |
| Installs an X.509 certificate as a trusted certificate authority. |
| Installs a client certificate and private key from a PKCS#12 bundle. |
This field is required.
Default value:
CA
Selecting IDENTITY displays the Alias and Certificate Password fields.
Certificate File
Upload the certificate file that Swif should install.
This field is required.
Requirements depend on the certificate type:
Certificate type | Required content |
| X.509 certificate encoded as DER or PEM |
| PKCS#12 bundle containing the certificate and private key |
The file must not exceed 64 KB after decoding.
The Swif interface converts the uploaded certificate into the encoded payload required for delivery. Do not paste a file path in place of the certificate contents.
Alias
Specifies the name under which an identity certificate is stored on the device.
The alias:
Applies only to
IDENTITYcertificatesMust be unique within the policy
Can be referenced by a client certificate selection rule
Is used when matching the identity for later removal
Should remain stable throughout the certificate lifecycle
Example:
corp-wifi-device-identity
Use descriptive aliases that indicate the certificate’s purpose. Do not include passwords, private keys, or other secrets in an alias.
CA certificates do not use this field.
Certificate Password
Enter the passphrase protecting the PKCS#12 bundle.
The password allows Android to unpack the certificate and private key during installation.
Leave the field empty when the PKCS#12 bundle has no password.
Enter the exact password when the bundle is protected.
The field is not used for CA certificates.
A wrong password prevents the identity certificate from being installed.
Configuration Examples
Install an Internal Root CA
Use this configuration when managed applications must trust certificates issued by an internal certificate authority.
Setting | Value |
Certificate Type |
|
Certificate File | Organization’s verified root CA in DER or PEM format |
Alias | Not applicable |
Certificate Password | Not applicable |
Before deployment, verify the root CA’s SHA-256 fingerprint through an independent trusted source.
Install a Client Identity Certificate
Use this configuration for a service that authenticates the device using a client certificate.
Setting | Value |
Certificate Type |
|
Certificate File | PKCS#12 bundle containing the client certificate and private key |
Alias |
|
Certificate Password | PKCS#12 bundle password |
Configure the corresponding VPN, Wi-Fi, or application policy to use the same identity alias when required.
Install a CA and Identity Together
Use this configuration when a device needs both the issuing CA and a client identity.
Certificate 1:
Setting | Value |
Certificate Type |
|
Certificate File | Internal root or intermediate CA |
Certificate 2:
Setting | Value |
Certificate Type |
|
Certificate File | Device identity PKCS#12 bundle |
Alias |
|
Certificate Password | PKCS#12 bundle password |
Keeping related certificates in one policy allows them to reach the device during the same policy run.
Company-Owned and BYOD Considerations
Company-Owned Devices
On fully managed company-owned devices, certificates can support device-wide managed services, subject to Android and application behavior.
Recommended practices include:
Issue a separate identity certificate for each device.
Use non-exportable or hardware-backed keys when supported by the certificate workflow.
Combine certificates with managed Wi-Fi and VPN configurations.
Monitor certificate expiration and revocation.
Remove certificates when devices are retired or reassigned.
BYOD Devices
On BYOD devices, Swif manages the work profile rather than the user’s personal profile.
As a result:
Certificates are installed within the managed scope.
Work applications can use applicable managed certificates.
Personal applications may not see or use the certificates.
Removing the work profile removes its managed applications and data according to Android behavior.
Certificate-based workflows should be tested inside work-badged applications.
Do not assume that a certificate installed for the work profile changes trust behavior for personal applications.
Verify the Policy
After assigning the policy:
Confirm that the Android device is online in Swif.
Confirm that the policy reports as installed.
Allow the Swif agent to complete a periodic policy run.
Verify that the expected certificate appears in the managed credential store when the device exposes that information.
Confirm the CA subject, issuer, serial number, and fingerprint.
For an identity certificate, confirm that the expected alias is available.
Connect to the applicable Wi-Fi network, VPN, website, or service.
Confirm that server trust succeeds.
Confirm that client certificate authentication succeeds.
Test the same workflow after restarting the device.
On BYOD devices, test from the work profile.
Confirm that unrelated personal-profile applications are not unintentionally affected.
The exact certificate display location varies by Android version and device manufacturer.
Troubleshooting
The Policy Reports Installed but the Certificate Is Missing
Check the following:
The device runs Android 9 or later.
The Swif agent is online.
The agent has completed a periodic policy run.
The certificate entry contains a file.
The file is 64 KB or smaller after decoding.
The selected certificate type matches the uploaded file.
The certificate file is not corrupted.
The device is using a supported enrollment mode.
The certificate is being checked in the correct work or device profile.
Allow the device to check in again and review its policy status.
A CA Certificate Cannot Be Installed
Confirm that:
The file contains a valid X.509 certificate.
The certificate uses DER or PEM encoding.
The uploaded file contains the certificate rather than an unrelated private key or request.
The certificate is within the size limit.
The certificate is not malformed or truncated.
Inspect the certificate with:
openssl x509 -in root-ca.pem -noout -text
For a DER certificate, use:
openssl x509 -inform DER -in root-ca.cer -noout -text
An Identity Certificate Cannot Be Installed
Confirm that:
The file is a valid PKCS#12 bundle.
The bundle contains a private key.
The bundle contains its corresponding client certificate.
The configured password is correct.
The alias is present and unique.
The decoded file size does not exceed 64 KB.
Test the bundle with:
openssl pkcs12 -in device-identity.p12 -info -noout
Do not extract an unencrypted private key merely for troubleshooting.
The Certificate Is Installed but Authentication Fails
Certificate installation alone does not configure the service that uses it.
Check:
The Wi-Fi, VPN, or application configuration references the correct alias.
The certificate is valid and not expired.
The certificate has not been revoked.
The certificate includes the required key usage and extended key usage.
The server trusts the issuing CA.
The device has the required CA chain.
The server name matches its certificate.
The device date and time are correct.
The application supports managed certificates.
The test is occurring in the correct Android profile.
Review server-side authentication logs for the exact rejection reason.
An Internal Website Still Shows a Certificate Error
Confirm that:
The correct CA certificate is installed.
The server presents a complete certificate chain.
The hostname matches the server certificate.
The certificate is within its validity period.
The application trusts managed or user-installed CAs.
Some Android applications use their own trust store or Network Security Configuration and may not trust a managed CA automatically. Consult the application vendor when the Android system trusts the CA but the application does not.
Android Does Not Select the Identity Certificate
Confirm that the identity alias matches the client certificate selection configuration.
Verify that the PKCS#12 bundle contains the private key.
Confirm that the requesting application supports managed key pairs.
Check whether another certificate matches the same authentication request.
Test from the work profile on a BYOD device.
Review the Wi-Fi, VPN, or application configuration.
The Certificate Exists but Swif Does Not Replace It
The agent leaves certificates already present on the device unchanged.
For certificate rotation:
Install the replacement using a new alias when possible.
Update dependent configurations.
Verify the replacement.
Uninstall the old certificate with the appropriate Swif certificate removal command.
If the replacement must reuse the original alias, remove the old identity before expecting the new one to install under that alias.
Removing the Certificate From the Policy Did Not Delete It
This is expected.
Removing an entry prevents future installation but does not remove a certificate already held by the device. Use the certificate uninstall command to delete the installed certificate.
A Personal Application Cannot Use the Certificate
On a BYOD device, managed certificates are generally scoped to the work profile. Personal applications operate outside that managed profile and may not have access.
Install and test the required application in the work profile.
Security Best Practices
Verify every CA fingerprint before deployment.
Deploy only certificate authorities controlled or explicitly trusted by the organization.
Prefer unique identity certificates for each device or user.
Never share private keys through email, chat, or unsecured storage.
Protect PKCS#12 files and their passwords.
Use strong PKCS#12 passwords.
Limit policy assignment to devices that require the certificate.
Use descriptive, non-sensitive identity aliases.
Monitor certificate issuance, expiration, and revocation.
Rotate certificates before expiration.
Revoke compromised or retired identity certificates.
Remove certificates when a device is retired or its purpose changes.
Test CA trust behavior in every required application.
Maintain an inventory linking certificate identities to their assigned devices.
Avoid deploying broad interception CAs without security, privacy, and legal review.
Security and Compliance Impact
The Android Certificate Policy can support:
Certificate-based device authentication
Enterprise Wi-Fi access
VPN authentication
Mutual TLS
Internal service trust
Reduction of password-based authentication
Device identity and access control
Certificate deployment must be combined with secure issuance, private-key protection, revocation, expiration monitoring, and access-policy enforcement.
This policy does not independently make an organization compliant with a particular security framework.
Notes
The policy supports Android 9 or later.
Company-owned and BYOD devices are supported.
Certificates are installed by the Swif agent through Android’s device-management framework.
A policy can contain multiple certificate entries.
An empty certificate list installs nothing.
CA certificates must use X.509 DER or PEM format.
Identity certificates must use PKCS#12 format.
Identity bundles must contain a certificate and private key.
Certificate files cannot exceed 64 KB after decoding.
Identity aliases must be unique within the policy.
PKCS#12 passwords are optional when the bundle is not password-protected.
Existing certificates are left unchanged during periodic policy runs.
Removing a policy entry does not uninstall the certificate.
Use the certificate uninstall command to remove an installed certificate.
Certificate availability on BYOD devices is limited by work-profile boundaries.
Installing a certificate does not automatically configure Wi-Fi, VPN, or application use.
Summary
The Android Certificate Policy installs trusted CA and client identity certificates on managed Android devices.
For a secure deployment:
Verify the certificate and its fingerprint.
Select the correct certificate type.
Upload a supported file smaller than 64 KB.
Configure a unique alias for each identity certificate.
Enter the correct PKCS#12 password.
Include related CA and identity certificates in the same policy.
Test certificate trust and client authentication.
Rotate certificates before expiration.
Use the certificate uninstall command when removing old credentials.
Protect private keys throughout their lifecycle.