Step 6: Certificate Enrollment and Device Provisioning


This section addresses digital certificates and how you can use them to identify your mobile devices and provide a more secure authentication path to access your corporate network. It also introduces device provisioning, which can be helpful in managing devices in the enterprise.

Certificates on Windows Mobile Devices

Digital certificates play a significant role in network authentication and in helping to secure a device. Certificates are electronic credentials that bind the identity of the certificate owner or the device to a public and private pair of electronic keys used to encrypt and digitally sign information. Signed digital certificates help to assure that the keys actually belong to the specified application, device, organization, or person, and that they can be trusted.

Digital certificates are used on Windows Mobile powered devices in two essential roles:

  • In authentication, presenting trusted credentials for connecting to a corporate e-mail server or network, or helping to verify the identity of a remote server.
  • In code signing, determining whether an application can be run on the device and if so, the permissions (privileged or normal) with which it will run.

For example, to authenticate with a network, the mobile device must present a certificate from its root store that is recognized and accepted by the server before an SSL connection can be established with the network server.

Further, in order for an application to be installed and run on the device, the application must present a digital certificate that proves it was accepted and signed by a trusted source.

Certificates Shipped on Windows Mobile Powered Devices

By default, Windows Mobile powered devices are shipped with a variety of certificates:

  • Trusted root certificates from major certificate vendors that can be used for authentication purposes.
  • Mobile2Market and other trusted certificates that designate applications that are signed for use on Windows Mobile powered devices.
  • Additional certificates that may be added by the OEM or mobile network operator.

The following table lists the certificates shipped with Windows Mobile devices that run Windows Mobile 6 at this printing.

Vendor Certificate name


AAA Certificate Services


AddTrust External CA Root


Baltimore CyberTrust Root


GlobalSign Root CA


GTE CyberTrust Global Root


Class 2 Public Primary Certification Authority


Thawte Premium Server CA


Thawte Server CA


Secure Server Certification Authority


Class 3 Public Primary Certification Authority

Entrust Certification Authority (2048)

Entrust Secure Server Certification Authority


Equifax Secure Certification Authority


GeoTrust Global CA


Go Daddy Class 2 Certification Authority



Starfield Class 2 Certification Authority

Certificate Stores

The certificates in a Windows Mobile powered device reside in the certificate store in the registry. In the Windows Mobile 6 software, the certificate store includes separate User Root and Certification Authority stores to allow device users with the less-powerful authenticated user permissions to add or to enroll for trusted digital certificates. The system Root and Certification Authority stores can only be changed if you have Manager or Enterprise role permissions.


On Windows Mobile 5.0 powered devices, the certificate Root and Certification Authority stores are locked to everyone except those with Manager role permissions to help ensure the integrity of the digital certificates.

The following table shows the certificate stores on Windows Mobile devices that run Windows Mobile 6, and their uses and permissions.

Certificate store Physical Store Description

Privileged Execution Trust Authorities


Contains trusted certificates. Applications signed with a certificate from this store will run with privileged trust level (Trusted).

Unprivileged Execution Trust Authorities


Contains normal certificates. On a one-tier device, an application signed with a certificate in this store will run with privileged trust level (Privileged). On a two-tier device, applications signed with a certificate from this store will run with normal trust level (Normal).



Contains Software Publishing Certificates (SPC) used for signing .cab or .cpf files and assigning the correct role mask to the file installation.

Root (system)


Contains root certificates, which can be certificates signed by Microsoft, the OEM, or the mobile operator. These certificates are used for SSL server authentication. These cannot be changed without Manager role permissions. Users with the Manager role can add certificates in this store.

OMA DM transport client only checks this store for root certificates when establishing an SSL connection.

Root (user)


Contains root, or self-signed, certificates that can be installed by someone with Authenticated user role.

CA (system)


Contains certificates and information from intermediary certification authorities. They are used for building certificate chains. In Windows Mobile 5.0, users with Manager role can add certificates in this store.

OMA DM transport client only checks this store for intermediate certificates when establishing an SSL connection.

Certificates are added to this store by Microsoft, the OEM, or the mobile operator.

CA (user)


Contains certificates, including those from intermediary certification authorities that can be installed by the device user with Authenticated User role. They are used for building certificate chains.



Contains end-user personal certificates used for certificate authentication or S/MIME.

Certificate Chains

A certificate chain consists of all the certificates needed to certify the subject identified by the end certificate. In practice, this includes the end certificate, the certificates of intermediate Certification Authorities, and the certificate of a root Certification Authority trusted by all parties in the chain. Every intermediate Certification Authority in the chain holds a certificate issued by the Certification Authority one level above it in the trust hierarchy. The root Certification Authority issues a certificate for itself.

When importing the certificate for a client, the certificate chain may be included in the file. This enables the device to authenticate the intermediate and root certificates associated with the end certificate. All certificates in the chain will be added to the appropriate certificate stores on the device in order to enable trust validation.

