Confianza en el servidor del perfil de WiFi de Intune: nombres de servidor de certificados 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 sedes requiere vincular un perfil de certificado de confianza que contenga la CA raíz al mismo grupo de Entra ID para evitar fallos en el saludo de autenticación.

¿Qué hace realmente la validación de servidor 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 los despliegues paralizados fallan en la parte del servidor, por lo que esta guía cubre únicamente esa mitad.

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 (Remote Authentication Dial-In User Service) lo aprueba. EAP-TLS (Extensible Authentication Protocol con Transport Layer Security, RFC 5216) autentica a ambas partes mediante certificados. PEAP (Protected EAP) 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 una contraseña.

Comprobaciones y decisiones

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

• Cadena de confianza. ¿Se encadena el certificado con 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 de servidor Radius.

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

Por qué los fallos permanecen ocultos

Intune informa si un perfil llegó al dispositivo. No informa si el dispositivo acepta su servidor RADIUS. Un perfil puede mostrarse como completado con éxito mientras que cada saludo de autenticación falla en el punto de acceso. Solo detectará el problema cuando el personal informe que la red no se conecta.

¿Qué necesita antes de empezar?

Reúna estos elementos antes de abrir Intune:

• El certificado del servidor RADIUS activo. Registre el nombre común del sujeto (CN), cada entrada DNS de nombre alternativo del sujeto (SAN), la fecha de caducidad, la entidad emisora intermedia y la CA raíz.
• El certificado de cada servidor RADIUS. Los servidores principales y secundarios suelen tener certificados diferentes. Los dispositivos deben validar ambos.
• El archivo de certificado de la 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 a grupos 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 llegan a RADIUS a través de RadSec (RADIUS sobre TLS, RFC 6614). El punto de acceso realiza su propia comprobación del nombre del certificado en ese tramo. La configuración de Juniper Mist de Purple para SecurePass establece un nombre de servidor RadSec con comodín bajo el dominio de Purple. También carga un certificado RadSec a nivel de organización. Esa comprobación se sitúa entre el punto de acceso y el servidor. Intune nunca la toca. Mantenga las dos capas separadas cuando realice tareas de resolución 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 realizar esta configuración. Las siguientes decisiones son las que determinan si esos pasos funcionan.

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

Lea el certificado que presenta su servidor RADIUS actualmente. 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 del 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 mismo sufijo compartido, como radius1.contoso.com y radius2.contoso.com.

Paso 2: crear 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 cometerse errores comunes:

• Subir en su lugar la CA emisora del cliente. 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 CA 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: completar los campos de validación del servidor por plataforma

• Windows: Añada cada nombre de servidor RADIUS bajo los nombres de servidor de certificados. Seleccione el perfil de certificado de confianza bajo los certificados raíz para la validación del servidor. Windows acepta más de un perfil raíz.
• iOS, iPadOS y macOS: Introduzca el nombre bajo los nombres de servidor de certificados. El documento de referencia del perfil de configuración de Apple documenta 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: Introduzca el nombre o sufijo DNS bajo el nombre del servidor Radius. La guía de Microsoft indica introducir únicamente 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 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 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
Con qué se compara	Nombre DNS en el certificado de servidor	Nombre común del certificado de servidor	Nombre o sufijo DNS en el certificado de servidor
Soporte de patrones	Introduzca cada nombre de servidor completo	Comodín, por ejemplo *.contoso.com	Sufijo, por ejemplo contoso.com
Configuración 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 un desajuste	La conexión falla sin previo aviso	Mensaje "No se ha podido conectar" o un aviso de confianza	Problema de autenticación mostrado en la entrada de red
Dónde leer el error	Registro operativo de WLAN-AutoConfig	Consola macOS, proceso eapolclient	adb logcat, líneas TLS del suplicante

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

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 WiFi informan todos de un estado correcto en el dispositivo.
2. Conexión en directo. Conéctese al SSID. En Windows, netsh wlan show interfaces confirma la conexión y el método de autenticación.
3. Aceptación en el lado del servidor. Compruebe el registro de RADIUS para ver un Access-Accept en relación con ese dispositivo o cuenta.
4. Prueba negativa. Dirija 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 no se elude mediante un mensaje de confianza.
5. Registro de expiración. Anote la fecha de caducidad del certificado RADIUS y su raíz. Programe la renovación con suficiente 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 fallar y cómo solucionarlo?

