Windows Mobile 6.5 Certificate Management

Windows Mobile 6.5 relied on a centralized certificate infrastructure inherited from Windows CE to establish secure connections for Exchange ActiveSync, corporate Wi-Fi, VPNs, and secure web browsing. This article provides an overview of how the operating system stored, installed, and validated digital certificates, highlighting the internal architecture and administrative mechanisms used to ensure secure mobile communication.

The Certificate Store Architecture

Windows Mobile 6.5 utilized the Microsoft CryptoAPI (CAPI) to manage digital identities and trust relationships. The system organized certificates into distinct logical certificate stores:

  • Privileged Root (Trusted Root Certification Authorities): Contained trusted root certificates required to validate secure infrastructure, system-level software signing, and core operating system operations.
  • Unprivileged Root: Contained third-party root certificates used for standard user tasks, such as browsing SSL/TLS websites in Internet Explorer Mobile without administrative privileges.
  • Intermediate Certification Authorities (CA): Held intermediate certificates required to establish a complete trust chain from a client or server certificate back to a trusted root.
  • Personal ("My") Store: Stored user and device certificates containing private keys, primarily used for mutual authentication (client certificate authentication) for corporate email, VPN connections, and 802.1X wireless networks.

Certificate Deployment and Installation Methods

System administrators and end-users had multiple pathways to deploy certificates onto Windows Mobile 6.5 devices:

Direct File Installation

Users could transfer standard certificate formats—such as .cer, .der, or .p7b (public keys) and .pfx or .p12 (Personal Information Exchange files containing private keys)—to the device via storage card, email attachment, or direct download. Opening the file in the device’s File Explorer triggered the built-in certificate installer. For .pfx files, the system prompted the user to input the password protecting the private key.

Over-the-Air (OTA) and Device Management

Enterprise environments deployed certificates remotely using Open Mobile Alliance Device Management (OMA DM) or OMA Client Provisioning (OMA CP). Through management platforms like Microsoft System Center Mobile Device Manager (SCMDM), administrators pushed XML provisioning files (e.g., using the CertificateStore configuration service provider) directly to enrolled devices without user intervention.

Custom CAB Files and Provisioning XML

Administrators bundled certificates into signed CAB installation files using the Microsoft Windows Mobile SDK. These files contained _setup.xml provisioning instructions that automatically injected the included certificates into their appropriate target stores during application or profile setup.

Use in Secure Connections

Windows Mobile 6.5 applied installed certificates across several key network protocols:

  • Exchange ActiveSync: The mail client relied on the Trusted Root store to validate the SSL/TLS certificate of the Microsoft Exchange Client Access Server. If an organization implemented certificate-based authentication, the mail client extracted the user's certificate from the Personal store to authenticate rather than relying solely on basic username-password pairs.
  • Enterprise Wi-Fi (802.1X): Secure wireless networks using EAP-TLS required the network's root certificate in the Root store and a matching client certificate in the Personal store to grant network access.
  • Virtual Private Networks (VPN): L2TP/IPsec connections used the system's certificate stores for machine authentication to establish secure tunnels back to corporate networks.
  • Web Browsing: Internet Explorer Mobile checked public SSL/TLS web certificates against the Root and Intermediate stores to prevent man-in-the-middle attacks, issuing warning dialogs if a certificate was expired, untrusted, or mismatched to the host domain.

Validation and Limitations

While Windows Mobile 6.5 provided an enterprise-ready public key infrastructure (PKI) framework, it featured constraints typical of mobile operating systems of its era. By default, Certificate Revocation List (CRL) checking was often disabled or limited to preserve mobile bandwidth and prevent latency when establishing connections over cellular networks. Administrators could alter this behavior through Windows Registry modifications, balancing high-security requirements against network performance.