Intune WiFi profile server trust: certificate server names and root CA checklist for Entra ID

To establish Intune WiFi profile server trust with Microsoft Entra ID integration, match your certificate server names to your RADIUS server certificate. Deploying this IEEE 802.1X standard across 80,000+ venues requires linking a trusted certificate profile containing the root CA to the same Entra ID group to prevent authentication handshake failures.

What does server validation in an Intune WiFi profile actually do?

An enterprise WiFi profile in Intune has two halves. The client half proves who the device is. The server half proves the network belongs to you. Most stalled rollouts fail in the server half, so this guide covers that half only.

A few definitions first. IEEE 802.1X is the port-based access control standard. It holds a device off the network until a RADIUS (Remote Authentication Dial-In User Service) server approves it. EAP-TLS (Extensible Authentication Protocol with Transport Layer Security, RFC 5216) authenticates both sides with certificates. PEAP (Protected EAP) wraps a password exchange inside a TLS tunnel.

In both methods, the RADIUS server presents its certificate first. The device decides whether to trust it before it sends a certificate or password.

Checks and decisions

The device runs two tests on the RADIUS server certificate:

• Chain of trust. Does the certificate chain up to a root certificate authority (CA) that the profile names? In Intune, that root arrives on the device as a trusted certificate profile.
• Identity. Does the name on the certificate match the certificate server names field? On Windows, iOS and macOS the field has that name. On Android Enterprise it is the Radius server name field.

Both tests must pass. A certificate from a trusted CA with the wrong name fails. The right name from an unlisted CA also fails. This pairing blocks a rogue access point that presents a valid certificate for someone else's domain. That attack harvests PEAP credentials from devices that skip validation.

Why failures stay hidden

Intune reports whether a profile reached the device. It does not report whether the device accepts your RADIUS server. A profile can show as succeeded while every handshake fails at the access point. You only see the problem when staff report that the network will not connect.

What do you need before you start?

Collect these items before you open Intune:

• The live RADIUS server certificate. Record the subject common name (CN), every subject alternative name (SAN) DNS entry, the expiry date, the issuing intermediate and the root CA.
• Every RADIUS server's certificate. Primary and secondary servers often carry different certificates. Devices must validate both.
• The root CA certificate file. Export it as a .cer file. You will upload it to a trusted certificate profile.
• Client certificate infrastructure for EAP-TLS. You need a SCEP (Simple Certificate Enrollment Protocol) or PKCS certificate profile and the CA that issues it. Intune requires a trusted certificate profile for that CA as well.
• Entra ID group design. Decide whether each platform targets user groups or device groups. Keep that choice identical across every linked profile.
• Access points configured for WPA2-Enterprise or WPA3-Enterprise. The SSID must point at your RADIUS server. Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme and Fortinet all support 802.1X.
• A pilot group. Include at least one Windows, one Apple and one Android device.

A distinction matters if your access points reach RADIUS over RadSec (RADIUS over TLS, RFC 6614). The access point runs its own certificate name check on that leg. Purple's Juniper Mist configuration for SecurePass sets a wildcard RadSec server name under Purple's domain. It also loads a RadSec certificate at organisation level. That check sits between the access point and the server. Intune never touches it. Keep the two layers separate when you troubleshoot.

How do you set up certificate server names and the root CA in Intune?

Microsoft's Intune documentation holds the click-by-click steps. The decisions below are the ones that determine whether those steps work.

Step 1: read the names off the certificate the server presents

Read the certificate your RADIUS server presents today. Do not rely on the certificate request or a colleague's notes. A load balancer, a new node or a recent renewal can all change what devices receive.

Ideally the CN and the first SAN DNS entry are identical, for example radius.contoso.com. If you run two servers, choose between these patterns:

• Give each server its own name and list both names in the profile.
• Give both servers names under one shared suffix, such as radius1.contoso.com and radius2.contoso.com.

Step 2: build a trusted certificate profile for the server's root

Create a trusted certificate profile per platform: Windows, iOS and iPadOS, macOS and Android Enterprise. Each contains the root CA that issued the RADIUS server certificate.

