Export (0) Print
Expand All

Step 6: Certificate Enrollment and Phone Provisioning

7/2/2010

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

Digital certificates play a significant role in network authentication and in helping to secure a phone. Certificates are electronic credentials that bind the identity of the certificate owner or the phone 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, phone, organization, or person, and that they can be trusted.

Digital certificates are used on Windows® phones 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 phone and if so, the permissions (privileged or normal) with which it will run.

For example, to authenticate with a network, the phone 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 phone, the application must present a digital certificate that proves it was accepted and signed by a trusted source.

Certificates Shipped on Windows® Phones

By default, Windows® phones 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® phones
  • Additional certificates that may be added by the OEM or mobile network operator

The following table lists the certificates shipped with phones that run the Windows Mobile 6.5 operating system as of the publishing date of this deployment guide.

Vendor Certificate name

Comodo

AAA Certificate Services

Comodo

AddTrust External CA Root

Cybertrust

Baltimore CyberTrust Root

Cybertrust

GlobalSign Root CA

Cybertrust

GTE CyberTrust Global Root

Verisign

Class 2 Public Primary Certification Authority

Verisign

Thawte Premium Server CA

Verisign

Thawte Server CA

Verisign

Secure Server Certification Authority

Verisign

Class 3 Public Primary Certification Authority

Entrust

Entrust.net Certification Authority (2048)

Entrust

Entrust.net Secure Server Certification Authority

Geotrust

Equifax Secure Certification Authority

Geotrust

GeoTrust Global CA

Godaddy

Go Daddy Class 2 Certification Authority

Godaddy

http://www.valicert.com/

Godaddy

Starfield Class 2 Certification Authority

Certificate Stores

The certificates in a Windows® phone reside in the certificate store in the registry. In the Windows Mobile 6.5 software, the certificate store includes separate User Root and Certification Authority stores to allow phone 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.

The following table shows the certificate stores on phones that run the Windows Mobile 6.5 operating system, and their uses and permissions.

Certificate store Physical Store Description

Privileged Execution Trust Authorities

HKLM

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

Unprivileged Execution Trust Authorities

HKLM

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).

SPC

HKLM

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

Root (system)

HKLM

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)

HKCU

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

CA (system)

HKLM

Contains certificates and information from intermediary certification authorities. They are used for building certificate chains. In Windows Mobile 6.5, 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)

HKCU

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

MY

HKCU

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 phone 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 phone in order to enable trust validation.

Exchange ActiveSync relies on SSL to help secure the connection between the Windows® phone and the Exchange Client Access server. The client phone 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 client access server in order to establish a secure connection.

Windows® phones 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 phones will be able to access your corporate network by entering their domain, name, and password.

Ff459604.note(en-us,TechNet.10).gifNote:
Wildcard certificates, which are certificates not supplied by a Microsoft Certification Authority server, can be used with Windows Mobile 6.5.

Windows Mobile 6.5 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. Together Windows® phone and Windows Server 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® phone, the phone must contain the root certificate for the Client Access Exchange Server it is communicating with; the phone 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.

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 phones can be a daunting task. With Windows Mobile-based software and desktop Exchange 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.5 software and Exchange 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
Ff459604.note(en-us,TechNet.10).gifNote:
The process for adding certificates differs between Windows Mobile 6 and Windows Mobile 6.5.

Adding Certificates to Windows® phones

With Windows® phones that run the Windows Mobile 6.5 operating system, 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 phone. You can also distribute the encrypted certificate/key pair required for certificate-based authentication or 802.1x wireless connection using ActiveSync Desktop enroll.

The certificate installer in Windows Mobile 6.5 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 phone

The files can be delivered to the phone using desktop ActiveSync, Windows Mobile Device Center (WMDC), removable storage card, e-mail attachment, or Mobile Internet Explorer file download. Phones that run Windows Mobile 6.5 operating system 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.

Ff459604.note(en-us,TechNet.10).gifNote:
Those with User role permissions can install a certificate on a Windows® phone by copying the CAB or .cer file to the phone and running it. However, in order to enroll for a certificate from a Certification Authority, your phone users should use either the desktop application, Microsoft ActiveSync (for Windows XP or previous clients), or Windows Mobile Device Center - WMDC (for Windows Vista or newer clients).

Using Desktop Enrollment with Microsoft ActiveSync

The desktop application, Microsoft ActiveSync, enables users with cradled Windows® phones 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 phones. 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 phones.

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 phone users to enroll for the certificate, the users will step through the following process:

