Certificate Revocation in Windows Mobile 6.5

Windows Mobile 6.5 handled compromised digital certificates through a combination of CryptoAPI-based Certificate Revocation List (CRL) processing, administrative certificate blacklisting, and device provisioning frameworks. Because the operating system operated on the Windows CE 5.2 core in an era of constrained cellular bandwidth and intermittent connectivity, automated real-time revocation was minimal, shifting the primary responsibility of handling compromised certificates to local store management and enterprise configuration pushes.

CryptoAPI and Certificate Revocation Lists (CRLs)

Windows Mobile 6.5 relied on the Windows CE Cryptographic Application Programming Interface (CryptoAPI) for handling Public Key Infrastructure (PKI). CryptoAPI supported traditional Certificate Revocation Lists (CRLs) through Certificate Distribution Points (CDPs) over HTTP and LDAP. When an application initiated a secure connection, CryptoAPI could theoretically retrieve and parse these published CRL files to verify that an intermediate or leaf certificate had not been revoked by the issuing Certificate Authority (CA).

However, dynamic CRL network checking was disabled or heavily restricted by default in most stock implementations of Windows Mobile 6.5. Mobile networks at the time suffered from high latency and data transfer costs; enforcing synchronous network lookups for every SSL/TLS handshake often led to severe application timeouts or connection failures when devices were offline.

The "Disallowed" Certificate Store

To block known compromised certificates without relying on live network lookups, Windows Mobile 6.5 utilized local certificate stores, including the "Untrusted" or "Disallowed" store (ROOT and Disallowed system stores).

Once a certificate's hash or public key was added to the Disallowed store, CryptoAPI immediately rejected any chain relying on it, regardless of the certificate's expiration date or network reachability. This method provided a deterministic, offline-capable way to neutralize compromised root and intermediate authorities.

Enterprise Provisioning and MDM (OMA DM / OMA CP)

System administrators revoked trust across fleets of Windows Mobile 6.5 devices through Mobile Device Management (MDM) channels, such as System Center Mobile Device Manager (SCMDM) 2008. These platforms leveraged:

• OMA Client Provisioning (OMA CP) and OMA Device Management (OMA DM): Administrators generated XML-based provisioning files (.provxml) that explicitly modified device security roles, removed compromised CA certificates from the root store, or injected blacklisted certificates into the untrusted store.
• Signed CAB Files: Administrators packaged certificate store modifications into digitally signed cabinet (.cab) files distributed via ActiveSync, file transfers, or enterprise application portals.

Firmware and ROM Updates

For deeply integrated root certificates hardcoded into system images, Original Equipment Manufacturers (OEMs) and carriers distributed updates via updated ROMs or General Distribution Release (GDR) packages. These system-level updates replaced the default root certificate database stored in the device's read-only memory (ROM).

Absence of Native OCSP

Windows Mobile 6.5 lacked native operating system-level support for the Online Certificate Status Protocol (OCSP). Unlike modern mobile platforms that perform lightweight, real-time OCSP stapling checks, Windows Mobile 6.5 did not implement an OS-wide OCSP client. Consequently, direct software-based revocation on the platform remained divided between resource-intensive CRL downloads and administrative, push-based local certificate revocation.