Confianza en servidor de perfil de WiFi de Intune: nombres de servidor de certificado y lista de verificación de CA raíz para Microsoft Entra ID

Para establecer la confianza del servidor del perfil de WiFi de Intune con la integración de Microsoft Entra ID, haga coincidir los nombres de servidor de sus certificados con su certificado de servidor RADIUS. La implementación de este estándar IEEE 802.1X en más de 80,000 establecimientos requiere vincular un perfil de certificado de confianza que contenga la CA raíz al mismo grupo de Entra ID para evitar fallas en el saludo de autenticación.

¿Qué hace realmente la validación de servidores en un perfil de WiFi de Intune?

Un perfil de WiFi empresarial en Intune consta de dos partes. La parte del cliente demuestra la identidad del dispositivo. La parte del servidor demuestra que la red le pertenece. La mayoría de las implementaciones estancadas fallan en la parte del servidor, por lo que esta guía cubre únicamente esa sección.

Primero, algunas definiciones. El estándar IEEE 802.1X es el estándar de control de acceso basado en puertos. Mantiene a un dispositivo fuera de la red hasta que un servidor RADIUS (Servicio de autenticación de marcado de usuario de autenticación remota) lo aprueba. EAP-TLS (Protocolo de autenticación extensible con seguridad de la capa de transporte, RFC 5216) autentica a ambas partes mediante certificados. PEAP (EAP protegido) envuelve un intercambio de contraseñas dentro de un túnel TLS.

En ambos métodos, el servidor RADIUS presenta primero su certificado. El dispositivo decide si confía en él antes de enviar un certificado o contraseña.

Verificaciones y decisiones

El dispositivo realiza dos pruebas en el certificado del servidor RADIUS:

• Cadena de confianza. ¿El certificado se encadena a una autoridad de certificación (CA) raíz designada en el perfil? En Intune, esa raíz llega al dispositivo como un perfil de certificado de confianza.
• Identidad. ¿Coincide el nombre del certificado con el campo de nombres de servidor de certificados? En Windows, iOS y macOS el campo tiene ese nombre. En Android Enterprise, es el campo de nombre del servidor Radius.

Ambas pruebas deben superarse. Un certificado de una CA de confianza con el nombre incorrecto fallará. El nombre correcto de una CA no registrada también fallará. Esta combinación bloquea un punto de acceso no autorizado que presente un certificado válido para el dominio de otra persona. Ese tipo de ataque recopila credenciales PEAP de dispositivos que omiten la validación.

Por qué las fallas permanecen ocultas

Intune informa si un perfil llegó al dispositivo. No informa si el dispositivo acepta su servidor RADIUS. Un perfil puede mostrarse como exitoso mientras que cada saludo de autenticación falla en el punto de acceso. Solo verá el problema cuando el personal informe que no es posible conectarse a la red.

¿Qué necesita antes de comenzar?

Reúna estos elementos antes de abrir Intune:

• El certificado del servidor RADIUS activo. Registre el nombre común (CN) del sujeto, cada entrada DNS de nombre alternativo del sujeto (SAN), la fecha de vencimiento, la entidad emisora intermedia y la CA raíz.
• El certificado de cada servidor RADIUS. Los servidores primarios y secundarios a menudo tienen certificados diferentes. Los dispositivos deben validar ambos.
• El archivo del certificado CA raíz. Expórtelo como un archivo .cer. Lo subirá a un perfil de certificado de confianza.- Infraestructura de certificados de cliente para EAP-TLS. Necesita un perfil de certificado SCEP (Simple Certificate Enrollment Protocol) o PKCS y la CA que lo emite. Intune también requiere un perfil de certificado de confianza para esa CA.
• Diseño de grupos de Entra ID. Decida si cada plataforma se dirige a grupos de usuarios o de dispositivos. Mantenga esa elección idéntica en todos los perfiles vinculados.
• Puntos de acceso configurados para WPA2-Enterprise o WPA3-Enterprise. El SSID debe apuntar a su servidor RADIUS. Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme y Fortinet son compatibles con 802.1X.
• Un grupo piloto. Incluya al menos un dispositivo Windows, uno Apple y uno Android.

