Most importantly, adding the root certificate on the AOS switch is noted as an automatic task, which is a stark difference as seen on AOS-CX.
In sharp contrast, the Aruba OS-CX switch utilizes Downloadable User Roles (DURs), which centralize the policy definition and change the enforcement delivery method entirely. With DURs, all complex role parameters, including VLANs (e.g., VLAN 100, VLAN 120), classes and policies are configured centrally on ClearPass using an extensive GUI. ClearPass generates the complete CLI script for the user role. To deliver this policy, the switch does not rely on a RADIUS VSA trigger; instead, the AOS-CX switch must execute a REST API call over SSL to ClearPass to download the full role script when it is required for an endpoint. Since DURs are downloaded as needed, they are volatile and stored only in memory, being removed upon reboot, which is a key distinction from the persistent LURs used on AOS switches.
To enable this secure API communication, the trust model shifts from RADIUS shared secrets to certificate-based authentication, the switch must have NTP and DNS configured, and the ClearPass root certificate must be manually imported into a trusted anchor profile (pki ta profile) on the AOS-CX switch. Additionally, a dedicated downloadable user role account (e.g., duradmin) must be created on the switch and authenticated to ClearPass with the aruba user role download privilege level, granting the switch permission to execute the download.
This diagram summarizes the difference:
Swaitlana Agnihotri
What actually happened
In our case, all endpoint devices had already been updated with the new Sectigo root certificate, and ClearPass itself was fully migrated from Entrust to Sectigo, so everything appeared aligned on the surface. The issue emerged only where there was port bounce or reboot on these switches, leading for Re-auth again for clients connected. Once ClearPass began presenting the new Sectigo chain, the switches no longer trusted its HTTPS identity as they still had Entrust certificate on them, causing authentication failures. ArubaOS switches were generally able to recover automatically by redownloading the correct certificate after reboot or during RADIUS communication, though a few required the RADIUS configuration to be removed and re-added to trigger a fresh certificate fetch.
However, ArubaOS-CX switches could not recover on their own because they rely on a manually imported trusted anchor, with the Entrust root now invalid; DUR downloads failed immediately after any reboot or port bounce. Endpoints could authenticate at the RADIUS level, but the switch could not download their required roles, leaving them unable to join the network.
