How to Configure SCEP for Automated Enterprise WiFi Certificate Enrollment

Esta guía explica cómo configurar SCEP (Simple Certificate Enrollment Protocol) para el registro automatizado de certificados de WiFi empresariales, abarcando toda la arquitectura desde PKI y NDES hasta la implementación de perfiles MDM y la validación RADIUS. Está dirigida a gerentes de TI, arquitectos de red y CTOs en hoteles, cadenas de retail, estadios, centros de convenciones y organizaciones del sector público que necesitan ir más allá de las claves precompartidas e implementar una autenticación 802.1X EAP-TLS escalable y basada en la identidad. La plataforma de superposición en la nube de Purple, que es agnóstica al hardware, se integra directamente con esta arquitectura, proporcionando la capa de WiFi para invitados y BYOD que coexiste junto con la red de personal autenticada por certificado.

📖 10 min de lectura📝 2,282 palabras🔧 2 ejemplos resueltos❓ 3 preguntas de práctica📚 9 definiciones clave

Escucha esta guía

Ver transcripción del podcast

Bienvenido a la serie de Informes Técnicos de Purple. Hoy voy a hablar de algo que llega a muchas bandejas de entrada de TI pero que rara vez recibe una respuesta clara: cómo implementar realmente la autenticación de WiFi basada en certificados a escala, utilizando SCEP, a través de una gran red. Ya sea que se trate de un campus universitario, un grupo hotelero con múltiples sedes o un gran patrimonio del sector público, los desafíos son idénticos.

Vamos a cubrir el panorama completo. Qué hace realmente SCEP, cómo encaja en una arquitectura 802.1X, la secuencia de implementación en la que la mayoría de los equipos se equivocan, dos escenarios de implementación del mundo real y los obstáculos que le costarán un fin de semana de su vida si no los planifica.

Este es un informe de consultoría, no un tutorial. Asumo que sabe qué es un servidor RADIUS y que probablemente ya haya decidido que necesita dejar atrás las claves precompartidas. Lo que necesita ahora es el mapa de implementación.

Comencemos.

Primeros principios. SCEP significa Simple Certificate Enrollment Protocol (Protocolo de Inscripción de Certificados Simple). Fue formalizado por el IETF como RFC 8894 en 2020, aunque ya se utilizaba ampliamente en empresas desde hacía más de una década. Su función es sencilla: automatizar el proceso de obtención de un certificado digital en un dispositivo administrado sin necesidad de que una persona intervenga en cada máquina.

En el contexto de la autenticación de WiFi, SCEP es el mecanismo de entrega. El protocolo de autenticación real al que se dirige es EAP-TLS, Extensible Authentication Protocol con Transport Layer Security (Protocolo de Autenticación Extensible con Seguridad de la Capa de Transporte), que se encuentra dentro del marco 802.1X. EAP-TLS es ampliamente considerado como el método de autenticación más seguro para redes inalámbricas empresariales porque requiere que tanto el dispositivo cliente como el servidor RADIUS presenten certificados válidos. Ninguna de las partes confía en la otra sin una prueba criptográfica. Esa autenticación mutua es lo que lo protege contra los ataques de gemelo malvado (evil twin), donde un atacante levanta un punto de acceso no autorizado para recopilar credenciales.

Así es como funciona la cadena completa. Un dispositivo administrado, la laptop de un estudiante, el teléfono del personal, una terminal de punto de venta de un hotel, necesita unirse a la red inalámbrica corporativa. Su plataforma MDM, que podría ser Microsoft Intune o Jamf, envía un payload SCEP a ese dispositivo. El payload contiene dos cosas: la URL de SCEP, que apunta a su servidor NDES o gateway SCEP en la nube, y una contraseña de desafío o secreto compartido.

El dispositivo genera su propio par de claves pública y privada de forma local. Esto es fundamental. La clave privada nunca sale del dispositivo. Se genera en el dispositivo, se almacena en el enclave seguro o TPM, y nunca se transmite a través de la red. Luego, el dispositivo crea una Solicitud de Firma de Certificado, un CSR, y la envía al gateway SCEP. El gateway valida el desafío, reenvía el CSR a su Autoridad de Certificación (CA), y la CA lo firma y devuelve el certificado público al dispositivo.

A partir de ese momento, cuando el dispositivo se conecta a su SSID de WiFi, presenta ese certificado al servidor RADIUS. El servidor RADIUS valida el certificado contra su cadena de confianza de CA, verifica la Lista de Revocación de Certificados para confirmar que el certificado no haya sido revocado y, si todo está en orden, envía un mensaje de aceptación al punto de acceso. El dispositivo está en la red. Todo el proceso es invisible para el usuario.

Ahora, hablemos de dónde se ubica SCEP en relación con la alternativa, que es PKCS. PKCS (Public Key Cryptography Standards) es el otro método de entrega de certificados compatible con plataformas como Intune. Con PKCS, la CA genera tanto la clave pública como la privada de forma centralizada, y el conector de certificados envía el par de claves al dispositivo. Eso significa que la clave privada viaja a través de la red, lo que introduce una superficie de ataque teórica. PKCS es adecuado para casos de uso como el cifrado de correo electrónico S/MIME, donde el depósito de claves es realmente deseable. Para la autenticación de WiFi, SCEP es la opción correcta. La clave privada se queda en el dispositivo, y punto.