Existe una distinción importante si sus puntos de acceso se conectan a RADIUS a través de RadSec (RADIUS sobre TLS, RFC 6614). El punto de acceso realiza su propia verificación de nombre de certificado en ese tramo. La configuración de Juniper Mist de Purple para SecurePass establece un nombre de servidor RadSec comodín bajo el dominio de Purple. También carga un certificado RadSec a nivel de organización. Esa verificación se realiza entre el punto de acceso y el servidor. Intune nunca interviene en ella. Mantenga las dos capas separadas cuando realice el diagnóstico de problemas.

¿Cómo se configuran los nombres de los servidores de certificados y la CA raíz en Intune?

La documentación de Intune de Microsoft contiene los pasos detallados para hacer clic. Las decisiones que se describen a continuación son las que determinan si esos pasos funcionarán.

Paso 1: lea los nombres del certificado que presenta el servidor

Lea el certificado que presenta su servidor RADIUS hoy en día. No confíe en la solicitud de certificado ni en las notas de un colega. Un equilibrador de carga, un nuevo nodo o una renovación reciente pueden cambiar lo que reciben los dispositivos.

Idealmente, el CN y la primera entrada DNS de SAN son idénticos, por ejemplo, radius.contoso.com. Si tiene dos servidores, elija entre estos patrones:

• Asigne a cada servidor su propio nombre y enumere ambos nombres en el perfil.
• Asigne a ambos servidores nombres bajo un sufijo compartido, como radius1.contoso.com y radius2.contoso.com.

Paso 2: cree un perfil de certificado de confianza para la raíz del servidor

Cree un perfil de certificado de confianza por plataforma: Windows, iOS y iPadOS, macOS y Android Enterprise. Cada uno contiene la CA raíz que emitió el certificado del servidor RADIUS.

Aquí suelen ocurrir errores comunes:

• Subir la CA emisora del cliente en su lugar. Si sus certificados SCEP provienen de una CA diferente a la del certificado RADIUS, necesitará perfiles de certificado de confianza independientes. El campo de validación del servidor debe hacer referencia a la raíz del servidor.
• Subir la intermedia en lugar de la raíz. Suba la raíz. Configure el servidor RADIUS para que envíe sus certificados intermedios durante el saludo TLS, de modo que los dispositivos puedan construir la cadena completa.

Paso 3: complete los campos de validación del servidor por plataforma

• Windows: Agregue cada nombre de servidor RADIUS en los nombres de servidor de certificados. Seleccione el perfil de certificado de confianza en los certificados raíz para la validación del servidor. Windows acepta más de un perfil raíz.
• iOS, iPadOS y macOS: Ingrese el nombre en los nombres de servidor de certificados. Los documentos de referencia del perfil de configuración de Apple documentan este campo como una lista de nombres comunes de certificados de servidor aceptados, y se aceptan comodines como *.contoso.com. Seleccione el perfil de certificado de confianza como la raíz para la validación del servidor.
• Android Enterprise: Ingrese el nombre de DNS o sufijo en el nombre del servidor Radius. Las instrucciones de Microsoft indican ingresar solo el sufijo compartido cuando varios servidores lo comparten. Seleccione el certificado raíz para la validación del servidor.

Paso 4: asignar cada perfil vinculado al mismo grupo

Asigne el perfil de certificado de confianza, el perfil SCEP o PKCS y el perfil de WiFi al mismo grupo de Microsoft Entra ID. No envíe un perfil a un grupo de usuarios y otro a un grupo de dispositivos. Si el perfil de certificado de confianza nunca llega a un dispositivo, el perfil de WiFi dependiente fallará o nunca se instalará.

