Aruba ClearPass EAP-TLS Onboarding Failures: Diagnosing Certificate and "Unknown User" Errors

Certificate validation is time-sensitive on both ends of an EAP-TLS exchange. A client or RADIUS server certificate that is technically valid can still be rejected if the device performing the check believes the current date falls before the certificate's issue date or after its expiration date. This is not a hypothetical edge case: devices that have been powered off for an extended period, factory-reset without a network connection to sync time, or that rely on a cellular carrier or Wi-Fi connection for their initial clock sync can boot with a default date that predates the certificate entirely. Documented Android 11 cases have shown ClearPass logging a TLS handshake failure with an alert describing the server certificate as expired, when the actual fault was the device clock reading a date before the certificate's issue date rather than the certificate being genuinely out of its validity window. The symptom on the wire looks identical to a real expired certificate, which is what makes it easy to misdiagnose as a ClearPass certificate lifecycle problem when the certificate itself is fine.

Android 11 changed how the OS validates a RADIUS server's certificate during 802.1X authentication compared to Android 10, actively checking the certificate chain and, in some configurations, requiring the server certificate's domain to be explicitly entered in the Wi-Fi profile's Domain field rather than left blank. A device that onboarded successfully under an older Android version, or that was provisioned with a Wi-Fi profile built before this validation behavior existed, can start failing after an OS update with no change on the ClearPass side at all. Community reports describe this surfacing as an "untrusted certificate" error on the device even when certificate validation was believed to be disabled, or even after a trusted certificate was manually installed, because the missing Domain field caused the OS to reject the chain regardless. This is functionally an OS-vendor behavior change landing on top of an existing ClearPass Onboard configuration, not a ClearPass defect, but it produces symptoms indistinguishable from one unless the device's OS version and Wi-Fi profile configuration are specifically checked.

Not every failure originates on the device. A ClearPass Onboard-issued client certificate can be revoked deliberately, through a certificate revocation list update, a device removed from the endpoint repository, or a change to which certificate authority the 802.1X service trusts, and any of these will produce an authentication failure that has nothing to do with the device's clock or OS. A generic "user not found" or unknown user rejection specifically points at the authentication source rather than the certificate itself: the EAP-TLS service's configured authorization source no longer contains a record matching the certificate's subject, either because the underlying Active Directory or local user account was disabled or deleted, or because the endpoint's entry in ClearPass's own device repository was removed during a cleanup pass. A root CA rotation on the Onboard certificate authority without a corresponding update to the trusted root deployed to already-onboarded devices produces the same downstream symptom from the opposite direction: the device presents a certificate chaining to a root ClearPass itself no longer trusts.

Start in ClearPass's Access Tracker, filtered to the failing device's MAC address or certificate subject, before assuming anything about the device. If no request appears at all for the attempted authentication, the failure is upstream of ClearPass, most likely a network access device or switch port issue, not a certificate or user problem. If a request appears with an explicit rejection reason, that reason narrows the cause immediately: a certificate-related alert (expired, not yet valid, untrusted issuer) points at the clock, OS validation, or CA trust chain causes above, while a user-not-found or authentication-source rejection points at the directory or endpoint repository. Cross-reference the rejection against the Event Viewer for the same time window to catch anything the Access Tracker summary alone doesn't surface, particularly Winbind or Active Directory join issues that can produce a user-not-found result even when the account genuinely exists. Before assuming a certificate defect, check the device's actual current date and time against the certificate's stated validity window and the device's OS version and build date against known validation-behavior changes for that platform.

For a device confirmed to have an incorrect clock, correcting the date and time and forcing a reconnect resolves the immediate failure, but the durable fix is making sure the device has a reliable time source before it ever attempts 802.1X authentication, since a device that syncs time only after joining the network has a chicken-and-egg problem when the network access itself depends on a correct clock. For managed devices, an MDM-pushed NTP configuration applied before the 802.1X profile is delivered avoids this. For devices that only get time from cellular or from the network they are trying to join, a captive onboarding SSID or wired path that does not depend on certificate validation, used only long enough to sync time and complete an initial handshake, avoids stranding a device that has never had a chance to get its clock right.