Ahora, la capa de hardware. SCEP y EAP-TLS son estándares neutrales respecto al proveedor, lo que significa que funcionan en puntos de acceso Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme y Fortinet. Su configuración de RADIUS, ya sea Windows NPS, FreeRADIUS o un servicio RADIUS en la nube, es donde usted define la política de validación de certificados y, fundamentalmente, donde configura la asignación dinámica de VLAN.

Las VLAN dinámicas son la forma en que se segmenta la red por identidad. El dispositivo de un estudiante obtiene la VLAN 20 solo para acceso a internet. El dispositivo de un profesor obtiene la VLAN 10 para acceder a los sistemas de investigación internos. Un dispositivo de gestión de instalaciones obtiene la VLAN 30 para acceder a los sistemas de gestión del edificio. Todo esto se gestiona mediante los atributos del certificado y la política de RADIUS, sin intervención manual por dispositivo.

Para la integración con proveedores de identidad, los atributos del certificado SCEP, específicamente el Subject Alternative Name, pueden contener el nombre principal del usuario de Microsoft Entra ID, Okta o Google Workspace. Eso vincula el certificado a una identidad específica, lo que significa que cuando se deshabilita una cuenta en Entra ID y el MDM desvincula el dispositivo, el certificado se revoca y el acceso a WiFi se corta automáticamente. Esa es la historia de revocación que las claves precompartidas simplemente no pueden ofrecer.

Bien, hablemos de la secuencia de implementación, porque aquí es donde la mayoría de los equipos se equivocan.

La secuencia no es negociable: primero el certificado raíz de confianza (Trusted Root), segundo el perfil de certificado SCEP y tercero el perfil de WiFi. Tanto Intune como Jamf aplican dependencias de perfil. Si su perfil de WiFi hace referencia a un certificado SCEP que aún no se ha implementado en el dispositivo, el perfil de WiFi fallará con un error críptico que parece una configuración incorrecta, pero que en realidad es solo un problema de sincronización.

El segundo error común es la segmentación por grupos. Los tres perfiles, Trusted Root, SCEP y WiFi, deben implementarse exactamente en el mismo grupo de Azure AD o Jamf. Si el perfil SCEP se dirige a un grupo de usuarios y el perfil WiFi a un grupo de dispositivos, Intune no podrá resolver la dependencia y el perfil WiFi se mostrará como "No aplicable". Esto toma por sorpresa a los equipos constantemente.

Tercero: la accesibilidad del servidor NDES. Su servidor NDES debe ser accesible desde internet para que los dispositivos puedan registrarse antes de llegar a las instalaciones. La forma correcta de hacerlo es a través de Azure AD Application Proxy, no abriendo un puerto en su firewall. App Proxy le brinda acceso remoto seguro sin puertos entrantes y le permite aplicar políticas de acceso condicional al flujo de registro.

Cuarto: la disponibilidad de la CRL. Su servidor RADIUS verifica la Lista de Revocación de Certificados cada vez que un dispositivo se autentica. Si su punto de distribución de CRL no está disponible, ya sea porque un servidor está caído o porque la URL cambió, la autenticación fallará para todos los dispositivos de la red simultáneamente. Eso representa una caída del servicio en todo el campus. Asegúrese de que sus endpoints de CRL tengan alta disponibilidad y pruebe la revocación antes de salir a producción.

Para redes grandes, de más de 500 dispositivos, considere un gateway SCEP en la nube en lugar de un NDES local. Los gateways en la nube eliminan el punto único de falla de NDES, se escalan horizontalmente y, por lo general, se integran directamente con los servicios RADIUS en la nube, eliminando otra dependencia de infraestructura.

Abordemos algunas preguntas rápidas que escuchamos a menudo de los CTO.

¿Puede SCEP manejar dispositivos BYOD que no están registrados en un MDM? No directamente. SCEP requiere el registro en el MDM para enviar la carga útil del certificado. Para BYOD no administrados, necesita un enfoque diferente, ya sea un portal de autoservicio para la incorporación de usuarios o un SSID independiente que utilice un Captive Portal con verificación de identidad. Purple maneja esa capa de invitados y BYOD de manera limpia, coexistiendo con su red de personal autenticada por certificados.

¿Qué pasa con iOS y Android? Ambas plataformas son compatibles con SCEP de forma nativa. iOS es compatible con SCEP desde iOS 4. Android Enterprise es compatible con SCEP a través de Intune y otros MDM. La configuración es ligeramente diferente según la plataforma, pero el protocolo subyacente es idéntico.

¿Funciona EAP-TLS con WPA3? Sí. WPA3-Enterprise exige un modo de seguridad de 192 bits para entornos sensibles, y EAP-TLS es totalmente compatible. De hecho, WPA3-Enterprise con EAP-TLS es la combinación recomendada por la Wi-Fi Alliance para redes gubernamentales y financieras.

En resumen: la autenticación WiFi mediante certificados SCEP es la arquitectura adecuada para cualquier red con más de 50 dispositivos administrados. Elimina las credenciales compartidas, le brinda identidad por dispositivo, permite la segmentación dinámica de VLAN y se integra directamente con su proveedor de identidad para la revocación automatizada. La secuencia de implementación (Trusted Root, luego el perfil SCEP y después el perfil WiFi) es fija. La segmentación por grupos debe ser consistente. La disponibilidad de la CRL no es opcional.

Específicamente para la educación superior, la combinación de SCEP para los dispositivos del personal y del cuerpo docente, junto con una capa de WiFi para invitados separada para los estudiantes en sus dispositivos personales, le brinda tanto seguridad como una excelente experiencia de usuario sin compromisos.