Basic Authentication

Exchange ActiveSync relies on SSL to help secure the connection between the Windows Mobile powered device and the Exchange front-end or Client Access server. The client device provides the domain user’s credentials using the SSL basic authentication method. This authenticates the client to the server. The device must have the root certificate of the Exchange front-end or client access server in order to establish a secure connection.

Windows Mobile powered devices are shipped with a set of third-party trusted root and intermediate certificates. If you use one of these trusted certificates to help secure your Exchange Server, users of these devices will be able to access your corporate network by entering their domain, name, and password.


Wildcard certificates, which are certificates not supplied by a Microsoft Certification Authority server, can be used with Windows Mobile 6.

Certificate-based Authentication

Windows Mobile 5.0 powered devices with the Messaging and Security Feature Pack and later devices can use SSL with Transport Layer Security (TLS) client authentication in place of SSL basic authentication. Certificate-based authentication offers a potential security advantage over the use of single-factor password-based authentication. This advantage comes from two factors. First, the strength of the key is determined by the administrator and can be very strong. Windows Mobile and Windows Server together support up to 2,048-bit keys. Second, requiring certificate-based authentication greatly reduces the risk that a user’s credentials will be compromised. If a user shares their password, the authentication process helps prevent an attacker from recovering usable credentials. The credentials are hashed and protected by SSL encryption during transport.

To use certificate-based authentication with Windows Mobile, the mobile device must contain the root certificate for the Exchange Server front-end or Client Access server it is communicating with; the mobile device must also have its own client user certificate with the associated private key. The user certificate enrollment process can only occur when the device is connected to a desktop in the same domain as the enrollment web site.

Managing Device Certificates

Digital certificates afford a powerful tool in helping to establish device and user identities for authentication. In a corporate environment, distributing and renewing digital certificates on hundreds or thousands of mobile devices can be a daunting task. With Windows Mobile 6 software and desktop ActiveSync, the management of device certificates has been simplified. The certificate enrollment tools enable the system administrator to manage device certificates to help create a more secure environment.

You can use Windows Mobile 6 software and ActiveSync certificate enrollment tools for the following company-wide activities:

  • Deploying enterprise-wide Exchange ActiveSync or SSL TLS certificate-based authentication
  • Renewing existing certificates
  • Distributing 802.1x wireless certificates
  • Providing certificates for S/MIME digital signing

The process for adding certificates differs between Windows Mobile 5.0 and Windows Mobile 6.

Adding Certificates to Windows Mobile 5.0 Powered Devices

To add a certificate to a Windows Mobile 5.0 powered device, you must have either Manager role permission on the device or have the ability to run trusted code on it. Another option is to contact your OEM or mobile operator for a signed certificate installation tool such as SPADDCERT.exe.

If you wish to install root certificates for certificate-based authentication, you can use the tool for deploying Exchange ActiveSync certificate-based authentication; it can be downloaded from the following Microsoft Download Center Web site:

For more information, see the Microsoft Knowledge Base article titled, How to install root certificates on a Windows Mobile-based device, available at the following Microsoft Web site:

Adding Certificates to Windows Mobile 6 Powered Devices

With Windows Mobile devices that run Windows Mobile 6, you can create a CAB file with a certificate appropriate for your organization. The User role allows your users to install this CAB file to add the certificate to the HKCU Root and Certification Authority stores on the device. You can also distribute the encrypted certificate/key pair required for certificate-based authentication or 802.1x wireless connection using Exchange ActiveSync Desktop enroll.

The certificate installer in Windows Mobile 6 will install certificates delivered in the following file formats:

  • PFX/.P12 – Public-Key Cryptography Standards #12 (PKCS #12) files that include personal certificates with private keys as well as certificates that install into the intermediate and root certificate stores.
  • CER – Base64-encoded or DER-encoded X.509 certificates that install into the intermediate and root certificate stores.
  • P7B - Public-Key Cryptography Standards #7 (PKCS #7) files that install multiple certificates to any certificate store on the device.

The files can be delivered to the device using desktop ActiveSync, removable storage card, e-mail attachment, or Mobile Internet Explorer file download. Windows Mobile devices that run Windows Mobile 6 Professional also allow download from a file share. When the file is opened from the file explorer, the certificate installer is designed to process and install the file automatically.


Those with User role permissions can install a certificate on a device that runs Windows Mobile 6 by copying the CAB or .cer file to the device and running it. However, in order to enroll for a certificate from a Certification Authority, your device users should use Desktop ActiveSync.

Using Desktop Enrollment

Desktop ActiveSync enables users with cradled Windows Mobile powered devices to enroll for a certificate from the corporate server. Your users connect to your network using the existing corporate desktop logon procedure -- password, smartcard, or other means of user identification. The two levels of authentication control the certificate enrollment, streamlining the distribution of the certificates.

