Windows Mobile 6.5 Certificate Error Override Options

Windows Mobile 6.5 handled Secure Sockets Layer (SSL) and Transport Layer Security (TLS) certificate errors through native prompts within Internet Explorer Mobile and the underlying WinINet network stack. When users encountered an invalid, untrusted, or expired security certificate, the operating system generated a modal warning dialog that halted page loading and offered specific actions. This article details the certificate error override options available to users in Windows Mobile 6.5, the certificate details they could inspect, and the security constraints that restricted these overrides.

The Warning Dialog and User Choices

When an encrypted connection failed validation in Windows Mobile 6.5, the browser displayed a prompt stating the nature of the issue (such as a date mismatch, untrusted authority, or mismatched host address). Beneath the warning text, users were generally presented with three distinct actions:

  • Yes (Continue): This option allowed the user to bypass the security warning. Selecting "Yes" temporarily accepted the problematic certificate for the current browsing session, allowing the webpage or secure asset to load despite the validation failure.
  • No (Cancel): This was the safe, default choice. Selecting "No" aborted the connection request immediately, preventing data transmission to the unverified server and returning the user to the previous page or a blank screen.
  • View Certificate: This option opened a secondary inspection screen detailing the technical properties of the certificate.

Information in the "View Certificate" Screen

Choosing to view the certificate allowed technical users and administrators to troubleshoot the exact cause of the validation failure before deciding to override it. This view provided:

  • Subject / Issued To: The common name (CN) and organization associated with the site, revealing whether there was a domain name mismatch.
  • Issuer / Issued By: The Certificate Authority (CA) that signed the certificate, allowing the user to verify if the root CA was missing from the Windows Mobile 6.5 trust store.
  • Validity Period: The "Valid From" and "Valid To" dates, clarifying whether the certificate had expired or if the mobile device's local system clock was set incorrectly.

From the certificate details screen, users could return to the original prompt to select either "Yes" to proceed or "No" to decline.

Error Types Subject to Overrides

Internet Explorer Mobile presented override prompts for the following common SSL/TLS discrepancies:

  1. Expired or Not Yet Valid Certificates: Triggered when the current date on the device fell outside the certificate’s validity window.
  2. Name Mismatches: Triggered when the URL entered into the browser did not match the Common Name (CN) or Subject Alternative Name (SAN) specified in the certificate.
  3. Untrusted Root Authorities: Triggered when the certificate was self-signed or issued by an intermediate/root authority not pre-installed in the Windows Mobile root certificate store.

Administrative Restrictions and Blocked Overrides

While end users typically had the power to bypass certificate warnings, overrides could be restricted or modified depending on device configuration:

  • Enterprise Security Policies: System administrators managing fleets via Microsoft System Center Mobile Device Manager (SCMDM) or Exchange ActiveSync could enforce security policies that completely disabled the ability to ignore certificate errors.
  • Hard Validation Failures: In instances where a certificate was explicitly revoked (if Certificate Revocation List checking was enabled and reachable) or fundamentally malformed, the operating system would terminate the connection without providing a "Yes" override option, presenting only an acknowledgment prompt (such as "OK" or "Close") to dismiss the error.