Patrones de fallo comunes

• Nombre incorrecto en el campo. Los equipos introducen una dirección IP, un nombre de host corto o el nombre del equilibrador de carga. Introduzca el nombre exacto que aparece en el propio 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 desemparejada. El perfil de WiFi se dirige a grupos de usuarios, mientras que el perfil de certificado de confianza se dirige a grupos de dispositivos. Alinéelos.
• Falta de una intermedia. El servidor RADIUS solo envía su certificado hoja. 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 coincide con el nombre común (CN). 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 rompe las conexiones de forma silenciosa

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

Una renovación rompe 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 antiguo.
• Un servidor en una configuración multiservidor. Solo cambia el servidor secundario, por lo que los fallos parecen aleatorios e intermitentes.

El fallo es silencioso porque no cambia nada en Intune. El perfil sigue apareciendo como correcto y los dispositivos siguen conservando 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 siguientes soluciones eliminan la mayor parte del riesgo:

• Emita el certificado RADIUS desde una CA privada que usted controle. Su raíz puede sobrevivir a muchos certificados de servidor. Las renovaciones bajo la misma raíz son invisibles para los dispositivos.
• Planifique 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. Cambie 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 de Microsoft-Windows-WLAN-AutoConfig en el Visor de eventos. Los fallos de conexión aparecen allí con un motivo. netsh wlan show wlanreport genera un informe HTML de las sesiones recientes.
• macOS: Filtre en la Consola por el proceso eapolclient. Los fallos de confianza de TLS indican el nombre del certificado que fue rechazado.
• iOS e iPadOS: El dispositivo muestra un mensaje de "No se ha podido conectar" o un aviso de confianza. Confirme el contenido del perfil en Intune y, a continuación, reprodúzcalo en un 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 suplicante que indican el fallo de verificación del certificado.
• Servidor RADIUS: Un intercambio EAP que comienza y luego se detiene sin respuesta del cliente suele significar que el dispositivo rechazó su certificado.

Casos prácticos

Caso 1: una cadena de retail renueva con una nueva raíz. Una cadena de retail utilizaba PEAP para los dispositivos de mano del personal y las cajas registradoras Windows. Su CA pública renovó el certificado RADIUS desde una raíz más reciente. 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. A continuación, forzó una sincronización desde Intune. Las tiendas volvieron a conectarse dentro de un ciclo de registro de Intune, y el equipo trasladó los certificados RADIUS a una CA privada. Las renovaciones posteriores no produjeron fallos de conexión. Los entornos de Retail con dispositivos de mano y cajas registradoras comparten este riesgo.

Caso 2: un hotel y el nombre común de Apple. Un hotel distribuyó iPads de limpieza y tablets Android en un único SSID 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. Al reemitir el certificado con un CN y un SAN idénticos, se restauraron todos los iPads sin necesidad de tocar Intune. Los Hoteles que gestionan flotas mixtas deben mantener alineados el CN y el SAN por norma general.

Caso 3: un centro de conferencias con asignaciones divididas. Un centro de conferencias del sector público distribuyó EAP-TLS en portátiles Windows para el personal del evento. El perfil de WiFi se dirigía a un grupo de usuarios, mientras que el certificado de confianza y los perfiles SCEP se dirigían a un grupo de dispositivos. Algunos portátiles nunca recibieron el perfil de WiFi. Volver a dirigir los perfiles a un único grupo de dispositivos solucionó la distribución. Los portátiles se conectaron en su siguiente registro.

Una vez superada la validación, las caídas restantes suelen ser problemas de radio o de itinerancia. Consulte la guía sobre resolución de problemas de itinerancia en WLAN corporativas. Para cambios de canal en recintos con gran afluencia, consulte Eventos de radar DFS en Cisco Meraki, HPE Aruba y Ruckus: una lista de comprobación de diagnóstico para cambios de canal.

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

