Skip to content

Troubleshooting Android EAP-TLS Wi-Fi (Error 0x87d1fde8)

Android Enterprise devices have two certificate requirements that, when missed, cause an EAP-TLS Wi-Fi profile to fail — usually without a clear error. This guide covers the most common Android-specific failure and how to work through it methodically.

Symptom

  • The Wi-Fi (or VPN) configuration profile fails to apply on an Android Enterprise device.
  • Intune reports error 0x87d1fde8 (decimal -2016281112) against the profile.
  • The certificate itself may show as deployed, which makes this easy to misdiagnose as a RADIUS or network problem when the root cause is on the certificate/profile side.

Root cause

Android validates the client certificate — including its Subject Alternative Name (SAN) — before it applies the Wi-Fi profile. The two conditions that trigger this are:

  1. Wrong certificate type. On a BYOD Work Profile, the SCEP certificate must be a User certificate. A Device certificate enrols but the Work Profile network stack cannot bind to it, so the profile fails silently.
  2. Missing UPN in the SAN. The User Principal Name (UPN) must be present in the SAN as an otherName entry (OID 1.3.6.1.4.1.311.20.2.3). A UPN in the Common Name (CN) alone is not sufficient for Android.

Both are configured in the Intune SCEP profile that issues the certificate. See the EasyScep Android Enterprise setup section for the exact settings.

Diagnostic decision tree

Work through the checks in order. Each step tells you where to go next.

  • 1. Is this a BYOD Work Profile enrolment?

    • Yes → go to step 2.
    • No / not sure (corporate-owned, fully managed) → the User-vs-Device rule differs for fully managed devices; still complete steps 3–5, then contact support@just-software.com if unresolved.

  • 2. Is the SCEP profile issuing a User certificate (not a Device certificate)?

    • No (Device certificate) → This is the most common cause. Change Certificate type to User in the Intune SCEP profile, re-issue, and re-test. → step 3.
    • Yes (User certificate) → go to step 3.

  • 3. Does the issued certificate contain the UPN in the SAN as an otherName (OID 1.3.6.1.4.1.311.20.2.3)?

    • No (UPN only in the CN, or no UPN at all) → add the SAN attribute User principal name (UPN) = {{UserPrincipalName}} to the SCEP profile, re-issue, and re-test. → step 4.
    • Yes → go to step 4.

  • 4. Does the SCEP profile have the Client Authentication EKU (1.3.6.1.5.5.7.3.2) and chain to the Root CA trusted on the device?

    • No → correct the EKU and/or deploy the Root CA trust profile to the device, re-issue, and re-test. → step 5.
    • Yes → go to step 5.

  • 5. After re-issuing, force an Intune sync on the device and confirm the new certificate is present, then re-apply the Wi-Fi profile.

    • Profile now applies → resolved.
    • Still failing → the issue is likely no longer certificate-related; continue with the general EAP-TLS Authentication Troubleshooting in the FAQ (RADIUS client config, server certificate validation, connectivity) or contact support@just-software.com with the device details and exact error.

How to verify the certificate contents

Before assuming a RADIUS-side problem, confirm what was actually issued:

  • Inspect the issued certificate (on the device where possible, or via the EasyScep administration portal) and check that:
    • The Subject Alternative Name lists the user's UPN (as Other Name / Principal Name), not just a CN.
    • The Enhanced/Extended Key Usage includes Client Authentication (1.3.6.1.5.5.7.3.2).
    • The certificate chains to the Root CA that is deployed as a trusted certificate on the device.