Despliegue de certificados WiFi de Microsoft Intune a través de SCEP y PKCS

Resumen ejecutivo

Para los establecimientos empresariales, ya sea un dinámico entorno de hostelería , una operación de comercio minorista multisitio o un campus corporativo moderno, depender de claves precompartidas o de Captive Portals básicos para el WiFi del personal es una vulnerabilidad de seguridad y un cuello de botella operativo. La arquitectura de red moderna exige autenticación 802.1X mediante EAP-TLS, lo que garantiza que cada dispositivo se verifique criptográficamente antes de acceder a la red.

Sin embargo, el desafío radica en la distribución: ¿cómo desplegar certificados de cliente únicos en miles de dispositivos Windows, iOS y Android sin saturar a su servicio de soporte con tickets? Microsoft Intune resuelve esto mediante la gestión automatizada del ciclo de vida de los certificados. Al aprovechar los perfiles de certificado SCEP (Simple Certificate Enrollment Protocol) o PKCS (Public Key Cryptography Standards), los equipos de TI pueden enviar certificados raíz y de cliente de confianza de forma silenciosa a los dispositivos gestionados.

Esta guía proporciona un diseño arquitectónico definitivo y una estrategia de implementación paso a paso para el despliegue de certificados WiFi de Intune. Exploraremos las diferencias críticas entre SCEP y PKCS, detallaremos la secuencia de despliegue exacta requerida para el éxito y describiremos estrategias de mitigación de riesgos en el mundo real para garantizar que su Guest WiFi y sus redes corporativas sigan siendo seguras y eficientes.

Escuche el informe del podcast complementario:

Análisis técnico profundo: SCEP frente a PKCS

Al diseñar su estrategia de despliegue de certificados WiFi de Intune, la primera decisión arquitectónica es seleccionar el mecanismo de entrega de certificados. Intune admite tanto SCEP como PKCS, pero funcionan de manera fundamentalmente diferente.

SCEP (Simple Certificate Enrollment Protocol)

SCEP es el estándar de la industria para el registro de dispositivos empresariales. En un flujo de trabajo de SCEP, el servicio de Intune indica al dispositivo final que genere su propio par de claves privada y pública. A continuación, el dispositivo crea una solicitud de firma de certificado (CSR) y la envía a través de un servidor de Servicio de inscripción de dispositivos de red (NDES) a su entidad de certificación (CA). La CA firma la solicitud y devuelve el certificado público al dispositivo.

La ventaja crítica de seguridad de SCEP es que la clave privada nunca sale del dispositivo. Se genera localmente, se almacena en el enclave seguro del dispositivo (como el TPM en Windows o el Secure Enclave en iOS) y nunca se transmite a través de la red. Esto hace que SCEP sea el enfoque firmemente recomendado para la autenticación 802.1X.

PKCS (Public Key Cryptography Standards)

Por el contrario, con PKCS, la entidad de certificación genera tanto la clave pública como la privada de forma centralizada. A continuación, el Microsoft Intune Certificate Connector exporta de forma segura este par de claves y lo envía al dispositivo de destino.

Aunque PKCS elimina la necesidad de desplegar y mantener un servidor NDES (lo que simplifica la infraestructura), introduce un riesgo de seguridad teórico porque la clave privada se transmite a través de la red. PKCS suele ser más adecuado para casos de uso en los que se requiere el depósito de claves (key escrow), como el cifrado de correo electrónico S/MIME, en lugar de la autenticación de red.

Guía de implementación: la secuencia de despliegue

Configurar correctamente un perfil de WiFi de Intune para 802.1X requiere cumplir estrictamente una secuencia de despliegue específica. Las dependencias de los perfiles de Intune dictan que se debe establecer la confianza antes de poder configurar la autenticación.

Paso 1: Desplegar el perfil de certificado raíz de confianza

Antes de que cualquier dispositivo pueda solicitar un certificado de cliente o confiar en su servidor RADIUS, debe confiar en la entidad de certificación emisora.

1. Exporte su certificado de CA raíz (y cualquier certificado de CA intermedia) como archivos .cer.
2. En el centro de administración de Microsoft Endpoint Manager, vaya a Dispositivos > Perfiles de configuración > Crear perfil.
3. Seleccione la plataforma de destino (por ejemplo, Windows 10 y posterior) y elija el tipo de perfil Certificado de confianza.
4. Cargue el archivo .cer y despliegue este perfil en sus grupos de dispositivos de destino.

Regla general: Dirija siempre los perfiles a los mismos grupos (ya sean usuarios o dispositivos) en todos los perfiles relacionados para evitar discrepancias en el despliegue.

Paso 2: Configurar el perfil de certificado SCEP

Una vez establecida la confianza, configure el perfil SCEP para indicar a los dispositivos cómo obtener su certificado de cliente.

1. Cree un nuevo perfil de configuración y seleccione Certificado SCEP.
2. Configure el Formato del nombre del sujeto. Para la autenticación basada en usuario, lo estándar es CN={{UserPrincipalName}}. Para la autenticación de dispositivos, utilice CN={{AAD_Device_ID}}.
3. Establezca el Uso de la clave (Key usage) en Digital signature y Key encipherment.
4. En Uso de clave extendido (Extended key usage), especifique Client Authentication (OID: 1.3.6.1.5.5.7.3.2).
5. Vincule este perfil al perfil de certificado raíz de confianza creado en el Paso 1.
6. Proporcione la URL externa de su servidor NDES.