Desktop certificate enrollment can be used to query for and to renew certificates on mobile devices. You can also use the Certificate Enroller Configuration Service Provider to define certificate types and to create the provisioning XML file that can be pushed out to the mobile devices.

To prepare for desktop certificate enrollment, the system administrator should:

  • Set up or have access to a Windows 2000, Windows 2003, or later Windows Certificate Server.
  • Create the certificate type or use an existing certificate published to Active Directory.
  • Inform users of the location of the certificate on the corporate network.
  • Provide users with instructions for using the ActiveSync Get Device Certificate feature on the desktop PC.

Once you have published the certificate to Active Directory and directed device users to enroll for the certificate, the users will step through the following process:

To enroll for a certificate with a Windows Mobile 6 powered device

  1. Using ActiveSync, synchronize your Windows Mobile powered device with a desktop PC and log into the corporate network in the same domain as the certificate enrollment server.

  2. From Advanced Tools, choose Get Device Certificate. From the View drop-down combo box in Get Device Certificates, select Certificate types from Active Directory, select the desired certificate from the list, and click Enroll.

  3. Under Get Device Certificate, click Yes to proceed.

  4. To approve the certificate request on a device that runs Windows Mobile 6, a device screen prompt will ask you to confirm the installation process. Click Continue on the device.

  5. A second prompt may appear on the device asking if you wish to install the certificate or block this request. Choose Install.

  6. The desktop processes the enrollment. During this time, the device generates a public/private key set and proxies the enrollment to the Windows Certificate Server through the desktop.

  7. The Certification Authority returns a signed certificate to the desktop, which in turn delivers the certificate to your device.

  8. The device stores the certificate and its chain of certificates to the root Certification Authority. If the root certificate is not already in the root certificate store of the device, you will be asked to accept the certificate.

  9. You will see a success dialog at the end of the enrollment process. Click Ok on Get Device Certificate, then Close.

Once the certificate is in the user Root or Certification Authority store, the mobile device will be ready to authenticate with the desired protocol.

Windows Mobile Security Policies and Device Provisioning

In the enterprise, you may be dealing with both front-door and back-door devices. Front-door devices are new devices purchased in large quantities directly from an OEM or mobile operator. In this case, you may be in a position to request specific features and work with the device provider to create a unique device configuration that meets your corporate requirements. Back-door devices are ones that are brought into the corporate environment by individuals or groups who have procured the devices from a retailer or that have additional requirements preventing them from using front-door devices.

Your challenge will be to control both front-door and back-door devices, which you can do with ongoing device configuration, called provisioning, that can alter the security level settings and other features on an already functioning device.

For more information about the security features available on Windows Mobile powered devices and how they interact with Exchange ActiveSync, see the following white papers:

Security Considerations for Windows Mobile Messaging in the Enterprise at

Security Model for Windows Mobile 5.0 and Windows Mobile 6 at

Security Policies and Roles

The built-in security policy settings on Windows Mobile powered devices define levels of security. For example, security policies determine whether a device can be configured over the air (OTA), and whether it can accept unsigned messages, applications, or files. Security policy settings provide flexible control over authentication, data encryption, virtual private networking, Wi-Fi encryption, and SSL services. These policies are defined globally and enforced locally in their respective components at critical points across the device architecture.

Security roles, such as Manager or Enterprise, help to control access to device resources and define who can change each policy. The Manager role, usually reserved for the device manufacturer, allows complete control over the device. This is the role used to pre-load and configure settings on devices before they are purchased.

By default, only someone with Manager role permissions on the device can change most of the security policies. Using Mailbox Policies in Exchange ActiveSync, network administrators may use the Enterprise role to change the policies outlined in New Enterprise Features for Windows Mobile 6 and Exchange Server 2007 in this document. Additionally, if the OEM has given you Manager role permissions on your Windows Mobile powered devices, you can change all security policies on the device by provisioning.

Provisioning Windows Mobile Powered Devices

Provisioning refers to updating the device after manufacture, and involves creating a provisioning XML file that contains configuration information that specifies the attributes of features and security policies. The XML file is signed with a certificate and then transferred to the device, where the Configuration Service Providers configure the device based on the contents of the file.

A completed provisioning file can be delivered to a Windows Mobile powered device using any one of the following means:

  • OTA using an OMA DM Server
  • OTA using an OMA Client Provisioning (formerly WAP Client Provisioning) server
  • Wrapped in a .cpf file and sent using Internet Explorer Mobile, ActiveSync, SI/SL, or storage card.


Microsoft recommends that you provision the device using OTA methods when possible. If you must deliver the XML in a file, we recommend that you package and sign provisioning documents in the CAB Provisioning Format (.cpf). An XML provisioning document may not install on a Windows Mobile powered device if the file containing the document is not signed.


Cabinet files and each DLL and executable within a cabinet file must be signed, including resource-only DLLs.

For more information about provisioning devices that run Windows Mobile 6, see Windows Mobile Home on the MSDN Web site at