Para la parte de identidad de un despliegue de Microsoft Entra ID, consulte cómo habilitar el inicio de sesión único.

Cómo aplica el campo cada plataforma

Comportamiento	Windows 10 y 11	iOS, iPadOS y macOS	Android Enterprise
Nombre del campo en Intune	Nombres de servidor de certificados	Nombres de servidor de certificados	Nombre del servidor Radius
Contra qué se compara	Nombre DNS en el certificado del servidor	Nombre común del certificado del servidor	Nombre DNS o sufijo en el certificado del servidor
Soporte de patrones	Ingrese cada nombre de servidor completo	Comodín, por ejemplo *.contoso.com	Sufijo, por ejemplo contoso.com
Configuración de raíz	Perfiles de certificados de confianza	Un perfil de certificado de confianza	Un perfil de certificado de confianza
Si el campo de nombre se deja en blanco	Windows puede pedir al personal que confíe en el servidor	El dispositivo puede pedir al personal que confíe en el servidor	Android 11 y versiones posteriores eliminan la opción de omitir la validación
Qué ve el personal ante una discrepancia	La conexión falla sin previo aviso	Mensaje de "No se puede conectar" o una solicitud de confianza	Se muestra un problema de autenticación en la entrada de red
Dónde se lee el error	Registro operativo WLAN-AutoConfig	Consola macOS, proceso eapolclient	adb logcat, líneas TLS del solicitante

¿Cómo se comprueba que la validación del servidor funciona?

Realice estas comprobaciones en cada dispositivo piloto antes de ampliar la asignación:

1. Estado del perfil. Confirme en Intune que el certificado de confianza, el certificado de cliente y los perfiles de WiFi reporten un estado exitoso en el dispositivo.
2. Conexión en vivo. Conéctese al SSID. En Windows, netsh wlan show interfaces confirma la conexión y el método de autenticación.
3. Aceptación del lado del servidor. Revise el registro de RADIUS para ver un Access-Accept para ese dispositivo o cuenta.
4. Prueba negativa. Apunte un SSID de prueba a un servidor RADIUS cuyo certificado tenga un nombre diferente. El dispositivo debe rechazarlo. Esto demuestra que la validación se aplica de forma obligatoria y que no se omite mediante una solicitud de confianza.
5. Registro de caducidad. Anote la fecha de vencimiento del certificado RADIUS y su raíz. Agende la renovación con bastante antelación.

La prueba negativa es el paso que los equipos suelen saltarse. Sin ella, no se puede distinguir un perfil que se valida correctamente de uno que confía en cualquier certificado.

¿Qué puede salir mal y cómo solucionarlo?

Patrones de falla comunes

• El nombre incorrecto en el campo. Los equipos ingresan una dirección IP, un nombre de host corto o el nombre del balanceador de carga. Ingrese el nombre exacto que aparece en el certificado.
• La raíz incorrecta. El perfil hace referencia a la CA emisora del cliente o a una intermedia. Haga referencia a la raíz que firmó la cadena del certificado del servidor.
• Asignación no coincidente. El perfil de WiFi se dirige a grupos de usuarios, mientras que el perfil de certificado de confianza se dirige a grupos de dispositivos. Aléineolos.
• Falta una intermedia. El servidor RADIUS envía solo su certificado final. Los dispositivos no pueden construir la cadena, por lo que lo rechazan. Instale la intermedia en el servidor.
• Un CN que difiere del SAN. Apple hace coincidir el nombre común. Un certificado con el SAN correcto y un CN diferente puede funcionar en Android y fallar en iPhone. Mantenga ambos idénticos.

Cómo una renovación de certificado RADIUS interrumpe las conexiones de forma silenciosa

Una renovación que conserve la misma raíz y los mismos nombres no cambia nada en los dispositivos. Las conexiones continúan.

Una renovación interrumpe las conexiones cuando cambia cualquiera de los siguientes elementos:

• La CA raíz. Su proveedor emite el nuevo certificado desde una raíz diferente. Todos los dispositivos siguen apuntando a la raíz antigua.
• La cadena intermedia. La nueva cadena necesita una intermedia que el servidor no envía.
• El nombre. Alguien vuelve a emitir el certificado con un nuevo nombre de host o elimina el SAN anterior.
• Un servidor en una configuración multiservidor. Solo cambia el servidor secundario, por lo que las fallas parecen aleatorias e intermitentes.

La falla es silenciosa porque nada cambia en Intune. El perfil sigue apareciendo como exitoso y los dispositivos aún conservan la raíz antigua.

Las renovaciones están a punto de ser más frecuentes. La votación SC-081 del CA/Browser Forum reduce la vida útil máxima de los certificados TLS de confianza pública. El límite disminuirá significativamente en los próximos años. Un servidor RADIUS con un certificado de CA pública se renovará varias veces al año.

Las soluciones eliminan la mayor parte del riesgo:

• Emita el certificado RADIUS desde una CA privada que usted controle. Su raíz puede durar más que muchos certificados de servidor. Las renovaciones bajo la misma raíz son invisibles para los dispositivos.
• Prepare cualquier cambio de raíz antes de la renovación. Implemente primero la nueva raíz como un perfil de certificado de confianza adicional. Los perfiles de Windows pueden hacer referencia a ambas raíces durante el periodo de transición. Reemplace el certificado del servidor solo después de que los dispositivos informen sobre el nuevo perfil.

Lectura de errores en cada plataforma

• Windows: Abra el registro operativo Microsoft-Windows-WLAN-AutoConfig en el Visor de eventos. Los fallos de conexión se muestran ahí con un motivo. netsh wlan show wlanreport genera un reporte HTML de las sesiones recientes.
• macOS: Filtre la Consola por el proceso eapolclient. Los fallos de confianza TLS indican el certificado que fue rechazado.
• iOS y iPadOS: El dispositivo muestra un mensaje de "No se puede conectar" o una solicitud de confianza. Confirme el contenido del perfil en Intune, luego reprodúzcalo en una Mac con el mismo perfil para leer los registros.
• Android: La entrada de red muestra un problema de autenticación. En un dispositivo de prueba, adb logcat muestra líneas de supplicant que indican el fallo de verificación del certificado.
• Servidor RADIUS: Un intercambio EAP que comienza y luego se detiene sin respuesta del cliente generalmente significa que el dispositivo rechazó su certificado.

Escenarios prácticos

Escenario 1: una cadena de retail renueva con una nueva raíz. Una cadena de retail utilizaba PEAP para dispositivos portátiles de personal y cajas registradoras Windows. Su CA pública renovó el certificado RADIUS desde una raíz más nueva. Todos los dispositivos seguían apuntando a la raíz antigua y ninguna tienda pudo conectarse a la mañana siguiente. El equipo distribuyó un perfil de certificado de confianza para la nueva raíz al mismo grupo de dispositivos. Luego forzó una sincronización desde Intune. Las tiendas se volvieron a conectar dentro de un ciclo de sincronización de Intune, y el equipo migró los certificados RADIUS a una CA privada. Las renovaciones posteriores no produjeron fallos de conexión. Los complejos de retail con dispositivos portátiles y cajas registradoras comparten este riesgo.

Escenario 2: un hotel y el nombre común de Apple. Un hotel distribuyó iPads de limpieza y tablets Android en un mismo SSID con EAP-TLS. El certificado RADIUS reemitido mantuvo el SAN correcto, pero su CN volvió al nombre de host corto del servidor. Las tablets Android coincidieron con el sufijo DNS y se conectaron. Los iPads rechazaron la conexión. Reemitir el certificado con un CN y un SAN idénticos restableció todos los iPads sin necesidad de modificar Intune. Los hoteles que operan flotas mixtas deben mantener alineados el CN y el SAN como estándar.