Common mistakes happen here:

• Uploading the client-issuing CA instead. If your SCEP certificates come from a different CA than the RADIUS certificate, you need separate trusted certificate profiles. The server validation field must reference the server's root.
• Uploading the intermediate instead of the root. Upload the root. Configure the RADIUS server to send its intermediate certificates during the TLS handshake, so devices can build the full chain.

Step 3: complete the server validation fields per platform

• Windows: Add each RADIUS server name under certificate server names. Select the trusted certificate profile under root certificates for server validation. Windows accepts more than one root profile.
• iOS, iPadOS and macOS: Enter the name under certificate server names. Apple's configuration profile reference documents this field as a list of accepted server certificate common names, and wildcards such as *.contoso.com are accepted. Select the trusted certificate profile as the root for server validation.
• Android Enterprise: Enter the DNS name or suffix under Radius server name. Microsoft's guidance says to enter only the shared suffix when several servers share it. Select the root certificate for server validation.

Step 4: assign every linked profile to the same group

Assign the trusted certificate profile, the SCEP or PKCS profile and the WiFi profile to the same Entra ID group. Do not send one profile to a user group and another to a device group. If the trusted certificate profile never reaches a device, the dependent WiFi profile fails or never installs.

For the identity side of an Entra ID rollout, see how to enable single sign on.

How each platform applies the field

Behaviour	Windows 10 and 11	iOS, iPadOS and macOS	Android Enterprise
Intune field name	Certificate server names	Certificate server names	Radius server name
What it is matched against	DNS name on the server certificate	Server certificate common name	DNS name or suffix on the server certificate
Pattern support	Enter each full server name	Wildcard, for example *.contoso.com	Suffix, for example contoso.com
Root setting	Trusted certificate profiles	A trusted certificate profile	A trusted certificate profile
If the name field is left blank	Windows may ask staff to trust the server	The device may ask staff to trust the server	Android 11 and later remove the option to skip validation
What staff see on a mismatch	The connection fails with no prompt	"Unable to join" message or a trust prompt	Authentication problem shown on the network entry
Where you read the error	WLAN-AutoConfig operational log	macOS Console, eapolclient process	adb logcat, supplicant TLS lines

How do you check server validation works?

Run these checks on each pilot device before you widen the assignment:

1. Profile status. Confirm in Intune that the trusted certificate, client certificate and WiFi profiles all report success on the device.
2. Live connection. Join the SSID. On Windows, netsh wlan show interfaces confirms the connection and the authentication method.
3. Server-side acceptance. Check the RADIUS log for an Access-Accept against that device or account.
4. Negative test. Point a test SSID at a RADIUS server whose certificate carries a different name. The device must refuse it. This proves validation is enforced, not bypassed by a trust prompt.
5. Expiry record. Note the RADIUS certificate expiry date and its root. Diarise the renewal well ahead of schedule.

The negative test is the step teams skip. Without it, you cannot tell a profile that validates correctly from one that trusts any certificate.

What goes wrong, and how do you fix it?

Common failure patterns

• The wrong name in the field. Teams enter an IP address, a short hostname or the load balancer's name. Enter the name printed on the certificate itself.
• The wrong root. The profile references the client-issuing CA or an intermediate. Reference the root that signed the server certificate's chain.
• Mismatched assignment. The WiFi profile targets user groups while the trusted certificate profile targets device groups. Align them.
• A missing intermediate. The RADIUS server sends only its leaf certificate. Devices cannot build the chain, so they reject it. Install the intermediate on the server.
• A CN that differs from the SAN. Apple matches the common name. A certificate with the right SAN and a different CN can pass on Android and fail on iPhone. Keep both identical.

How a renewed RADIUS certificate silently breaks connections

A renewal that keeps the same root and the same names changes nothing on devices. Connections carry on.

A renewal breaks connections when any of these change:

• The root CA. Your provider issues the new certificate from a different root. Every device still points at the old root.
• The intermediate chain. The new chain needs an intermediate the server does not send.
• The name. Someone re-issues the certificate under a new hostname or drops the old SAN.
• One server in a multi-server setup. Only the secondary server changes, so failures look random and intermittent.

The failure is silent because nothing in Intune changes. The profile still shows as succeeded and devices still hold the old root.

Renewals are about to get more frequent. CA/Browser Forum ballot SC-081 cuts the maximum lifetime of publicly trusted TLS certificates. The limit falls significantly over the coming years. A RADIUS server on a public CA certificate will renew several times a year.

Fixes remove most of the risk:

• Issue the RADIUS certificate from a private CA you control. Its root can outlive many server certificates. Renewals under the same root are invisible to devices.
• Stage any root change before the renewal. Deploy the new root as an additional trusted certificate profile first. Windows profiles can reference both roots during the overlap. Swap the server certificate only after devices report the new profile.

Reading the errors on each platform

• Windows: Open the Microsoft-Windows-WLAN-AutoConfig operational log in Event Viewer. Connection failures appear there with a reason. netsh wlan show wlanreport builds an HTML report of recent sessions.
• macOS: Filter Console on the eapolclient process. TLS trust failures name the certificate that was rejected.
• iOS and iPadOS: The device shows an "Unable to join" message or a trust prompt. Confirm the profile contents in Intune, then reproduce on a Mac with the same profile to read the logs.
• Android: The network entry shows an authentication problem. On a test device, adb logcat shows supplicant lines that name the certificate verification failure.
• RADIUS server: An EAP exchange that starts and then stops without a client response usually means the device rejected your certificate.

Worked scenarios

Scenario 1: a retail chain renews on a new root. A retail chain ran PEAP for staff handhelds and Windows tills. Its public CA renewed the RADIUS certificate from a newer root. Every device still pointed at the old root, and no store could connect the next morning. The team deployed a trusted certificate profile for the new root to the same device group. It then forced a sync from Intune. Stores reconnected within one Intune check-in cycle, and the team moved RADIUS certificates to a private CA. Later renewals produced no connection failures. Retail estates with handhelds and tills share this exposure.

Scenario 2: a hotel and the Apple common name. A hotel issued housekeeping iPads and Android tablets on one EAP-TLS SSID. The re-issued RADIUS certificate kept the right SAN, but its CN reverted to the server's short hostname. The Android tablets matched on the DNS suffix and connected. The iPads refused the connection. Re-issuing the certificate with an identical CN and SAN restored every iPad without touching Intune. Hotels running mixed fleets should keep CN and SAN aligned as standard.

Scenario 3: a conference centre with split assignments. A public-sector conference centre deployed EAP-TLS to Windows laptops for event staff. The WiFi profile targeted a user group, while the trusted certificate and SCEP profiles targeted a device group. Some laptops never received the WiFi profile. Re-targeting the profiles to one device group fixed delivery. The laptops connected on their next check-in.

Once validation passes, remaining drops are usually radio or roaming issues. See resolving roaming issues in corporate WLANs. For channel changes at busy venues, see DFS radar events on Cisco Meraki, HPE Aruba and Ruckus: a diagnostics checklist for channel changes.

Checklist for Microsoft Entra ID-joined fleets

1. Read the CN and every SAN DNS entry from the certificate each RADIUS server presents.
2. Make the CN identical to the primary SAN DNS name.
3. Confirm each RADIUS server sends its intermediate certificates in the TLS handshake.
4. Export the root CA that issued the server certificate, not the intermediate.
5. Create a trusted certificate profile for that root on every platform you manage.
6. Keep the client-issuing CA in its own, separate trusted certificate profile.
7. Enter exact server names on Windows, a wildcard on Apple and the DNS suffix on Android.
8. Assign the trusted certificate, SCEP or PKCS, and WiFi profiles to one Entra ID group.
9. Use the same group type, user or device, for every linked profile on a platform.
10. Run the negative test with a mismatched server certificate on each platform.
11. Record every RADIUS certificate's expiry date and root, and review them well ahead of schedule.
12. Stage any new root as an extra trusted certificate profile before you swap the server certificate.

