Apple Device Support: iPad Fleet Loses Wi-Fi After Certificate Renewal

iPad Fleet Loses Wi-Fi After Certificate Renewal

A school manages 300 iPads with MDM. They connect to School-WiFi, which uses WPA2-Enterprise with 802.1X and a RADIUS server whose server certificate is issued by the school's internal CA. The CA certificate is delivered in the Wi-Fi payload. The RADIUS server certificate expires and is renewed. The IT team installs the new certificate on the RADIUS server but does not change the CA. Within a day, iPads begin failing to join School-WiFi; they show "Unable to join network." A few iPads that were powered off during the change still connect when turned on, then fail after a reboot. Teacher Macs on the same network are unaffected. The MDM admin confirms the Wi-Fi payload has not changed.

1. Explain why the iPads fail while the teacher Macs do not, and why powered-off iPads worked briefly.

Read the worked answer

The failure is a server-certificate trust problem on the iPads, exposed by the RADIUS certificate renewal.

iPads validate the RADIUS server certificate against the CA certificate installed via the Wi-Fi payload. If the renewed server certificate was issued by a different CA (or an intermediate that the iPads don't trust), the 802.1X handshake fails and iOS/iPadOS reports "Unable to join network." The MDM admin says the payload didn't change - but the payload contains the old CA, and the new server cert chains to a CA the iPads don't have.
Teacher Macs are unaffected because macOS and iOS handle trust differently in practice: the Macs may have the new CA installed through another path (e.g., a previously trusted root, a profile, or manual install), or they may be configured to not strictly validate the server cert. The asymmetry is a clue, not a contradiction.
Powered-off iPads worked briefly because they had not yet re-run the 802.1X handshake against the new certificate. Once they rebooted and attempted a fresh join, they hit the same validation failure. This is consistent with a trust-chain problem rather than a network outage.

Next step: compare the new server certificate's issuer chain with the CA certificate in the Wi-Fi payload using openssl s_client against the RADIUS server, and inspect the payload's installed CA on a failing iPad.

2. What is the correct fix, and how would you roll it out to 300 iPads with minimal disruption?

Read the worked answer

Correct fix: ensure the iPads trust the CA that issued the renewed RADIUS server certificate.

Confirm the chain. On a test machine, run openssl s_client -connect <radius>:<port> -showcerts and identify the issuing CA of the new server certificate. Compare with the CA certificate currently in the Wi-Fi payload.
Update the payload. If the issuer changed, add the correct CA certificate to the Wi-Fi payload (or a separate certificate payload) and push via MDM. If only the leaf certificate was renewed under the same CA, the payload should already be correct - in that case verify the server is actually presenting the new leaf and not an old one from a secondary path.
Test on a small pilot. Push to 3–5 iPads, reboot them, and confirm they join School-WiFi reliably across multiple reboots.

Rollout with minimal disruption:

Push the updated profile during a low-use window (e.g., after school hours).
Because profile updates can require re-authentication, communicate to staff that devices may prompt to rejoin Wi-Fi.
Monitor MDM compliance/connection status to catch devices that fail to pick up the new profile.
Keep the old CA in the payload temporarily if both old and new server certs may be in use during transition, then remove it once the new cert is confirmed everywhere.

This avoids a mass re-enrollment and keeps the change declarative and reversible.