For devices failing due to stricter certificate validation after an OS update, update the device's Wi-Fi or 802.1X profile to explicitly populate the RADIUS server's domain in the Domain or server identity field rather than leaving it blank, and confirm the full certificate chain, not just the leaf certificate, is installed as trusted on the device. Where devices are managed, push this as an updated Wi-Fi profile through MDM rather than relying on per-device manual correction, since the same OS-level change affects every device on that platform version, not just the one that happened to generate a help desk ticket. Where ClearPass Onboard provisions the Wi-Fi profile as part of enrollment, confirm the Onboard provisioning template itself has been updated to populate the domain field for newly onboarded devices, otherwise every new enrollment on an affected OS version reproduces the same failure going forward.

For a user-not-found rejection, confirm first whether the underlying account in Active Directory or the local user repository is still active, since a disabled or deleted account will produce this symptom regardless of anything correct on the certificate side. If the account is active, check whether the device's entry was removed from ClearPass's own endpoint repository during a device cleanup or inactivity policy, which severs the mapping between a still-valid certificate and an authorization decision. For a certificate revoked or rejected due to a CA trust chain change, confirm the 802.1X service's trusted certificate authority list includes the current Onboard-issuing CA and, if a root rotation occurred, that the new root has been distributed to already-onboarded devices, not just applied to newly issued certificates, since a rotation that only updates future certificates leaves the entire existing device population unable to validate against the new trust anchor.

After a clock or time-sync fix, do not consider the device resolved after one successful authentication; power-cycle the device or let it sit disconnected long enough to test whether the clock drifts again before the next NTP sync, since a device that only syncs time infrequently can pass a same-session retest and still fail on its next cold boot. After a Wi-Fi profile or trust chain update pushed through MDM, confirm the change actually reached the affected device population, not just the one device used for testing, by checking Access Tracker for a broader sample of devices on the same OS version over the following day. After a directory or endpoint repository fix, re-check Access Tracker for the specific device or user to confirm the authentication now resolves through the intended authorization source rather than succeeding for an unrelated reason, such as a fallback authentication method that happens to be enabled on the same service.

A device whose clock was manually corrected once can drift back to an incorrect date if it has no persistent time source and its battery-backed clock is failing, producing a recurrence weeks later that looks like the same bug reappearing when it is actually a hardware issue on that specific device. A Wi-Fi profile update pushed through MDM can fail silently on devices that are offline or unenrolled from management at the time of push, leaving a subset of the fleet still running the old profile and still failing, which is easy to miss if validation only checks a small sample. A CA trust chain fix that updates the RADIUS service's trusted authorities but does not redistribute the new root to already-onboarded devices resolves authentication for newly onboarded devices while leaving the existing device population failing, which reads as an incomplete fix rather than the two genuinely separate problems it actually is.

Escalate to whoever owns device management (MDM) when the fix requires a fleet-wide Wi-Fi profile or trust anchor update rather than a per-device correction, since pushing that change is outside what a NAC administrator can do from ClearPass alone. Escalate to the PKI or certificate authority owner when diagnostics point to a CA rotation or trust chain issue affecting the Onboard-issued certificate population broadly, since redistributing a new root to an existing device fleet is a distinct project from anything configurable inside ClearPass's own policy service. Escalate to Aruba support directly when Access Tracker and Event Viewer both show a request reaching ClearPass with correct device time, a valid and trusted certificate chain, and an active directory account, and the authentication still fails, since at that point the fault is most plausibly in ClearPass's own service configuration or a platform defect that needs Aruba's own diagnostics to isolate. For background on how EAP-TLS and 802.1X fit into a broader NAC deployment, see our network access control overview.