Escenario 3: un centro de conferencias con asignaciones divididas. Un centro de conferencias del sector público distribuyó EAP-TLS a laptops Windows para el personal de eventos. El perfil de WiFi apuntaba a un grupo de usuarios, mientras que el certificado de confianza y los perfiles SCEP apuntaban a un grupo de dispositivos. Algunas laptops nunca recibieron el perfil de WiFi. Reorientar los perfiles a un solo grupo de dispositivos solucionó la entrega. Las laptops se conectaron en su siguiente sincronización.

Una vez que se supera la validación, las caídas restantes suelen ser problemas de radio o de roaming. Consulte resolución de problemas de roaming en WLAN corporativas. Para cambios de canal en recintos concurridos, consulte eventos de radar DFS en Cisco Meraki, HPE Aruba y Ruckus: una lista de verificación de diagnóstico para cambios de canal.

Lista de verificación para flotas unidas a Microsoft Entra ID

1. Lea el CN y cada entrada DNS de SAN del certificado que presenta cada servidor RADIUS.
2. Haga que el CN sea idéntico al nombre de DNS de SAN principal.
3. Confirme que cada servidor RADIUS envíe sus certificados intermedios en el saludo TLS.
4. Exporte la CA raíz que emitió el certificado del servidor, no la intermedia.
5. Cree un perfil de certificado de confianza para esa raíz en cada plataforma que administre.
6. Mantenga la CA emisora de clientes en su propio perfil de certificado de confianza independiente.
7. Ingrese nombres de servidor exactos en Windows, un comodín en Apple y el sufijo DNS en Android.
8. Asigne el certificado de confianza, SCEP o PKCS, y los perfiles de WiFi a un solo grupo de Entra ID.
9. Use el mismo tipo de grupo, usuario o dispositivo, para cada perfil vinculado en una plataforma.
10. Ejecute la prueba negativa con un certificado de servidor no coincidente en cada plataforma.
11. Registre la fecha de vencimiento y la raíz de cada certificado RADIUS, y revíselos con suficiente antelación.
12. Prepare cualquier raíz nueva como un perfil de certificado de confianza adicional antes de cambiar el certificado del servidor.

¿Cuánto cuesta y qué obtiene a cambio?

Intune está incluido en Microsoft 365 E3, E5 y Business Premium. La mayoría de las flotas unidas a Entra ID ya cuentan con la licencia. Una CA privada puede ejecutarse en Active Directory Certificate Services en Windows Server. Microsoft Cloud PKI está disponible como un complemento de Intune con licencia independiente.

El costo principal es el tiempo del personal. Cada renovación fallida genera una ola de tickets de soporte en todos los sitios a la vez. La lista de verificación anterior toma unas pocas horas por plataforma y elimina esa ola recurrente.

El retorno es una red sin clave compartida que pueda filtrarse. Usted revoca el acceso al deshabilitar la cuenta o revocar el certificado. EAP-TLS también es compatible con el requisito 4.2.1.2 de PCI-DSS v4.0, que exige criptografía sólida en redes inalámbricas conectadas al entorno de datos de los titulares de tarjetas. Los sitios de Cuidado de la salud y los operadores de Trenes que manejan dispositivos del personal se benefician de este mismo control.

Purple Staff WiFi aporta Redes Basadas en la Identidad y RADIUS en la nube a este modelo. Funciona con Microsoft Entra ID, Okta y Google Workspace, por lo que las altas, bajas y cambios de personal actualizan el acceso a la red de forma automática. Es independiente del hardware y funciona con Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme y Fortinet. Purple opera en más de 80,000 establecimientos activos y cuenta con las certificaciones ISO 27001 y Cyber Essentials.

Preguntas frecuentes

¿La autenticación de certificados WiFi de Intune funciona con los puntos de acceso que ya tenemos?