Si desea profundizar más, la guía de Purple sobre autenticación de WiFi empresarial cubre el camino nativo de la nube. Y si está pensando en lo que sucede cuando un empleado se va, nuestra guía sobre cómo revocar el acceso a WiFi detalla todo el flujo de trabajo de revocación.

Gracias por escucharnos. Soy del equipo técnico de Purple y nos vemos en la próxima sesión informativa.

Puntos clave

✓SCEP (RFC 8894) automatiza el registro de certificados para dispositivos administrados: la clave privada se genera en el dispositivo y nunca se transmite, lo que lo convierte en la opción correcta para la autenticación de WiFi sobre PKCS.
✓La secuencia de implementación no es negociable: primero el certificado Trusted Root, segundo el perfil de certificado SCEP y tercero el perfil de WiFi. Violar este orden provoca fallas de dependencia del perfil.
✓Los tres perfiles de MDM (Trusted Root, SCEP, WiFi) deben dirigirse exactamente al mismo grupo de directorio. La segmentación entre diferentes grupos es la causa más común de fallas de implementación.
✓NDES debe publicarse a través de Azure AD Application Proxy, no exponerse directamente a internet. Para redes de más de 500 dispositivos, una puerta de enlace SCEP en la nube elimina el punto único de falla de NDES.
✓La disponibilidad del punto de distribución CRL es una dependencia crítica de la red. Si el servidor RADIUS no puede comunicarse con la CRL, falla de manera cerrada y deniega toda autenticación simultáneamente.
✓EAP-TLS con certificados provistos por SCEP cumple con el requisito 8.6 de PCI DSS 4.0 para redes inalámbricas en entornos de datos de titulares de tarjetas y es necesario para WPA3-Enterprise de 192 bits (Suite B).
✓SCEP cubre únicamente dispositivos administrados. Los dispositivos BYOD no administrados y de invitados requieren un SSID independiente con Captive Portal y verificación de identidad; la plataforma de Purple maneja esta capa junto con su red de personal autenticada por certificado.

Resumen ejecutivo

Para los entornos empresariales (ya sea un hotel de 200 habitaciones, una cadena minorista con 50 sucursales o un gran centro de convenciones), depender de claves precompartidas para el WiFi del personal representa un riesgo de seguridad y un cuello de botella operativo. Una sola contraseña filtrada expone a toda la red. La autenticación basada en certificados a través de IEEE 802.1X y EAP-TLS (Extensible Authentication Protocol - Transport Layer Security) elimina ese riesgo por completo. Cada dispositivo demuestra su identidad criptográficamente antes de que el punto de acceso le conceda acceso a la red.

El desafío es la distribución. Implementar manualmente certificados de cliente únicos en miles de dispositivos Windows, iOS y Android no es viable. SCEP (Simple Certificate Enrollment Protocol), formalizado como RFC 8894 por la IETF en 2020, resuelve esto. Automatiza el proceso de solicitud, emisión e instalación de certificados digitales en dispositivos administrados a través de su plataforma MDM, sin ninguna interacción del usuario.

Esta guía cubre la arquitectura completa: qué hace SCEP, cómo se integra con Microsoft Intune, Jamf y otras plataformas MDM, la secuencia exacta de implementación en la que la mayoría de los equipos se equivocan y los errores operativos que causan interrupciones. También cubrimos dos escenarios de implementación del mundo real en hotelería y comercio minorista, y explicamos dónde encaja la plataforma de Guest WiFi de Purple junto con la red de su personal autenticada por certificados.

Escuche el podcast informativo complementario:

Análisis técnico profundo: SCEP, PKI y 802.1X

Qué hace realmente SCEP

SCEP no es un reemplazo para su Infraestructura de Clave Pública (PKI). Es la capa de inscripción automatizada que se ejecuta sobre ella. Su PKI (normalmente una jerarquía de dos niveles con una CA raíz fuera de línea y una CA emisora en línea) sigue siendo el ancla de confianza. SCEP automatiza el paso en el que un dispositivo solicita un certificado a esa CA, eliminando la necesidad de generar manualmente una CSR e instalar el certificado.

En el contexto de la autenticación WiFi, el protocolo de destino es EAP-TLS. Este es el método de autenticación 802.1X que requiere que tanto el dispositivo cliente como el servidor RADIUS presenten certificados X.509 válidos. Ninguna de las partes confía en la otra sin una prueba criptográfica. Ese modelo de autenticación mutua elimina el robo de credenciales y protege contra ataques de "evil twin", donde un atacante monta un punto de acceso falso para recopilar nombres de usuario y contraseñas.

Para un desglose detallado del saludo de manos (handshake) EAP-TLS, consulta nuestra guía sobre WiFi Certificate Authentication: Secure Network Access .

El flujo de inscripción SCEP, paso a paso

La cadena de inscripción completa funciona de la siguiente manera. Tu plataforma MDM (Microsoft Intune, Jamf u otro MDM) envía un payload SCEP a un dispositivo administrado. Ese payload contiene dos cosas: la URL de SCEP que apunta a tu servidor NDES (Network Device Enrollment Service) o gateway SCEP en la nube, y una contraseña de desafío o secreto compartido.

El dispositivo genera su propio par de claves pública y privada de forma local. Esta es la propiedad de seguridad crítica de SCEP: la clave privada se genera en el dispositivo, se almacena en el enclave seguro o chip TPM, y nunca se transmite a través de la red. Luego, el dispositivo crea una Solicitud de Firma de Certificado (CSR) y la envía al gateway SCEP. El gateway valida la contraseña de desafío, reenvía la CSR a tu Autoridad de Certificación (CA), y la CA la firma y devuelve el certificado público al dispositivo.

