Cómo configurar SCEP para el registro automatizado de certificados WiFi corporativos

Esta guía explica cómo configurar SCEP (Simple Certificate Enrollment Protocol) para el registro automatizado de certificados WiFi corporativos, abarcando toda la arquitectura desde PKI y NDES hasta el despliegue de perfiles MDM y la validación RADIUS. Está dirigida a directores de TI, arquitectos de red y CTO de hoteles, cadenas de retail, estadios, centros de conferencias 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 independiente del hardware, se integra directamente con esta arquitectura, proporcionando la capa de WiFi para invitados y BYOD que coexiste junto a la red de personal autenticada por certificado.

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

Escuchar esta guía

Ver transcripción del podcast

Le damos la bienvenida 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, en una red de gran tamaño. Ya se trate de un campus universitario, un grupo hotelero con múltiples sedes o un gran complejo del sector público, los retos son idénticos.

Vamos a cubrir todo el panorama. Qué hace realmente SCEP, cómo encaja en una arquitectura 802.1X, la secuencia de despliegue en la que la mayoría de los equipos se equivocan, dos escenarios de implementación del mundo real y los errores 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 lo que 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.

Entremos en materia.

Principios básicos. SCEP son las siglas de Simple Certificate Enrollment Protocol (Protocolo de registro de certificados simple). Fue formalizado por el IETF como RFC 8894 en 2020, aunque ya se utilizaba de forma generalizada en las 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 gestionado 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 que se busca es EAP-TLS (Extensible Authentication Protocol with Transport Layer Security), que se encuadra dentro del marco 802.1X. EAP-TLS está considerado de forma generalizada 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 le protege contra los ataques de "evil twin" (gemelo malvado), en los que un atacante levanta un punto de acceso no autorizado para recopilar credenciales.