To enroll for a certificate with a Windows® phone

  1. Using ActiveSync, synchronize your Windows® phone with a desktop PC and log into the corporate network in the same domain as the certificate enrollment server.
    Ff459604.ca6ce4fc-95ee-4099-8b3e-48ee4b0a238f(en-us,TechNet.10).jpg
  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.
    Ff459604.749bcb4d-d4c9-430d-9db5-c58f768fde5d(en-us,TechNet.10).jpg
  3. Under Get Device Certificate, click Yes to proceed.
  4. To approve the certificate request on a phone that is based on the Windows Mobile 6.5 operating system, a screen prompt will ask you to confirm the installation process. Click Continue on the phone
  5. A second prompt may appear on the phone asking if you wish to install the certificate or block this request. Choose Install.
  6. The desktop processes the enrollment. During this time, the phone 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 phone.
  8. The phone 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 phone, 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, and then Close.

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

Using Desktop Enrollment with Windows Mobile Device Center (WMDC)

The desktop application, Microsoft WMDC, enables users with cradled Windows® phones 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 phones. 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 phones.

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 WMDC Get Device Certificate feature on the desktop PC

Once you have published the certificate to Active Directory and directed phone users to enroll for the certificate, the users will need to step through the following process to install the certificate on their Windows phones.

To enroll for a certificate with a Windows® phone using WMDC

  1. Using Windows Mobile Device Center, synchronize your Windows® phone with a Vista PC, and log into the corporate network in the same domain as the certificate enrollment server. Click Mobile Device Settings, then click more>>.
    Ff459604.42b9c7d0-84c9-42d8-9b95-05d57522c9e5(en-us,TechNet.10).jpg
  2. From Mobile Device Settings, choose Get device certificates.
    Ff459604.5ecf2033-0590-4731-9dca-0a3c4f1181c0(en-us,TechNet.10).jpg
  3. Under Get device certificates, click I need to configure enroll, or manage a custom certificate type (Advanced) to proceed.
    Ff459604.8a895bfe-a641-471e-a36d-e714eed57b2b(en-us,TechNet.10).jpg
  4. To approve the certificate request on a Windows Mobile 6.5 phone, a screen prompt will ask to confirm the installation process. Click Continue on the phone, and then click ADD on the WMDC screen.
    Ff459604.f9434d30-b93d-41b1-b0e8-91605a5f2cee(en-us,TechNet.10).jpg
  5. Enter the Certificate type name and Certificate server name. Select the This server requires an encrypted (SSL) connection checkbox. Select the certificate template name as ExchangeUser.
    Ff459604.668e7827-6944-4756-b70e-8824b25e2e63(en-us,TechNet.10).jpg
  6. A prompt may appear on the phone asking if you wish to install the certificate or block this request. Choose Install.
  7. The desktop processes the enrollment. During this time, the phone generates a public/private key set and sends the enrollment to the Windows Certificate Server through the desktop.
  8. The Certification Authority returns a signed certificate to the desktop, which in turn delivers the certificate to your phone.
  9. The phone 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 phone, you will be asked to accept the certificate.
  10. Finally, click the Enroll button to complete the process.
    Ff459604.a98d922e-6b7a-4cba-82b6-1c56a98cb979(en-us,TechNet.10).jpg

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® phones and how they interact with Exchange ActiveSync, see the following white papers:

Security Considerations for Windows Mobile Messaging in the Enterprise

Security Policies and Roles

The built-in security policy settings on Windows® phones define levels of security. For example, security policies determine whether a phone 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 phone architecture.

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

By default, only someone with Manager Role permissions on the phone 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.5 and Exchange Server 2010 in this document. Additionally, if the OEM has given you Manager Role permissions on your Windows® phones, you can change all security policies on the phone by provisioning.

Provisioning Windows® phones

Provisioning refers to updating the phone 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 phone, where the Configuration Service Providers configure the phone based on the contents of the file.

A completed provisioning file can be delivered to a Windows® phone 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, Exchange ActiveSync, SI/SL, or storage card.
Ff459604.note(en-us,TechNet.10).gifNote:
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® phone if the file containing the document is not signed.
Ff459604.note(en-us,TechNet.10).gifNote:
Cabinet files and each DLL and executable within a cabinet file must be signed, including resource-only DLLs.

For more information about provisioning phones that are based on the Windows Mobile 6.5 operating system, see Windows Mobile Home on the Microsoft Developer Network (MSDN) Web site.

Was this page helpful?
(1500 characters remaining)
Thank you for your feedback
Show:
© 2014 Microsoft