1. Lea el CN y cada entrada DNS del SAN del certificado que presenta cada servidor RADIUS.
2. Haga que el CN sea idéntico al nombre DNS de SAN principal.
3. Confirme que cada servidor RADIUS envía sus certificados intermedios en el saludo de 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. Introduzca los 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 grupo de Microsoft Entra ID.
9. Utilice el mismo tipo de grupo, usuario o dispositivo, para cada perfil vinculado en una plataforma.
10. Realice la prueba negativa con un certificado de servidor no coincidente en cada plataforma.
11. Registre la fecha de caducidad y la raíz de cada certificado de RADIUS, y revíselas con suficiente antelación.
12. Prepare cualquier nueva raíz como un perfil de certificado de confianza adicional antes de cambiar el certificado del servidor.

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

Intune está incluido en Microsoft 365 E3, E5 y Business Premium. La mayoría de las flotas unidas a Microsoft Entra ID ya tienen 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 coste principal es el tiempo del personal. Cada renovación fallida genera una ola de solicitudes de soporte en todos los centros a la vez. La lista de comprobación anterior requiere unas pocas horas por plataforma y elimina esa ola recurrente.

El beneficio es una red sin clave compartida que se pueda filtrar. El acceso se revoca deshabilitando la cuenta o revocando el certificado. EAP-TLS también cumple el requisito 4.2.1.2 de PCI DSS v4.0, que exige una criptografía sólida en las redes inalámbricas conectadas al entorno de datos de los titulares de tarjetas. Los centros de Sanidad y los operadores de Trenes que gestionan dispositivos del personal se benefician de este mismo control.

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

Preguntas frecuentes

¿Funciona la autenticación de certificados WiFi de Intune 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 Networks y Fortinet admiten 802.1X. Purple Staff WiFi es independiente del hardware y funciona como una capa de red en la nube sobre la infraestructura existente. No necesita reemplazar el hardware para migrar al personal a la autenticación basada en certificados.

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

No, si ya dispone de Microsoft 365 E3, E5 o Business Premium. Esas suites incluyen Intune, que cubre perfiles de WiFi, certificados de confianza y perfiles SCEP o PKCS. Es posible que tenga que pagar por separado para 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 coste aparte, tanto si utiliza Network Policy Server como si opta por un servicio RADIUS en la nube.

¿El certificado del servidor RADIUS debe proceder de una CA pública o de una CA 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 están acortando su validez bajo la votación SC-081 del foro CA/Browser. Cada renovación pública entraña el riesgo de un cambio de raíz o de entidad intermedia que los dispositivos rechazarán hasta que vuelva a desplegar el perfil de confianza.

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

Sí. Despliegue 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. Retire el perfil PEAP una vez que cada grupo se conecte de forma fiable. Los ajustes de validación del servidor, los nombres y la raíz, pueden seguir siendo los mismos en ambos métodos. Esto elimina la variable de mayor riesgo de la migración.

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

Nada, siempre que el certificado renovado mantenga la misma CA raíz y los mismos nombres. Los dispositivos se seguirán conectando. Si cambia la raíz, la cadena intermedia, el CN o el SAN, los dispositivos rechazarán el servidor, aunque Intune siga informando de que el perfil se ha aplicado correctamente. Prepare primero cualquier raíz nueva como un perfil de certificado de confianza adicional. Confirme que los dispositivos lo han recibido y, a continuación, instale el certificado renovado en el servidor RADIUS.

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

Sí. El requisito 4.2.1.2 de PCI-DSS v4.0 exige una 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 necesidad de una clave compartida. Para el GDPR, la autenticación por certificado vincula cada sesión a una identidad conocida, lo que facilita el registro de accesos y la revocación inmediata. Purple cuenta con las certificaciones ISO 27001 y Cyber Essentials, y su plataforma cumple con el GDPR.

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

La mayoría de los dispositivos registrados reciben los cambios en su siguiente comprobación de Intune. En el caso de dispositivos Windows, iOS y Android, esa comprobació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 comprobación de antelación al cambio de certificado RADIUS. Los dispositivos que estén apagados recibirán la actualización en su próxima comprobación.