What does it cost, and what do you get back?

Intune is included in Microsoft 365 E3, E5 and Business Premium. Most Entra ID-joined fleets already hold the licence. A private CA can run on Active Directory Certificate Services in Windows Server. Microsoft Cloud PKI is available as a separately licensed Intune add-on.

The main cost is staff time. Each failed renewal brings a wave of support tickets across every site at once. The checklist above takes a few hours per platform and removes that recurring wave.

The return is a network with no shared key to leak. You revoke access by disabling the account or revoking the certificate. EAP-TLS also supports PCI DSS v4.0 requirement 4.2.1.2, which calls for strong cryptography on wireless networks connected to the cardholder data environment. Healthcare sites and Trains operators running staff devices benefit from the same control.

Purple Staff WiFi brings Identity-Based Networks and cloud RADIUS to this model. It works with Microsoft Entra ID, Okta and Google Workspace, so joiners, movers and leavers update network access automatically. It is hardware-agnostic across Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme and Fortinet. Purple runs at 80,000+ live venues and holds ISO 27001 and Cyber Essentials certification.

Frequently asked questions

Does Intune WiFi certificate authentication work with the access points we already own?

Yes. Server validation runs between the device and the RADIUS server, so the access point only needs to support WPA2-Enterprise or WPA3-Enterprise. Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme and Fortinet all support 802.1X. Purple Staff WiFi is hardware-agnostic and runs as a cloud overlay on that existing estate. You do not need to replace hardware to move staff onto certificate-based authentication.

Do we need extra Microsoft licences to deploy Intune WiFi profiles?

No, if you already hold Microsoft 365 E3, E5 or Business Premium. Those suites include Intune, which covers WiFi, trusted certificate and SCEP or PKCS profiles. You may pay separately for a certificate authority. Active Directory Certificate Services runs on Windows Server. Microsoft Cloud PKI is a separately licensed Intune add-on. Your RADIUS server is a separate cost, whether you run Network Policy Server or a cloud RADIUS service.

Should the RADIUS server certificate come from a public CA or a private CA?

A private CA is the safer choice for most fleets. You control its root, so renewals under that root never break device trust. Public CA certificates are shortening under CA/Browser Forum ballot SC-081. Each public renewal risks a root or intermediate change that devices will reject until you redeploy the trust profile.

Can we migrate from PEAP passwords to EAP-TLS without disrupting staff?

Yes. Deploy the SCEP or PKCS certificate profile and the new EAP-TLS WiFi profile alongside the existing PEAP profile. Pilot one group per platform and confirm connections in your RADIUS logs. Remove the PEAP profile once each group connects reliably. The server validation settings, names and root, can stay the same across both methods. That removes the riskiest variable from the migration.

What happens to Intune WiFi profiles when the RADIUS certificate is renewed?

Nothing, provided the renewed certificate keeps the same root CA and the same names. Devices keep connecting. If the root, intermediate chain, CN or SAN changes, devices reject the server even though Intune still reports the profile as succeeded. Stage any new root as an additional trusted certificate profile first. Confirm devices have received it, then install the renewed certificate on the RADIUS server.

Does certificate-based staff WiFi help with PCI DSS and GDPR?

Yes. PCI DSS v4.0 requirement 4.2.1.2 requires strong cryptography for wireless networks connected to the cardholder data environment. EAP-TLS with server validation meets that bar without a shared key. For GDPR, certificate authentication ties each session to a known identity, which supports access logging and prompt revocation. Purple holds ISO 27001 and Cyber Essentials certification, and its platform is GDPR compliant.

How long does it take for profile changes to reach devices?

Most enrolled devices receive changes at their next Intune check-in. For Windows, iOS and Android devices, that check-in runs periodically throughout the day. You can force an immediate sync from Intune or from the device itself. Plan root changes at least one full check-in cycle ahead of the RADIUS certificate swap. Devices that are switched off will collect the update at their next check-in.