A partir de ese momento, cuando el dispositivo se conecta a tu SSID de WiFi, presenta ese certificado al servidor RADIUS. El servidor RADIUS valida el certificado contra tu cadena de confianza de la CA, verifica la Lista de Revocación de Certificados (CRL) para confirmar que el certificado no haya sido revocado y, si todo está en orden, envía un mensaje de Access-Accept al punto de acceso. El dispositivo está en la red. Todo el proceso es invisible para el usuario.

SCEP vs. PKCS: cuál utilizar para WiFi

Las plataformas MDM como Intune admiten dos mecanismos de entrega de certificados: SCEP y PKCS (Public Key Cryptography Standards). La diferencia arquitectónica es significativa.

Con SCEP, la clave privada se genera en el dispositivo y nunca sale de él. Con PKCS, la Autoridad de Certificación genera tanto la clave pública como la privada de forma centralizada, y el conector de certificados envía el par de claves al dispositivo a través de la red. Eso significa que la clave privada se transmite, lo que introduce una superficie de ataque teórica.

PKCS es adecuado para casos de uso donde se requiere el depósito de claves (key escrow), como el cifrado de correo electrónico S/MIME. Para la autenticación de WiFi, SCEP es la opción correcta. La clave privada permanece en el dispositivo.

Propiedad	SCEP	PKCS
Generación de clave privada	En el dispositivo (TPM/Secure Enclave)	Centralizada (CA)
Transmisión de clave privada	Nunca	A través de la red
Servidor NDES requerido	Sí (o gateway en la nube)	No
Recomendado para WiFi	Sí	No
Recomendado para S/MIME	No	Sí

Compatibilidad de hardware

SCEP y EAP-TLS son estándares neutrales respecto al proveedor. Funcionan en puntos de acceso Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme y Fortinet. Su configuración RADIUS (ya sea Windows NPS, FreeRADIUS o un servicio RADIUS en la nube) es donde se define la política de validación de certificados y la asignación dinámica de VLAN.

La asignación dinámica de VLAN es la forma en que se segmenta la red según la identidad del dispositivo. Un dispositivo del personal obtiene la VLAN 10 con acceso a los sistemas internos. El dispositivo de un contratista obtiene la VLAN 20 con acceso exclusivo a Internet. Una terminal de punto de venta obtiene la VLAN 30 con acceso exclusivo a los sistemas de procesamiento de pagos. Todo esto se gestiona mediante los atributos del certificado y la política de RADIUS, sin intervención manual por dispositivo.

Para obtener más información sobre cómo WiFi Analytics se integra con la segmentación de red basada en la identidad, consulte nuestra descripción general de la plataforma de analíticas.

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

Configurar correctamente SCEP para WiFi empresarial requiere cumplir estrictamente con una secuencia de despliegue específica. Las plataformas MDM imponen dependencias de perfil: un perfil de WiFi que hace referencia a un certificado SCEP no se puede aplicar hasta que ese certificado exista en el dispositivo. Violar esta secuencia es la causa más común de fallas en el despliegue.

La secuencia es: primero la Raíz de Confianza, segundo el perfil SCEP, tercero el perfil de WiFi. Este orden no es negociable.

Paso 1: desplegar el perfil de Certificado de 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 Autoridad de Certificación emisora. Exporte su certificado de CA Raíz (y cualquier certificado de CA Intermedia) como archivos .cer. En su centro de administración de MDM, cree un perfil de Certificado de Confianza, cargue el archivo .cer y despliéguelo en su grupo de dispositivos objetivo.

Si tiene una jerarquía de PKI de dos niveles (recomendado), debe desplegar tanto el certificado de la CA raíz como el de la CA emisora como perfiles de Certificado de Confianza independientes, o como una cadena en un solo perfil, según su plataforma MDM.

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.

Cree un nuevo perfil de configuración y seleccione el tipo de perfil de certificado SCEP. Configure el formato del nombre de sujeto (Subject name). Para la autenticación basada en el usuario, CN={{UserPrincipalName}} es el estándar. Para la autenticación de dispositivos (dispositivos compartidos, IoT, terminales de punto de venta), use CN={{AAD_Device_ID}}. Establezca el uso de clave (Key usage) en Firma digital y Cifrado de clave. Establezca el Uso mejorado de clave (Extended Key Usage) en Autenticación de cliente (OID: 1.3.6.1.5.5.7.3.2). Vincule este perfil al perfil de certificado de Raíz de Confianza creado en el Paso 1. Proporcione la URL externa de su servidor NDES. For Microsoft Intune specifically, the NDES server must be published via Azure AD Application Proxy to allow remote devices to enroll before arriving on-site. Do not expose NDES directly to the internet.

Step 3: deploy the 802.1X WiFi profile

The final step is pushing the WiFi configuration that ties the certificates to the network SSID. Create a Wi-Fi configuration profile. Enter the Network name (SSID) exactly as it is broadcast by your access points. Select WPA2-Enterprise or WPA3-Enterprise as the security type. Set the EAP type to EAP-TLS. In the authentication settings, select the SCEP certificate profile created in Step 2 as the client authentication certificate. Specify the Trusted Root certificate for server validation - this ensures the device only connects to your legitimate RADIUS server and not a rogue access point.

Identity provider integration

