Client SSL Certificate Auth on Windows Mobile 6.5

Windows Mobile 6.5 utilized client-side SSL/TLS certificates to deliver secure, mutual authentication for enterprise devices accessing corporate gateways, such as Microsoft Forefront Unified Access Gateway (UAG), Forefront Threat Management Gateway (TMG), and Exchange ActiveSync endpoints. This mechanism eliminated or augmented standard password-based logins by requiring the mobile operating system to prove its identity cryptographically. This article explains the technical process of how Windows Mobile 6.5 stored certificates, executed the mutual TLS handshake, and allowed corporate reverse proxies to map user identities to internal network directories.

Certificate Enrollment and Storage

Before authentication could occur, both the user's digital certificate and the enterprise root Certificate Authority (CA) chain had to reside on the Windows Mobile 6.5 device. This deployment was typically managed through Microsoft System Center Mobile Device Manager (MDM), Simple Certificate Enrollment Protocol (SCEP), or over-the-air (OTA) provisioning via Exchange ActiveSync policies. Alternatively, administrators could package certificates into encrypted .pfx or .p12 files installed directly by users.

Windows Mobile 6.5 stored these credentials using the Windows CE Cryptographic Application Programming Interface (CryptoAPI):

  • Personal Store ("MY"): Contained the user's client certificate along with its corresponding private key, secured within the device’s internal protected memory.
  • Root Store ("ROOT"): Stored the trusted root CAs required to validate the identity of the corporate gateway.
  • Intermediate Store ("CA"): Held intermediate certificates necessary to construct a complete chain of trust.

The Mutual TLS Handshake Process

When an application on Windows Mobile 6.5—such as Pocket Internet Explorer or the native ActiveSync client—attempted to connect to an HTTPS corporate gateway, the network stack (WinINet/Schannel) initiated a standard mutual TLS (mTLS) handshake.

  1. Client Hello: The device initiated the connection by sending supported cipher suites and SSL/TLS versions to the corporate gateway.
  2. Server Hello and Certificate: The gateway responded with its server certificate. The Windows Mobile CryptoAPI validated this certificate against the device’s "ROOT" store to prevent man-in-the-middle attacks.
  3. Certificate Request: Crucially, the gateway sent a CertificateRequest message to the device. This payload contained a list of acceptable CA distinguished names that the gateway trusted for client authentication.
  4. Certificate Selection: The Windows Mobile Secure Channel (Schannel) security support provider inspected the device's "MY" store to find a certificate that matched the gateway's requested CA list and possessed the Client Authentication Enhanced Key Usage (EKU) attribute (OID 1.3.6.1.5.5.7.3.2). If multiple valid certificates existed, the OS prompted the user to select one; if only one matched, Schannel selected it automatically.
  5. Certificate Verify: The device sent the chosen public certificate to the gateway, followed by a CertificateVerify message. This message contained a cryptographic hash of all preceding handshake data, signed using the private key associated with the client certificate in the device's protected store.

Gateway Verification and Identity Mapping

Once the gateway received the client certificate and the signed verification data:

  • Cryptographic Verification: The gateway verified the signature using the client certificate's public key, confirming that the Windows Mobile device possessed the private key.
  • Chain Validation and Revocation: The gateway validated the certificate chain up to an internal enterprise root CA and checked certificate validity dates and Certificate Revocation Lists (CRLs).
  • Identity Mapping: The corporate gateway extracted identity identifiers from the certificate, typically the User Principal Name (UPN) located within the Subject Alternative Name (SAN) extension, or the Common Name (CN) within the Subject field.
  • Active Directory Authentication: Using mechanisms such as Kerberos Constrained Delegation (KCD) or native Active Directory client certificate mapping, the gateway translated the certificate into a valid Windows domain token.

Once mapped, the corporate gateway granted the device access to internal intranets, SharePoint portals, or Exchange mailboxes without requiring the user to transmit an Active Directory password across the network.