Sí. La validación del servidor se realiza entre el dispositivo y el servidor RADIUS, por lo que el punto de acceso solo necesita ser compatible con WPA2-Enterprise o WPA3-Enterprise. Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme y Fortinet son compatibles con 802.1X. Purple Staff WiFi es independiente del hardware y funciona como una superposición en la nube sobre esa infraestructura existente. No necesita reemplazar el hardware para migrar al personal a la autenticación basada en certificados.

¿Necesitamos licencias adicionales de Microsoft para implementar perfiles de WiFi de Intune?

No, si ya cuenta con Microsoft 365 E3, E5 o Business Premium. Esas suites incluyen Intune, que cubre perfiles de WiFi, certificados de confianza y SCEP o PKCS. Es posible que deba pagar por separado por una entidad de certificación. Active Directory Certificate Services se ejecuta en Windows Server. Microsoft Cloud PKI es un complemento de Intune con licencia independiente. Su servidor RADIUS tiene un costo aparte, ya sea que ejecute Network Policy Server o un servicio RADIUS en la nube.

¿El certificado del servidor RADIUS debe provenir de una CA pública o privada?

Una CA privada es la opción más segura para la mayoría de las flotas de dispositivos. Usted controla su raíz, por lo que las renovaciones bajo esa raíz nunca rompen la confianza del dispositivo. Los certificados de CA públicas se están acortando bajo la votación SC-081 del CA/Browser Forum. Cada renovación pública corre el riesgo de un cambio de raíz o intermedio que los dispositivos rechazarán hasta que vuelva a implementar el perfil de confianza.

¿Podemos migrar de contraseñas PEAP a EAP-TLS sin interrumpir al personal?

Sí. Implemente el perfil de certificado SCEP o PKCS y el nuevo perfil de WiFi EAP-TLS junto con el perfil PEAP existente. Realice una prueba piloto con un grupo por plataforma y confirme las conexiones en sus registros de RADIUS. Elimine el perfil PEAP una vez que cada grupo se conecte de manera confiable. La configuración de validación del servidor, los nombres y la raíz, pueden seguir siendo los mismos en ambos métodos. Eso elimina la variable más riesgosa de la migración.

¿Qué sucede con los perfiles de WiFi de Intune cuando se renueva el certificado RADIUS?

Nada, siempre que el certificado renovado conserve la misma CA raíz y los mismos nombres. Los dispositivos se seguirán conectando. Si la raíz, la cadena intermedia, el CN o el SAN cambian, los dispositivos rechazarán al servidor aunque Intune siga informando que el perfil se aplicó con éxito. Prepare cualquier raíz nueva como un perfil de certificado de confianza adicional primero. Confirme que los dispositivos lo hayan recibido y luego instale el certificado renovado en el servidor RADIUS.

¿El WiFi para el personal basado en certificados ayuda con PCI-DSS y GDPR?

Sí. El requisito 4.2.1.2 de PCI-DSS v4.0 exige criptografía sólida para las redes inalámbricas conectadas al entorno de datos de los titulares de tarjetas. EAP-TLS con validación de servidor cumple con ese estándar sin una clave compartida. Para GDPR, la autenticación por certificado vincula cada sesión a una identidad conocida, lo que respalda el registro de acceso y la revocación inmediata. Purple cuenta con las certificaciones ISO 27001 y Cyber Essentials, y su plataforma cumple con GDPR.

¿Cuánto tiempo tardan los cambios de perfil en llegar a los dispositivos?

La mayoría de los dispositivos registrados reciben los cambios en su próximo inicio de sesión en Intune. Para dispositivos Windows, iOS y Android, ese inicio de sesión se realiza periódicamente a lo largo del día. Puede forzar una sincronización inmediata desde Intune o desde el propio dispositivo. Planifique los cambios de raíz con al menos un ciclo completo de inicio de sesión de anticipación al intercambio de certificados de RADIUS. Los dispositivos que estén apagados recibirán la actualización en su próximo inicio de sesión.