SCEP certificate attributes - specifically the Subject Alternative Name (SAN) - can carry the user's principal name from Microsoft Entra ID, Okta, or Google Workspace. This ties the certificate to a specific identity. When you disable an account in Entra ID and the MDM unenrols the device, the certificate is revoked and WiFi access is cut automatically. That automated revocation is the security story that pre-shared keys cannot match.

For more on EAP Method WiFi: A Guide to Secure Network Access , including PEAP-MSCHAPv2 migration paths, see our dedicated guide.

Best practices and industry standards

NDES server placement

The NDES server must be accessible from the internet so that devices can enroll before arriving on-site. Publish the NDES URL via Azure AD Application Proxy. This provides secure remote access without opening inbound firewall ports and allows you to apply Conditional Access policies to the enrollment flow. Never expose NDES directly to the internet.

For networks with more than 500 managed devices, consider a cloud SCEP gateway rather than on-premises NDES. Cloud gateways eliminate the NDES single point of failure, scale horizontally, and typically integrate directly with cloud RADIUS services.

CRL availability

Your RADIUS server checks the Certificate Revocation List every time a device authenticates. If your CRL Distribution Point (CDP) is unavailable - because a server is down or the URL has changed - authentication fails for every device on the network simultaneously. Configure your NPS or RADIUS server to enforce strict CRL checking, and make your CRL endpoints highly available. Test revocation before going live.

PCI DSS 4.0 Requirement 8.6 mandates multi-factor authentication at the network layer for cardholder data environments. EAP-TLS with SCEP-provisioned certificates satisfies this requirement for wireless networks in Retail and Hospitality environments.

WPA3 compatibility

EAP-TLS es totalmente compatible con WPA3-Enterprise. WPA3-Enterprise con la suite de seguridad de 192 bits (Suite B) exige EAP-TLS y es la combinación recomendada por la Wi-Fi Alliance para redes gubernamentales, financieras y de atención médica. Si está realizando un despliegue en entornos de Healthcare o Transport con requisitos estrictos de cumplimiento, WPA3-Enterprise con EAP-TLS es la arquitectura de destino correcta.

BYOD y WiFi de invitados

SCEP requiere el registro en el MDM para enviar la carga útil del certificado. No cubre dispositivos BYOD no administrados ni invitados. Para esos casos de uso, necesita un SSID independiente con un Captive Portal y verificación de identidad. La plataforma de Purple maneja esa capa de manera limpia, coexistiendo con su red de personal autenticada por certificado. Nuestra plataforma de Guest WiFi admite opciones de aceptación consciente, captura de datos de origen e integración con Microsoft Entra ID, Okta y Google Workspace para la verificación de identidad.

Resolución de problemas y mitigación de riesgos

Error al aplicar el perfil de WiFi

Síntoma: El dispositivo recibe los certificados de Raíz de Confianza y SCEP, pero el perfil de WiFi se muestra como Error o No Aplicable en el MDM.

Causa raíz: Desajuste en la asignación de grupos. Si el perfil SCEP se dirige a un grupo de Usuarios y el perfil de WiFi se dirige a un grupo de Dispositivos, el MDM no puede resolver la dependencia.

Solución: Audite sus asignaciones. Asegúrese de que los perfiles de Raíz de Confianza, SCEP y WiFi se dirijan exactamente al mismo grupo de directorio.

Errores NDES 403 Forbidden

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

Causa raíz: La cuenta de servicio del conector de certificados MDM carece de permisos de Lectura e Inscripción en la plantilla de certificado, o el filtrado de URL del firewall está bloqueando los parámetros de la cadena de consulta SCEP.

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

Falla de autenticación masiva tras la expiración de la CRL

Síntoma: Todos los dispositivos de la red fallan al autenticarse simultáneamente.

Causa raíz: La CRL ha expirado o la URL del CDP no está accesible. El servidor RADIUS no puede confirmar que los certificados sean válidos y falla cerrando el acceso.

Solución: Configure el monitoreo y las alertas de la CRL. Publique las CRL con un período de validez significativamente mayor que el intervalo de publicación. Pruebe la accesibilidad del CDP desde el servidor RADIUS antes de la puesta en marcha.

La expiración de certificados causa fallas silenciosas

Síntoma: Dispositivos individuales fallan de manera intermitente al conectarse, sin un patrón claro.

Causa raíz: Los certificados de cliente han expirado y el MDM no los ha renovado con éxito.

Solución: Configure la renovación de certificados para que se active al 80% de la vida útil del certificado. Monitoree los informes de estado de inscripción de MDM para dispositivos con errores de certificado. Establezca períodos de validez de certificados adecuados para el ciclo de renovación de sus dispositivos, normalmente de uno a dos años para terminales administrados.

ROI e impacto empresarial

La transición a la autenticación por certificados 802.1X basada en SCEP ofrece retornos medibles en seguridad, operaciones y cumplimiento.

Reducción de tickets de soporte: El WiFi basado en contraseñas genera un volumen significativo de tickets de soporte: vencimientos de contraseñas, bloqueos y errores de escritura. La autenticación basada en certificados es invisible para el usuario. Las organizaciones suelen ver una reducción del 70-80% en el volumen de soporte relacionado con WiFi después de la migración.

Postura de seguridad: EAP-TLS elimina el robo de credenciales y los ataques de tipo Man-in-the-Middle. Esto respalda directamente el cumplimiento de PCI DSS 4.0 para redes de retail y hospitalidad, así como los requisitos del Artículo 32 de GDPR para medidas de seguridad técnica adecuadas.

Revocación automatizada: Cuando un empleado se va, deshabilitar su cuenta en Microsoft Entra ID activa la revocación automática del certificado y la desinscripción del MDM. El acceso a WiFi se corta sin ninguna intervención manual por parte del equipo de red.

