Wired 802.1X Lab Drops After a CA Migration
Eighty-five Mac minis in a teaching lab authenticate to wired 802.1X with EAP-TLS using machine certificates. Certificates come from SCEP through the MDM server against an internal Microsoft CA. In July the PKI team replaces the old single-tier root with a new two-tier hierarchy; the old root expires 31 December. The MDM SCEP URL now points at the new NDES endpoint. In September, six Macs fail first, then 40. The switch port stays unauthorized, and macOS shows a certificate-selection prompt listing both old and new certificates. The log shows 'trust evaluation failed' for the new intermediate. There is no Wi-Fi in the lab, and the minis use static addresses for imaging. Student accounts are network accounts. The lab switch uses a fallback VLAN for unauthenticated devices, but that VLAN has no route to the MDM server.
1. The log says trust evaluation failed for the new intermediate, and some Macs show a certificate chooser. Diagnose the failure and explain why it spread from 6 to 40 Macs.
Read the worked answer
The new leaf certificate chains to the new intermediate and root. If the new root is not in the System keychain or a trusted-certificate payload, the TLS supplicant cannot build a trusted chain to the server, so EAP-TLS fails and the port stays unauthorized. The chooser appears because the 802.1X payload now matches more than one identity, old and new, and the supplicant has no unambiguous issuer or subject match. Spread is explained by SCEP renewal: each Mac renews on its own schedule, so the population migrates in waves as certificates expire or the MDM profile is reinstalled. The old root still works, which is why only renewed Macs fail. This is not a switch problem or a user password problem; the evidence points to a missing trust anchor deployed after, not before, the SCEP endpoint change.
2. State the correct deployment order and the rollback point, given the old root expires on 31 December.
Read the worked answer
Trust must precede issuance: distribute the new root, and intermediate if it is not auto-fetched, as a trusted-certificate payload to all 85 Macs; verify it is present and trusted; only then point SCEP at the new NDES endpoint and allow renewal. Keep the old root trusted and the old SCEP endpoint available until every Mac has a new identity and has authenticated successfully. The rollback point is before the old root is removed: if the new chain fails, revert the 802.1X payload to the old issuer and keep the old root past the cutover. The hard constraint is the 31 December expiry, so the root payload must be delivered weeks earlier, not in the same change window. Because these Macs have no Wi-Fi and the fallback VLAN cannot reach MDM, delivery needs an out-of-band path: a temporary MAB or open staging VLAN, or a local admin installing the root from removable media.
3. How would you verify the fix on one Mac and recover the 40 without hand-installing certificates on all of them?
Read the worked answer
On one Mac, confirm the root is in the System keychain, inspect the 802.1X profile's allowed issuers, and check the EAPOL client log during a port authentication. The identity list should show a single preferred identity for the new issuer. Then renew the certificate and confirm the switch authorizes the port. For the 40, avoid hand-installing: use a temporary provisioning VLAN that permits MDM traffic, push the root and corrected 802.1X payload, then renew SCEP. If MDM cannot reach them because 802.1X is the only path, a local admin or a scripted package on removable media is the fallback; the script should install the root and select the new identity, not just delete old certificates. Track success by port authorization and by security find-identity output, and do not remove the old root until the count reaches 85.