Paso 3: Desplegar el perfil de WiFi 802.1X

El paso final consiste en enviar la configuración de WiFi que vincula los certificados al SSID de la red.

1. Cree un perfil de configuración de Wi-Fi.
2. Introduzca el Nombre de la red (SSID) exactamente como lo transmiten sus puntos de acceso inalámbricos .
3. Seleccione WPA2-Enterprise o WPA3-Enterprise como tipo de seguridad.
4. Establezca el Tipo de EAP en EAP-TLS.
5. En la configuración de autenticación, seleccione el perfil de certificado SCEP creado en el Paso 2 como el certificado de autenticación de cliente.
6. Especifique el certificado Trusted Root para la validación del servidor, garantizando que el dispositivo solo se conecte a su servidor RADIUS legítimo.

Mejores prácticas y estándares del sector

Al implementar el despliegue de certificados WiFi de Intune, siga estas mejores prácticas independientes del proveedor para garantizar el cumplimiento y la fiabilidad.

Ubicación y seguridad del servidor NDES

El servidor NDES debe ser accesible desde internet para permitir que los dispositivos remotos aprovisionen certificados antes de llegar a las instalaciones. Sin embargo, exponer un servidor interno directamente a internet supone un riesgo de seguridad significativo.

Recomendación: Publique la URL de NDES mediante Azure AD Application Proxy. Esto proporciona un acceso remoto seguro sin abrir puertos de entrada en el firewall y le permite aplicar políticas de Acceso condicional al flujo de inscripción.

RADIUS y comprobación de CRL

El despliegue de certificados es solo la mitad de la ecuación de seguridad; la revocación es igual de crítica. Si se rescinde el contrato de un empleado, deshabilitar su cuenta de Active Directory puede no revocar inmediatamente su acceso WiFi si su certificado de cliente sigue siendo válido y el servidor RADIUS no comprueba estrictamente la Lista de revocación de certificados (CRL).

Recomendación: Configure su Network Policy Server (NPS) o servidor RADIUS para exigir una comprobación estricta de la CRL. Asegúrese de que sus Puntos de distribución de CRL (CDP) tengan una alta disponibilidad; si el servidor RADIUS no puede acceder a la CRL, la autenticación fallará, lo que provocará una interrupción generalizada del servicio.

Para obtener más información sobre el diseño de redes seguras, considere revisar Los beneficios principales de SD WAN para las empresas modernas .

Resolución de problemas y mitigación de riesgos

Incluso con una planificación meticulosa, el despliegue de certificados puede presentar problemas. A continuación se detallan los fallos más comunes y las estrategias de mitigación.

Problema: El perfil WiFi no se aplica

Síntoma: El dispositivo recibe los certificados Trusted Root y SCEP, pero el perfil WiFi aparece como 'Error' o 'No aplicable' en Intune.

Causa principal: Esto casi siempre se debe a una discrepancia en la asignación de grupos. Si el perfil SCEP está asignado a un Grupo de usuarios, pero el perfil WiFi está asignado a un Grupo de dispositivos, Intune no puede resolver la dependencia.

Mitigación: Audite sus asignaciones. Asegúrese de que los perfiles Trusted Root, SCEP y WiFi estén desplegados exactamente en el mismo grupo de Azure AD.

Problema: Errores NDES 403 Forbidden

Síntoma: Los dispositivos no logran recuperar el certificado SCEP y los registros de IIS de NDES muestran errores HTTP 403.

Causa principal: La cuenta de servicio de Intune Certificate Connector carece de los permisos necesarios en la plantilla de certificado, o el filtrado de URL de su firewall está bloqueando los parámetros de cadena de consulta específicos utilizados por SCEP.

Mitigación: Verifique que la cuenta del conector tenga permisos de 'Lectura' y 'Inscripción' en la plantilla de la CA. Revise los registros del firewall para asegurarse de que no se estén bloqueando las URL que contienen ?operation=GetCACaps.

ROI e impacto empresarial

La transición al despliegue de certificados 802.1X de Microsoft Intune ofrece un retorno medible tanto en seguridad como en operaciones.

1. Reducción de tickets de soporte: El acceso WiFi basado en contraseñas genera un volumen significativo de tickets de soporte (caducidad de contraseñas, bloqueos de cuentas, errores de escritura). La autenticación basada en certificados es invisible para el usuario, lo que suele reducir el volumen de soporte relacionado con WiFi entre un 70 % y un 80 %.
2. Mejora de la postura de seguridad: EAP-TLS elimina el riesgo de robo de credenciales y de ataques Man-in-the-Middle (MitM). Esto es fundamental para cumplir con marcos como PCI DSS y GDPR, especialmente en entornos de Sanidad y comercio minorista.
3. Incorporación fluida: Para las organizaciones que gestionan grandes flotas de dispositivos Apple junto con Windows, la integración de Intune con los flujos de trabajo de MDM existentes (consulte nuestra guía sobre Jamf y RADIUS: Autenticación WiFi basada en certificados para flotas de dispositivos Apple ) garantiza una experiencia de aprovisionamiento unificada y sin intervención desde el primer día.