Segmentación de red: La asignación dinámica de VLAN a través de atributos de certificado RADIUS le brinda una segmentación de red aplicada criptográficamente. Los dispositivos llegan al segmento de red correcto según las propiedades del certificado, no por la selección de SSID o el filtrado de direcciones MAC, los cuales se pueden evadir fácilmente.

Purple opera en más de 80,000 sedes activas con un tiempo de actividad del 99.999%, y nuestra plataforma cuenta con las certificaciones ISO 27001, GDPR, CCPA y Cyber Essentials. Nuestra capa de nube agnóstica de hardware se integra con Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme y Fortinet, de modo que su red de personal autenticada por certificado y nuestra capa de WiFi para invitados funcionan desde la misma infraestructura.

Para obtener más información sobre cómo Behavioral Analytics: Insights for WiFi Networks puede complementar su implementación de red segura, consulte nuestra guía de analítica.

Referencias

[1] RFC 8894: Simple Certificate Enrollment Protocol - IETF [2] Configure infrastructure to support SCEP with Intune - Microsoft Learn [3] PCI DSS Wireless Guidelines - PCI Security Standards Council

Definiciones clave

SCEP (Simple Certificate Enrollment Protocol)

Un protocolo formalizado en RFC 8894 que permite a los dispositivos gestionados solicitar y recibir automáticamente certificados digitales X.509 de una Autoridad de Certificación a través de HTTP, utilizando una contraseña de desafío compartida para la autenticación inicial. La clave privada se genera en el dispositivo y nunca se transmite.

El mecanismo estándar utilizado por plataformas MDM como Microsoft Intune y Jamf para implementar certificados de autenticación WiFi en endpoints gestionados a escala.

EAP-TLS (Extensible Authentication Protocol - Transport Layer Security)

El método de autenticación 802.1X más seguro, que requiere que tanto el dispositivo cliente como el servidor RADIUS presenten certificados X.509 válidos. La autenticación mutua significa que ninguna de las partes confía en la otra sin una prueba criptográfica.

El protocolo de autenticación de destino para WiFi empresarial. Obligatorio o fuertemente recomendado por PCI DSS 4.0, WPA3-Enterprise de 192 bits (Suite B) y HIPAA para redes inalámbricas que manejan datos sensibles.

NDES (Network Device Enrollment Service)

Un rol de Microsoft Windows Server que actúa como una Autoridad de Registro (RA) entre los dispositivos habilitados para SCEP y una Autoridad de Certificación. Valida las contraseñas de desafío y reenvía las CSR a la CA en nombre de los dispositivos que carecen de credenciales de dominio.

Infraestructura requerida para la implementación de SCEP con Microsoft Intune. Debe publicarse a través de Azure AD Application Proxy en lugar de exponerse directamente a internet.

PKI (Public Key Infrastructure)

La jerarquía de Autoridades de Certificación, políticas y procedimientos utilizados para emitir, gestionar y revocar certificados digitales. Una PKI de dos niveles consta de una CA raíz fuera de línea (el ancla de confianza maestra) y una CA emisora en línea (que se encarga de la emisión diaria de certificados).

El prerrequisito no negociable para la implementación de EAP-TLS y SCEP. La CA raíz debe mantenerse aislada de la red (air-gapped); su clave privada es la base de toda su cadena de confianza de certificados.

CSR (Certificate Signing Request)

Un mensaje generado por un dispositivo que contiene su clave pública e información de identidad, enviado a una Autoridad de Certificación para solicitar un certificado digital firmado. En SCEP, la CSR se genera en el dispositivo y se empaqueta en un sobre PKCS antes de la transmisión.

Generada automáticamente por el dispositivo durante el flujo de inscripción de SCEP. La clave privada utilizada para firmar la CSR nunca sale del dispositivo.

CRL (Certificate Revocation List)

Una lista publicada por la Autoridad de Certificación que contiene los números de serie de los certificados que han sido revocados antes de su fecha de vencimiento. Los servidores RADIUS verifican la CRL en cada intento de autenticación para garantizar que los certificados revocados no puedan acceder a la red.

La disponibilidad del Punto de Distribución de CRL (CDP) es crítica. Si el servidor RADIUS no puede acceder a la CRL, falla de manera cerrada y niega toda autenticación, lo que provoca una interrupción en toda la red.

RADIUS (Remote Authentication Dial-In User Service)

Un protocolo de red que proporciona Autenticación, Autorización y Contabilidad (AAA) centralizada para el acceso a la red. En WiFi 802.1X, el servidor RADIUS valida los certificados de los clientes, verifica la CRL y devuelve un mensaje de Access-Accept o Access-Reject al punto de acceso.

El servidor de autenticación en el modelo suplicante-autenticador-servidor de 802.1X. Las implementaciones comunes incluyen Windows NPS, FreeRADIUS y servicios RADIUS en la nube.

Asignación dinámica de VLAN

Una función de RADIUS que coloca un dispositivo autenticado en una VLAN específica según los atributos del certificado o la pertenencia a un grupo de directorio, en lugar de depender de la selección de SSID o el filtrado de direcciones MAC. Aplica la segmentación de red mediante la identidad del dispositivo.

Permite que un solo SSID sirva a múltiples tipos de dispositivos con diferentes niveles de acceso a la red. Un dispositivo del personal obtiene la VLAN 10 (acceso interno); el dispositivo de un contratista obtiene la VLAN 20 (solo internet); una terminal POS obtiene la VLAN 30 (solo sistemas de pago).