Así es como funciona toda la cadena. Un dispositivo gestionado (el portátil de un estudiante, el teléfono de un empleado, un 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 una carga útil de SCEP a ese dispositivo. La carga útil contiene dos cosas: la URL de SCEP, que apunta a su servidor NDES o pasarela 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 propio dispositivo, se almacena en el enclave seguro o TPM y nunca se transmite por la red. A continuación, el dispositivo crea una solicitud de firma de certificado (CSR) y la envía a la pasarela SCEP. La pasarela valida el desafío, reenvía la CSR a su entidad 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 su SSID de WiFi, presenta ese certificado al servidor RADIUS. El servidor RADIUS valida el certificado contra su cadena de confianza de CA, comprueba la Lista de Revocación de Certificados para confirmar que el certificado no ha sido revocado y, si todo es correcto, envía un mensaje de aceptación al punto de acceso. El dispositivo ya está en la red. Todo el proceso es invisible para el usuario.

Ahora, hablemos de dónde se sitúa 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. Esto significa que la clave privada viaja por 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 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 de 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 se define la política de validación de certificados y, fundamentalmente, donde se configura la asignación dinámica de VLAN.

Las VLAN dinámicas son la forma de segmentar 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 ninguna intervención manual por dispositivo.

Para la integración con proveedores de identidad, los atributos de certificado SCEP, específicamente el Subject Alternative Name, pueden contener el nombre principal de usuario de Microsoft Entra ID, Okta o Google Workspace. Esto vincula el certificado a una identidad específica, lo que significa que cuando se deshabilita una cuenta en Entra ID y el MDM retira el dispositivo, el certificado se revoca y el acceso a la 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 despliegue, porque aquí es donde la mayoría de los equipos se equivocan.

La secuencia no es negociable: primero el certificado raíz de confianza, segundo el perfil de certificado SCEP y tercero el perfil de WiFi. Tanto Intune como Jamf imponen dependencias de perfil. Si su perfil de WiFi hace referencia a un certificado SCEP que aún no se ha desplegado 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 temporal.

El segundo error común es la segmentación por grupos. Los tres perfiles, Trusted Root, SCEP y WiFi, deben desplegarse 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 suele pillar desprevenidos 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 cortafuegos. App Proxy le ofrece un 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 comprueba la lista de revocación de certificados (CRL) cada vez que un dispositivo se autentica. Si el punto de distribución de su CRL no está disponible, ya sea porque un servidor está caído o porque la URL ha cambiado, la autenticación fallará para todos los dispositivos de la red simultáneamente. Eso se traduce en una caída de toda la sede. Asegúrese de que sus endpoints de CRL tengan una alta disponibilidad y pruebe la revocación antes de la puesta en marcha.

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

Abordemos ahora algunas preguntas rápidas que solemos escuchar de los CTO.

¿Puede SCEP gestionar dispositivos BYOD que no están registrados en el MDM? No directamente. SCEP requiere el registro en el MDM para enviar la carga útil del certificado. Para BYOD no gestionados, se necesita un enfoque diferente: un portal de autogestión para la incorporación de usuarios o un SSID independiente que utilice un Captive Portal con verificación de identidad. Purple gestiona esa capa de invitados y BYOD de forma limpia, conviviendo con su red de empleados autenticada por certificados.

¿Qué ocurre con iOS y Android? Ambas plataformas son compatibles con SCEP de forma nativa. iOS es compatible con SCEP desde iOS 4. Android Enterprise admite SCEP a través de Intune y otros MDM. La configuración varía ligeramente 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 gestionados. Elimina las credenciales compartidas, proporciona una 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 despliegue (Trusted Root, luego perfil SCEP y, por último, perfil WiFi) es fija. La segmentación por grupos debe ser coherente. 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 profesorado, junto con una capa de WiFi para invitados independiente para los estudiantes en sus dispositivos personales, le ofrece tanto seguridad como una excelente experiencia de usuario sin concesiones.

Si desea profundizar más, la guía de Purple sobre autenticación WiFi empresarial cubre el camino nativo de la nube. Y si está pensando en qué ocurre cuando un empleado se marcha, 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.

Conclusiones clave

✓SCEP (RFC 8894) automatiza el registro de certificados para dispositivos gestionados: 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 WiFi frente a PKCS.
✓La secuencia de despliegue no es negociable: primero el certificado de raíz de confianza (Trusted Root), segundo el perfil de certificado SCEP y tercero el perfil WiFi. Violar este orden provoca fallos de dependencia de perfil.
✓Los tres perfiles de MDM (Trusted Root, SCEP, WiFi) deben dirigirse exactamente al mismo grupo de directorio. El direccionamiento entre diferentes grupos es la causa más común de fallos de despliegue.
✓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 pasarela SCEP en la nube elimina el punto único de fallo de NDES.
✓La disponibilidad del punto de distribución de la CRL es una dependencia crítica de la red. Si el servidor RADIUS no puede acceder a la CRL, falla por seguridad (fails closed) y deniega todas las autenticaciones 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 obligatorio para WPA3-Enterprise de 192 bits (Suite B).
✓SCEP cubre únicamente dispositivos gestionados. Los dispositivos BYOD no gestionados y de invitados requieren un SSID independiente con Captive Portal y verificación de identidad; la plataforma de Purple gestiona esta capa junto con la red de su personal autenticada por certificado.

Resumen ejecutivo

Para los establecimientos empresariales (ya sea un hotel de 200 habitaciones, una cadena minorista con 50 tiendas o un gran centro de conferencias), depender de claves precompartidas para el WiFi del personal es 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 certificados de cliente únicos en miles de dispositivos Windows, iOS y Android de forma manual no es viable. SCEP (Simple Certificate Enrollment Protocol), formalizado como RFC 8894 por el IETF en 2020, resuelve esto. Automatiza el proceso de solicitud, emisión e instalación de certificados digitales en dispositivos gestionados 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 fallos operativos que causan interrupciones. También cubrimos dos escenarios de implementación del mundo real en hostelería y comercio minorista, y explicamos dónde encaja la plataforma de Guest WiFi de Purple junto a su red de 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 sustituto de su Infraestructura de Clave Pública (PKI). Es la capa de inscripción automatizada que se asienta 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 solicitudes de firma de certificado (CSR) e instalar certificados.

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 los ataques de "gemelo malvado" (evil twin), en los que un atacante levanta un punto de acceso no autorizado para recopilar nombres de usuario y contraseñas.

Para obtener un desglose detallado del protocolo de enlace EAP-TLS, consulte nuestra guía sobre Autenticación de certificados WiFi: Acceso seguro a la red .

El flujo de inscripción SCEP, paso a paso

La cadena de inscripción completa funciona de la siguiente manera. Su plataforma MDM (Microsoft Intune, Jamf u otro MDM) envía un payload SCEP a un dispositivo gestionado. Ese payload contiene dos cosas: la URL de SCEP que apunta a su servidor NDES (Network Device Enrollment Service) o pasarela 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. A continuación, el dispositivo crea una Solicitud de Firma de Certificado (CSR) y la envía a la pasarela SCEP. La pasarela valida la contraseña de desafío, reenvía la CSR a su Entidad 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 su SSID de WiFi, presenta ese certificado al servidor RADIUS. El servidor RADIUS valida el certificado frente a su cadena de confianza de la CA, comprueba la Lista de Revocación de Certificados (CRL) para confirmar que el certificado no ha sido revocado y, si todo es correcto, 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 frente a 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 Entidad 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. Esto significa que la clave privada se transmite, lo que introduce una superficie de ataque teórica.

PKCS es adecuado para casos de uso en los que se requiere el depósito de claves, como el cifrado de correo electrónico S/MIME. Para la autenticación 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 pasarela 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 independientes del fabricante. 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 se definen 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 de segmentar 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. Un 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 la descripción general de nuestra plataforma de analítica.

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

Configurar correctamente SCEP para WiFi empresarial requiere cumplir estrictamente 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 dicho certificado exista en el dispositivo. No respetar esta secuencia es la causa más común de fallos en el despliegue.

La secuencia es: primero, la raíz de confianza (Trusted Root); 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 (Trusted Root)

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 (CA) 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 (Trusted Certificate), cargue el archivo .cer y despliéguelo en su grupo de dispositivos de destino.

Si dispone de una jerarquía de PKI de dos niveles (recomendado), deberá 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 único 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, lo habitual es CN={{UserPrincipalName}}. Para la autenticación de dispositivos (dispositivos compartidos, IoT, terminales de punto de venta), utilice CN={{AAD_Device_ID}}. Establezca el uso de clave (Key usage) en Firma digital y Cifrado de clave. Establezca el uso de clave extendido (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.Para Microsoft Intune específicamente, el servidor NDES debe publicarse a través de Azure AD Application Proxy para permitir que los dispositivos remotos se registren antes de llegar a las instalaciones. No exponga NDES directamente a internet.

Paso 3: implementar el perfil de WiFi 802.1X

El paso final es enviar la configuración de WiFi que vincula los certificados al SSID de la red. Cree un perfil de configuración de Wi-Fi. Introduzca el nombre de la red (SSID) exactamente como lo transmiten sus puntos de acceso. Seleccione WPA2-Enterprise o WPA3-Enterprise como tipo de seguridad. Establezca el tipo de EAP en EAP-TLS. 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. Especifique el certificado raíz de confianza para la validación del servidor; esto garantiza que el dispositivo solo se conecte a su servidor RADIUS legítimo y no a un punto de acceso no autorizado.

Integración del proveedor de identidad

Los atributos del certificado SCEP, específicamente el Nombre alternativo del sujeto (SAN), pueden contener el nombre principal del usuario de Microsoft Entra ID, Okta o Google Workspace. Esto vincula el certificado a una identidad específica. Cuando desactiva una cuenta en Entra ID y el MDM anula el registro del dispositivo, el certificado se revoca y el acceso a WiFi se corta automáticamente. Esa revocación automatizada es la ventaja de seguridad que las claves precompartidas no pueden igualar.

Para obtener más información sobre EAP Method WiFi: A Guide to Secure Network Access , incluidas las rutas de migración de PEAP-MSCHAPv2, consulte nuestra guía dedicada.

Buenas prácticas y estándares del sector

Ubicación del servidor NDES

El servidor NDES debe ser accesible desde internet para que los dispositivos puedan registrarse antes de llegar a las instalaciones. Publique la URL de NDES a través de Azure AD Application Proxy. Esto proporciona un acceso remoto seguro sin abrir puertos de entrada en el cortafuegos y le permite aplicar políticas de acceso condicional al flujo de registro. Nunca exponga NDES directamente a internet.

Para redes con más de 500 dispositivos gestionados, considere una pasarela SCEP en la nube en lugar de un NDES local. Las pasarelas en la nube eliminan el punto único de fallo de NDES, se escalan horizontalmente y, por lo general, se integran directamente con los servicios RADIUS en la nube.

Disponibilidad de la CRL

Su servidor RADIUS comprueba la Lista de revocación de certificados cada vez que un dispositivo se autentica. Si su Punto de distribución de CRL (CDP) no está disponible, ya sea porque un servidor está caído o porque la URL ha cambiado, la autenticación fallará para todos los dispositivos de la red simultáneamente. Configure su servidor NPS o RADIUS para aplicar una comprobación estricta de la CRL y haga que sus puntos de conexión de CRL sean de alta disponibilidad. Pruebe la revocación antes de la puesta en marcha.

El requisito 8.6 de PCI DSS 4.0 exige la autenticación multifactor en la capa de red para los entornos de datos de titulares de tarjetas. EAP-TLS con certificados provistos por SCEP cumple con este requisito para redes inalámbricas en entornos de Retail y Hospitality .

Compatibilidad con WPA3

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 sanitarias. Si está realizando un despliegue en entornos de Sanidad o Transporte con requisitos de cumplimiento estrictos, WPA3-Enterprise con EAP-TLS es la arquitectura de destino correcta.

BYOD y WiFi para invitados

SCEP requiere el registro en el MDM para enviar la carga útil del certificado. No cubre los dispositivos BYOD no gestionados ni a los invitados. Para esos casos de uso, necesita un SSID independiente con un Captive Portal y verificación de identidad. La plataforma de Purple gestiona esa capa de forma limpia, coexistiendo con la red de su personal autenticada mediante certificados. Nuestra plataforma de Guest WiFi admite opciones de consentimiento explícito, 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 (Read and Enroll) en la plantilla de certificado, o el filtrado de URL del cortafuegos 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 cortafuegos para asegurarse de que no se bloqueen las URL que contienen ?operation=GetCACaps.

Fallo masivo de autenticación 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 deniega el acceso por seguridad.

Solución: Configure la supervisión y las alertas de la CRL. Publique las CRL con un periodo de validez significativamente superior al intervalo de publicación. Pruebe la accesibilidad del CDP desde el servidor RADIUS antes de la puesta en marcha.

La expiración de certificados provoca fallos silenciosos

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

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

Solución: Configure la renovación de certificados para que se active al 80 % de la vida útil del certificado. Supervise los informes de estado de registro de MDM para detectar dispositivos con errores de certificado. Establezca periodos de validez de los certificados adecuados para el ciclo de renovación de sus dispositivos, normalmente de uno a dos años para los terminales gestionados.

ROI e impacto empresarial

La transición a la autenticación por certificados 802.1X basada en SCEP ofrece un retorno de la inversión medible en términos de seguridad, operaciones y cumplimiento.

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

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

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

Segmentación de red: La asignación dinámica de VLAN a través de atributos de certificado RADIUS le proporciona una segmentación de red aplicada criptográficamente. Los dispositivos acceden al segmento de red correcto en función de las propiedades del certificado, no de la selección de SSID o del filtrado de direcciones MAC, métodos que se pueden eludir 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 software en la nube, independiente del 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 despliegue de red seguro, 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 desplegar 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 el despliegue 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 gestiona la emisión diaria de certificados).

El requisito previo no negociable para el despliegue de EAP-TLS y SCEP. La CA raíz debe mantenerse aislada (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 caducidad. Los servidores RADIUS comprueban 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 forma segura bloqueando el acceso y deniega 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, comprueba 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.

Dynamic VLAN assignment

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

Permite que un único 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); un terminal de punto de venta obtiene la VLAN 30 (solo sistemas de pago).

MDM (Mobile Device Management)

Software utilizado por los equipos de TI para inscribir, configurar, proteger y gestionar smartphones, tablets y 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 requisito previo para el despliegue de certificados basado en SCEP. Los dispositivos deben estar inscritos en el MDM antes de poder recibir los perfiles de SCEP y WiFi. Los dispositivos BYOD no gestionados requieren un enfoque de incorporación independiente.

Ejemplos prácticos

Un hotel Premier Inn de 200 habitaciones necesita proteger su WiFi para el personal, destinado a tabletas de punto de venta y smartphones del servicio de limpieza. Actualmente utilizan una clave precompartida que se ha filtrado a contratistas externos. Gestionan los dispositivos a través de Microsoft Intune y tienen una combinación de dispositivos iOS y Android. El establecimiento utiliza puntos de acceso HPE Aruba.

Implementar una PKI interna de dos niveles de Microsoft AD CS. Configurar NDES en un servidor Windows 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 de la CA Emisora. Desplegarlo 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 como CN={{AAD_Device_ID}}, ya que se trata de dispositivos compartidos. Configurar el Uso de Clave para Firma Digital y Cifrado de Clave, y el Uso Extendido de Clave para Autenticación de Cliente. Desplegar 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. Desplegar en 'Property Staff Devices'.
Configurar los ajustes de RADIUS de HPE Aruba para que apunten a Windows NPS. En NPS, configurar una Directiva 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 (TPV, 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 despliegue 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 hostelería.

Una cadena de tiendas con 50 ubicaciones quiere desplegar 802.1X para portátiles corporativos en todos sus centros. Utilizan puntos de acceso Cisco Meraki y Microsoft Intune. No desean desplegar ni mantener servidores NDES locales ni infraestructura AD CS en cada ubicación ni en su centro de datos.

Implementar un servicio de pasarela SCEP y PKI basado en la nube que se integre con Intune a través del protocolo SCEP. La CA en la nube emite los certificados; la pasarela SCEP en la nube gestiona la validación de las 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. Desplegar en el grupo de dispositivos 'Corporate Laptops'.
Crear un perfil de Certificado SCEP que apunte a la URL de la pasarela SCEP en la nube. Establecer el Nombre de Sujeto como CN={{UserPrincipalName}} para la autenticación basada en el usuario. Desplegar 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. Desplegar en 'Corporate Laptops'.
Cuando los portátiles se registran en Intune, solicitan automáticamente certificados a la CA en la nube a través de la pasarela SCEP en la nube. No se requiere infraestructura local en ninguna de las 50 ubicaciones.

Comentario del examinador: Esta es la arquitectura moderna óptima para entornos de retail distribuidos. Al aprovechar la PKI en la nube y el servicio RADIUS en la nube, la organización elimina la necesidad de mantener una infraestructura local compleja (NDES, AD CS, NPS) en cada centro. La pasarela SCEP en la nube escala horizontalmente y es intrínsecamente de alta disponibilidad, eliminando el punto único de fallo que introduce NDES local. La arquitectura gestionada 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 correctamente los perfiles de SCEP y de raíz de confianza en su grupo de Azure AD "Corporate Users" en Intune. Implementa el perfil de WiFi en "All Corporate Devices". Los usuarios informan de que no pueden conectarse y el perfil de WiFi aparece como No aplicable.

Sugerencia: Comprueba 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 de SCEP, que se asignó a un grupo de usuarios ("Corporate Users"). El perfil de WiFi se asignó a un grupo de dispositivos ("All Corporate Devices"). Intune no puede resolver la dependencia entre diferentes tipos de grupos. La solución consiste en cambiar las tres asignaciones de perfil (raíz de confianza, SCEP y WiFi) para que se dirijan al mismo grupo. Decida si desea utilizar un grupo de usuarios o un grupo de dispositivos en función de su modelo de autenticación (basado en usuarios frente a basado en dispositivos) y aplíquelo de forma coherente en los tres perfiles.

Q2. Una auditoría de seguridad revela que cuando se despide a un empleado y se deshabilita su cuenta de Microsoft Entra ID, su smartphone corporativo aún puede conectarse a la red WiFi del personal hasta una semana después del despido.

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

Ver respuesta modelo

El servidor RADIUS no está realizando una comprobación estricta de la lista de revocación de certificados (CRL), o bien la CRL se publica con poca frecuencia. Cuando se despide a un empleado, el MDM debe anular el registro del dispositivo y la CA debe revocar el certificado. Sin embargo, si el servidor RADIUS no comprueba 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 consta de tres pasos: configurar el servidor RADIUS para exigir una comprobació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 anule el registro de un dispositivo.

Q3. Debe 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 y, si no es así, cuál es la alternativa recomendada?

Sugerencia: Considere los requisitos previos para el registro de 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 de 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 en dispositivos que admiten HTTPS pero no MDM; (3) para dispositivos con una interfaz de gestión, algunos proveedores admiten el registro de SCEP directamente a través del firmware del dispositivo sin necesidad de un agente MDM. En cualquier caso, 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: Despliegue 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 el despliegue de certificados WiFi empresariales mediante SCEP. Cubre las diferencias críticas entre SCEP y PKCS, la secuencia exacta de despliegue requerida para el éxito y estrategias reales de mitigación de riesgos para líderes de TI.

Cómo implementar SCEP para el registro automatizado de certificados WiFi

Esta guía explica cómo implementar SCEP (Simple Certificate Enrollment Protocol) para el registro automatizado de certificados WiFi en entornos empresariales. Cubre el diseño arquitectónico completo, desde el diseño de PKI y la integración con MDM hasta la secuencia de despliegue obligatoria de tres pasos, y muestra a los responsables 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.

Introducción a Cisco SUDI: Identidad de dispositivos basada en hardware en el control de acceso a la red

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