MDM (Mobile Device Management)

Software utilizado por los equipos de TI para inscribir, configurar, asegurar y gestionar teléfonos inteligentes, tabletas y computadoras portátiles. Las plataformas MDM como Microsoft Intune y Jamf utilizan perfiles SCEP para enviar instrucciones de inscripción de certificados a los dispositivos gestionados sin interacción del usuario.

El prerrequisito para la implementación de certificados basados en SCEP. Los dispositivos deben estar inscritos en el MDM antes de poder recibir los perfiles SCEP y WiFi. Los dispositivos BYOD no gestionados requieren un enfoque de incorporación independiente.

Ejemplos resueltos

Un hotel Premier Inn de 200 habitaciones necesita proteger su WiFi para el personal en tabletas de punto de venta y teléfonos inteligentes de limpieza. Actualmente utilizan una clave precompartida que se ha filtrado a contratistas. Administran los dispositivos a través de Microsoft Intune y tienen una combinación de dispositivos iOS y Android. La propiedad utiliza puntos de acceso HPE Aruba.

Implementar una PKI interna de dos niveles de Microsoft AD CS. Configurar NDES en un Windows Server dedicado y publicarlo a través de Azure AD Application Proxy.
En Intune, crear un perfil de Certificado de Raíz de Confianza que contenga los certificados de la CA Raíz y la CA Emisora. Implementar en un grupo de Azure AD llamado 'Property Staff Devices'.
Crear un perfil de Certificado SCEP en Intune que apunte a la URL externa de NDES. Establecer el formato del Nombre de Sujeto en CN={{AAD_Device_ID}} ya que se trata de dispositivos compartidos. Establecer el Uso de Clave en Firma Digital y Cifrado de Clave, y el Uso de Clave Extendido en Autenticación de Cliente. Implementar en 'Property Staff Devices'.
Crear un perfil de Wi-Fi para el SSID del personal, configurando WPA2-Enterprise y EAP-TLS. Seleccionar el perfil SCEP para la autenticación del cliente y la CA Raíz para la validación del servidor. Implementar en 'Property Staff Devices'.
Configurar los ajustes de RADIUS de HPE Aruba para que apunten a Windows NPS. En NPS, configurar una Política de Red que requiera EAP-TLS y asigne la VLAN 10 para los dispositivos del personal.
Una vez que los dispositivos reciban los perfiles y se conecten correctamente, rotar la PSK en el SSID antiguo y programar su desmantelamiento.

Comentario del examinador: Este enfoque identifica correctamente que los dispositivos compartidos (punto de venta, limpieza) requieren una autenticación basada en el dispositivo (CN={{AAD_Device_ID}}) en lugar de una autenticación basada en el usuario, ya que varios miembros del personal utilizan el mismo dispositivo. Sigue la secuencia obligatoria de implementación de perfiles y garantiza que los tres perfiles se dirijan al mismo grupo de Azure AD. Publicar NDES a través de App Proxy en lugar de una exposición directa a Internet es la postura de seguridad correcta para un entorno de hospitalidad.

Una cadena de tiendas de retail con 50 sucursales desea implementar 802.1X para laptops corporativas en todos sus sitios. Utilizan puntos de acceso Cisco Meraki y Microsoft Intune. No desean implementar ni mantener servidores NDES locales o infraestructura de AD CS en cada sucursal ni en su centro de datos.

Implementar un servicio de PKI en la nube y una puerta de enlace SCEP que se integre con Intune a través del protocolo SCEP. La CA en la nube emite los certificados; la puerta de enlace SCEP en la nube gestiona la validación de CSR.
Configurar el servicio RADIUS en la nube (proporcionado por el proveedor de PKI) dentro del panel de Cisco Meraki en Wireless > Access Control para el SSID corporativo. Establecer la seguridad en WPA2-Enterprise y apuntar RADIUS al servicio en la nube.
En Intune, crear un perfil de Certificado de Raíz de Confianza que contenga el certificado raíz de la CA en la nube. Implementar en el grupo de dispositivos 'Corporate Laptops'.
Crear un perfil de Certificado SCEP que apunte a la URL de la puerta de enlace SCEP en la nube. Establecer el Nombre de Sujeto en CN={{UserPrincipalName}} para la autenticación basada en el usuario. Implementar en 'Corporate Laptops'.
Crear un perfil de Wi-Fi para el SSID corporativo con EAP-TLS, haciendo referencia al perfil SCEP y a la raíz de la CA en la nube. Implementar en 'Corporate Laptops'.
Cuando las laptops se registren en Intune, solicitarán automáticamente certificados a la CA en la nube a través de la puerta de enlace SCEP en la nube. No se requiere infraestructura local en ninguna de las 50 sucursales.

Comentario del examinador: Esta es la arquitectura moderna óptima para entornos de retail distribuidos. Al aprovechar la PKI en la nube y el RADIUS en la nube, la organización elimina la necesidad de mantener una infraestructura local compleja (NDES, AD CS, NPS) en cada sitio. La puerta de enlace SCEP en la nube se escala horizontalmente y es inherentemente de alta disponibilidad, eliminando el punto único de falla que introduce el NDES local. La arquitectura administrada en la nube de Cisco Meraki se alinea perfectamente con este enfoque.

Preguntas de práctica

Q1. Su organización está migrando de PEAP-MSCHAPv2 a EAP-TLS. Ha implementado con éxito los perfiles de Trusted Root y SCEP en su grupo de Azure AD "Corporate Users" en Intune. Implementa el perfil de WiFi en "All Corporate Devices". Los usuarios informan que no pueden conectarse y el perfil de WiFi se muestra como No aplicable.

Sugerencia: Verifique las dependencias del perfil y las reglas de segmentación de grupos. Intune resuelve las dependencias del perfil en función del grupo asignado.

Ver respuesta modelo

El problema es una discrepancia en la segmentación de grupos. El perfil de WiFi depende del perfil SCEP, el cual estaba dirigido a un grupo de usuarios ("Corporate Users"). El perfil de WiFi estaba dirigido a un grupo de dispositivos ("All Corporate Devices"). Intune no puede resolver la dependencia entre diferentes tipos de grupos. La solución es cambiar las asignaciones de los tres perfiles (Trusted Root, SCEP y WiFi) para que se dirijan al mismo grupo. Decida si utilizará un grupo de usuarios o un grupo de dispositivos según su modelo de autenticación (basado en usuario frente a basado en dispositivo) y aplíquelo de manera coherente en los tres perfiles.

Q2. Una auditoría de seguridad revela que cuando se rescinde el contrato de un empleado y se deshabilita su cuenta de Microsoft Entra ID, su teléfono inteligente corporativo aún puede conectarse a la red WiFi del personal hasta una semana después de la rescisión.

Sugerencia: Considere cómo determina el servidor RADIUS si un certificado sigue siendo válido después de que la cuenta se ha deshabilitado. ¿Cuál es el mecanismo para comunicar el estado de revocación?

Ver respuesta modelo

El servidor RADIUS no está realizando una verificación estricta de la Lista de Revocación de Certificados (CRL), o bien la CRL se publica con poca frecuencia. Cuando se rescinde el contrato de un empleado, el MDM debe dar de baja el dispositivo y la CA debe revocar el certificado. Sin embargo, si el servidor RADIUS no verifica la CRL en cada intento de autenticación, o si la CRL solo se publica semanalmente, el certificado revocado se sigue aceptando. La solución implica tres pasos: configurar el servidor RADIUS para exigir una verificación estricta de la CRL en cada autenticación; configurar la CA para publicar la CRL en un intervalo más corto (diario o más frecuente); y asegurarse de que el MDM esté configurado para activar la revocación del certificado cuando se dé de baja un dispositivo.

Q3. Necesita proporcionar acceso WiFi seguro para dispositivos IoT sin pantalla (termostatos inteligentes, reproductores de señalización digital) que no pueden ejecutar un agente MDM y no pueden mostrar un Captive Portal. ¿Puede utilizar SCEP para estos dispositivos? De no ser así, ¿cuál es la alternativa recomendada?

Sugerencia: Considere los requisitos previos para el registro SCEP y qué alternativas existen para los dispositivos que no se pueden registrar en el MDM o que no pueden interactuar con un navegador.

Ver respuesta modelo

No se puede utilizar SCEP para estos dispositivos. SCEP requiere un agente MDM para recibir la URL de registro y la contraseña de desafío, generar el par de claves e instalar el certificado resultante. Los dispositivos IoT sin pantalla que no pueden ejecutar un agente MDM no pueden participar en el flujo de registro SCEP. Las alternativas recomendadas son: (1) MAC Authentication Bypass (MAB) combinado con una segmentación estricta de VLAN: el servidor RADIUS permite el dispositivo en función de su dirección MAC y lo coloca en una VLAN de IoT aislada sin acceso a los sistemas corporativos; (2) si el dispositivo lo admite, EST (Enrollment over Secure Transport, RFC 7030) puede aprovisionar certificados a dispositivos que admiten HTTPS pero no MDM; (3) para dispositivos con una interfaz de administración, algunos proveedores admiten el registro SCEP directamente a través del firmware del dispositivo sin requerir un agente MDM. En todos los casos, los dispositivos IoT deben aislarse en una VLAN dedicada, independientemente del método de autenticación utilizado.

Continúe leyendo esta serie

La guía empresarial de SCEP: Implementación de Simple Certificate Enrollment Protocol para la seguridad automatizada de WiFi en campus

Esta guía de referencia técnica proporciona un diseño arquitectónico definitivo y una estrategia de implementación paso a paso para la distribución de certificados de WiFi empresarial mediante SCEP. Cubre las diferencias críticas entre SCEP y PKCS, la secuencia exacta de implementación requerida para el éxito y las estrategias de mitigación de riesgos del mundo real para los líderes de TI.

Cómo implementar SCEP para la inscripción automatizada de certificados WiFi

Esta guía explica cómo implementar SCEP (Simple Certificate Enrollment Protocol) para la inscripción automatizada de certificados WiFi en entornos empresariales. Cubre el diseño completo de la arquitectura, desde el diseño de PKI y la integración con MDM hasta la secuencia obligatoria de implementación de tres pasos, y muestra a los gerentes de TI y arquitectos de red cómo eliminar las credenciales compartidas, automatizar la gestión del ciclo de vida de los certificados y cumplir con los requisitos de PCI DSS y GDPR a escala.

Entendiendo Cisco SUDI: Identidad de Dispositivo Basada en Hardware en el Control de Acceso a la Red

Esta guía detalla la arquitectura técnica de Cisco SUDI, explicando cómo la identidad anclada en hardware asegura el control de acceso a la red. Proporciona pasos de implementación prácticos para que los líderes de TI desplieguen la autenticación 802.1X EAP-TLS y automaticen el Zero Touch Provisioning en entornos empresariales.