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

Esta guía explica cómo configurar SCEP (Protocolo de registro de certificados simple) 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 directores de TI, arquitectos de red y Directores de Tecnología 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 escalable 802.1X EAP-TLS basada en la identidad. La plataforma superpuesta 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 con la red de su personal autenticada por certificados.

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

Video overview

Escucha esta guía

Ver transcripción del podcast

Le damos la bienvenida a la serie de Informes Técnicos de Purple. Hoy hablaremos 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 lo largo de una red grande. Ya sea un campus universitario, un grupo hotelero de varias sedes o un gran complejo del sector público, los desafíos son idénticos.

Vamos a cubrir el panorama completo: qué hace realmente SCEP, cómo se integra en una arquitectura 802.1X, la secuencia de implementación que la mayoría de los equipos realiza de forma incorrecta, 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 ya sabe qué es un servidor RADIUS y que probablemente ya decidió que necesita alejarse de las claves precompartidas. Lo que necesita ahora es el mapa de implementación.

Comencemos.

Primeros principios. SCEP significa Simple Certificate Enrollment Protocol. Fue formalizado por el IETF como RFC 8894 en 2020, aunque ya se utilizaba ampliamente en entornos empresariales desde hace más de una década. Su trabajo es sencillo: automatizar el proceso de obtención de un certificado digital en un dispositivo gestionado sin necesidad de que una persona tenga que intervenir 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, que se ubica dentro del marco de trabajo 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 configura un punto de acceso no autorizado para recopilar credenciales.

Así es como funciona toda la cadena. Un dispositivo gestionado - la laptop de un estudiante, el teléfono de un miembro 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 de SCEP a ese dispositivo. El payload contiene dos cosas: la URL de SCEP, que apunta a su servidor NDES o gateway de 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 a través de la red. Luego, el dispositivo crea una solicitud de firma de certificado, una CSR, y la envía al gateway de SCEP. El gateway valida el desafío, reenvía la CSR a su Autoridad de Certificación 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 con 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á 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 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, punto final.

Ahora, la capa de hardware. SCEP y EAP-TLS son estándares neutrales del proveedor, lo que significa que funcionan en puntos de acceso de Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti, UniFi, Cambium, Extreme Networks y Fortinet. Su configuración de RADIUS, ya sea Windows NPS, FreeRADIUS o un servicio de 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 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. El dispositivo de administración de las 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 del proveedor 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 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 tropiezan.

La secuencia no es negociable: primero el certificado raíz de confianza, segundo el perfil de certificado SCEP, 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 temporización.
El segundo error común es la segmentación de 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 confunde a los equipos constantemente.

Tercero: accesibilidad del servidor NDES. Su servidor NDES debe estar disponible desde internet para que los dispositivos puedan registrarse antes de llegar al sitio. La forma correcta de hacer esto 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: 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 la CRL no está disponible, ya sea porque un servidor está caído o la URL cambió, la autenticación fallará para todos los dispositivos de la red simultáneamente. Eso significa una caída de red en todo el campus. Asegúrese de que sus puntos finales de CRL tengan alta disponibilidad y pruebe la revocación antes de salir a producción.

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

Abordemos algunas preguntas rápidas que solemos escuchar 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 insertar la carga útil del certificado. Para BYOD no administrados, necesita un enfoque diferente, ya sea un portal de autoservicio de incorporación 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 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 el modo de seguridad de 192 bits para entornos confidenciales, 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 con 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 luego el perfil WiFi - es fija. La segmentación de 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 docente y administrativo, junto con una capa de WiFi para invitados separada para los estudiantes en sus dispositivos personales, le ofrece 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 explica 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 WiFi sobre 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 de WiFi. Violar este orden causa fallas de dependencia de perfiles.
✓Los tres perfiles de MDM (Trusted Root, SCEP, WiFi) deben dirigirse exactamente al mismo grupo de directorio. La asignación a grupos cruzados es la causa más común de fallas 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 puerta de enlace SCEP en la nube elimina el punto único de falla de NDES.
✓La disponibilidad del punto de distribución de CRL es una dependencia crítica de la red. Si el servidor RADIUS no puede comunicarse con la CRL, falla en modo cerrado y niega toda la autenticación de manera simultánea.
✓EAP-TLS con certificados aprovisionados 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 administrados. Los dispositivos BYOD no administrados y los de invitados requieren un SSID independiente con Captive Portal y verificación de identidad - la plataforma de Purple maneja esta capa junto con la red de su personal autenticada por certificados.

📚 Parte de nuestra serie principal: Guía de seguridad de WiFi para empresas →

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

Resumen ejecutivo

Para espacios empresariales - ya sea un hotel de 200 habitaciones, una cadena de retail con 50 ubicaciones o un gran centro de conferencias - depender de claves precompartidas para el WiFi de los empleados 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 por completo ese riesgo. Cada dispositivo demuestra su identidad de forma criptográfica antes de que el punto de acceso le otorgue acceso a la red.

El desafío radica en la distribución. Implementar manualmente certificados de cliente únicos en miles de dispositivos Windows, iOS y Android no es viable. El SCEP (Simple Certificate Enrollment Protocol), formalizado como RFC 8894 por la IETF en 2020, resuelve este problema. 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 toda la arquitectura: qué hace el SCEP, cómo se integra con Microsoft Intune, Jamf y otras plataformas MDM, la secuencia exacta de implementación que la mayoría de los equipos realiza de manera incorrecta y las trampas operativas que causan interrupciones en el servicio. También abordamos dos escenarios reales de implementación en hotelería y retail, y explicamos dónde encaja la plataforma de Guest WiFi de Purple junto a su red de empleados autenticada por certificado.

Escuche el podcast informativo complementario:

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

Lo que SCEP realmente hace

El SCEP no reemplaza su Public Key Infrastructure (PKI). Es la capa de registro automatizada que se posiciona sobre ella. Su PKI - normalmente una jerarquía de dos niveles con una CA raíz offline y una CA emisora online - sigue siendo el anclaje de confianza. El 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 el EAP-TLS. Este es el método de autenticación 802.1X que exige 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. Este modelo de autenticación mutua elimina el robo de credenciales y protege contra los ataques de "evil twin", en los que un atacante crea un punto de acceso falso para recopilar nombres de usuario y contraseñas.

Para un análisis detallado del saludo EAP-TLS, consulte nuestra guía sobre WiFi Certificate Authentication: Secure Network Access .

Cómo configurar SCEP para el registro automatizado de certificados de WiFi empresariales - scep architecture overview

El flujo de registro SCEP, paso a paso

La cadena de registro completa funciona de la siguiente manera. Su plataforma MDM - Microsoft Intune, Jamf u otro MDM - envía una carga útil SCEP a un dispositivo administrado. Esa carga útil contiene dos cosas: la URL del SCEP que apunta a su 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 localmente. 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 por la red. El dispositivo crea entonces un Certificate Signing Request (CSR) y lo envía al gateway SCEP. El gateway valida la contraseña de 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 en relación con su 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 es correcto, envía un mensaje 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 de arquitectura 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 la clave pública y 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.O PKCS é adequado para casos de utilização em que a custódia de chaves é necessária, como a encriptação de e-mail S/MIME. Para a autenticação WiFi, o SCEP é a escolha correta. A chave privada permanece no dispositivo.

Propriedade	SCEP	PKCS
Geração de chave privada	No dispositivo (TPM/Secure Enclave)	Centralizada (CA)
Transmissão de chave privada	Nunca	Através da rede
Servidor NDES necessário	Sim (ou gateway na nuvem)	Não
Recomendado para WiFi	Sim	Não
Recomendado para S/MIME	Não	Sim

Compatibilidade de hardware

O SCEP e o EAP-TLS são normas independentes de fornecedor. Funcionam em pontos de acesso Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme e Fortinet. A sua configuração RADIUS - quer seja Windows NPS, FreeRADIUS ou um serviço RADIUS na nuvem - é onde define a política de validação de certificados e a atribuição dinâmica de VLAN.

A atribuição dinâmica de VLAN é a forma como segmenta a rede através da identidade do dispositivo. Um dispositivo de um funcionário recebe a VLAN 10 com acesso a sistemas internos. O dispositivo de um prestador de serviços recebe a VLAN 20 apenas com acesso à internet. Um terminal de ponto de venda recebe a VLAN 30 apenas com acesso a sistemas de processamento de pagamentos. Tudo isto é gerido por atributos de certificado e pela política RADIUS, sem qualquer intervenção manual por dispositivo.

Para saber mais sobre como o WiFi Analytics se integra com a segmentação de rede baseada em identidade, consulte a nossa visão geral da plataforma de analytics.

Guia de implementação: a sequência de implementação

A configuração bem-sucedida do SCEP para WiFi empresarial exige a adesão estrita a uma sequência de implementação específica. As plataformas MDM impõem dependências de perfil: um perfil de WiFi que faça referência a um certificado SCEP não pode ser aplicado até que esse certificado exista no dispositivo. A violação desta sequência é a causa mais comum de falhas na implementação.

A sequência é: primeiro a Raiz de Confiança (Trusted Root), segundo o perfil SCEP, terceiro o perfil WiFi. Esta ordem não é negociável.

Cómo configurar SCEP para el registro automatizado de certificados de WiFi empresariales - deployment checklist infographic

Passo 1: implementar o perfil de Certificado de Raiz de Confiança (Trusted Root)

Antes de qualquer dispositivo poder solicitar um certificado de cliente ou confiar no seu servidor RADIUS, deve confiar na Autoridade de Certificação (CA) emissora. Exporte o seu certificado de CA Raiz - e quaisquer certificados de CA Intermédia - como ficheiros .cer. No seu centro de administração MDM, crie um perfil de Certificado de Confiança, carregue o ficheiro .cer e implemente-o no seu grupo de dispositivos de destino.

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

Paso 2: configurar el perfil de Certificado SCEP

Una vez que se haya establecido 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 del Solicitante (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 POS), utilice CN={{AAD_Device_ID}}. Defina el Uso de la clave (Key usage) para Firma digital y Cifrado de clave. Defina el Uso de Clave Extendida (Extended Key Usage) para 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. Específicamente para Microsoft Intune, 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 el NDES directamente a internet.

Paso 3: implementar el perfil de WiFi 802.1X

El paso final es enviar la configuración de WiFi que asocia los certificados al SSID de la red. Cree un perfil de configuración de WiFi. Introduzca el Nombre de la red (SSID) exactamente como lo transmiten sus puntos de acceso. Seleccione WPA2 o WPA3 como el tipo de seguridad. Defina el tipo de EAP como EAP-TLS. En los ajustes de autenticación, seleccione el perfil de certificado SCEP creado en el Paso 2 como el certificado de autenticación del cliente. Especifique el certificado Trusted Root 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 Subject Alternative Name (SAN) - pueden contener el nombre principal del usuario de Microsoft Entra ID, Okta o Google Workspace. Esto asocia el certificado a una identidad específica. Cuando desactiva una cuenta en Entra ID y el MDM elimina el registro del dispositivo, el certificado se revoca y el acceso al WiFi se interrumpe automáticamente. Esta revocación automatizada es la historia 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 , incluidos los caminos de migración PEAP-MSCHAPv2, consulte nuestra guía dedicada.

Buenas prácticas y estándares de la industria

Ubicación del servidor NDES

El servidor NDES debe estar accesible desde internet para que los dispositivos se puedan registrar antes de llegar al sitio. Publique la URL del NDES a través de Azure AD Application Proxy. Esto proporciona un acceso remoto seguro sin abrir puertos de firewall de entrada y le permite aplicar políticas de Acceso Condicional al flujo de registro. Nunca exponga el NDES directamente a internet.

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

Disponibilidad de la CRL

Su servidor RADIUS verifica la Lista de Revocación de Certificados (CRL) 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 la URL cambió - la autenticación falla para todos los dispositivos en la red de forma simultánea. Configure su servidor NPS o RADIUS para imponer una verificación estricta de la CRL y haga que sus endpoints de CRL sean altamente disponibles. Pruebe la revocación antes de entrar en producción.

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

Compatibilidad con WPA3

El EAP-TLS es totalmente compatible con WPA3-Enterprise. El 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 salud. Si está realizando una implementación en entornos de Saúde o Transportes con requisitos de cumplimiento estrictos, 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 el payload del certificado. No cubre dispositivos BYOD no gestionados o de invitados. Para esos casos de uso, necesita un SSID separado con un Captive Portal y verificación de identidad. La plataforma de Purple maneja esa capa de forma limpia, coexistiendo con su red de empleados autenticada por certificado. Nuestra plataforma de Guest WiFi soporta opt-ins de elección consciente, captura de datos de primera mano (first-party) 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

Falla en la aplicación del perfil de WiFi

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

Causa raíz: Incompatibilidad de segmentación de grupo. 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 Trusted Root, SCEP y WiFi se dirijan todos exactamente al mismo grupo de directorio.

Errores NDES 403 Forbidden

Síntoma: Los dispositivos no pueden obtener el certificado SCEP. Los registros de IIS del NDES muestran errores HTTP 403.

Causa raíz: La cuenta de servicio del MDM Certificate Connector no tiene permisos de Lectura e Inscripción (Read and Enroll) en la plantilla de certificado, o el filtrado de URL del firewall está bloqueando los parámetros de la cadena de consulta (query string) de 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 garantizar 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 en la autenticación de manera simultánea.

Causa raíz: La CRL expiró o la URL del CDP no está accesible. El servidor RADIUS no puede confirmar si los certificados son válidos y por defecto deniega el acceso (fails closed).

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 del lanzamiento.

Expiración de certificados que causa fallas silenciosas

Síntoma: Dispositivos individuales pierden la conexión de forma intermitente sin un patrón claro.

Causa raíz: Los certificados de cliente expiraron y el MDM no los renovó con éxito.

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

ROI e impacto empresarial

La transición a la autenticación por certificado 802.1X basada en SCEP ofrece retornos medibles 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 técnico por expiración de contraseñas, bloqueos 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 WiFi tras la migración.

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

Revogação automatizada: Quando um colaborador sai da empresa, a desativação da sua conta no Microsoft Entra ID aciona a revogação automática do certificado e a desassociação do MDM. O acesso ao WiFi é cortado sem qualquer intervenção manual por parte da equipa de rede.

Segmentação de rede: A atribuição dinâmica de VLAN através de atributos de certificado RADIUS oferece-lhe uma segmentação de rede aplicada de forma criptográfica. Os dispositivos entram no segmento de rede correto com base nas propriedades do certificado, e não na seleção de SSID ou na filtragem de endereços MAC - ambas facilmente contornáveis.

A Purple opera em mais de 80.000 locais ativos com 99,999% de tempo de atividade, e a nossa plataforma possui as certificações ISO 27001, GDPR, CCPA e Cyber Essentials. A nossa sobreposição de nuvem agnóstica em termos de hardware integra-se com Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme e Fortinet - para que a sua rede de colaboradores autenticada por certificado e a nossa camada de WiFi de convidados funcionem a partir da mesma infraestrutura.

Para saber mais sobre como a análise comportamental ( Behavioral Analytics: Insights for WiFi Networks ) pode complementar a sua implementação de rede segura, consulte o nosso guia de análise.

Referências

[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 el RFC 8894 que permite a los dispositivos gestionados solicitar y recibir automáticamente certificados digitales X.509 de una Entidad 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 Entidad de Registro (RA) entre los dispositivos habilitados para SCEP y una Entidad 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 Entidades 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 el despliegue 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 la 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 Entidad 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 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 la CRL (CDP) es fundamental. Si el servidor RADIUS no puede acceder a la CRL, falla en modo cerrado y deniega todas las autenticaciones, lo que provoca una interrupción en toda la red.

RADIUS (Remote Authentication Dial-In User Service)

Un protocolo de red que proporciona servicios centralizados de autenticación, autorización y contabilidad (AAA) para el acceso a la red. En redes WiFi con 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 de 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 ubica 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 del filtrado de direcciones MAC. Aplica la segmentación de red según la identidad del dispositivo.

Permite que un solo SSID funcione para múltiples tipos de dispositivos con diferentes niveles de acceso a la red. Un dispositivo de personal obtiene la VLAN 10 (acceso interno); un dispositivo de contratista obtiene la VLAN 20 (solo internet); una 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 administrar 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 administrados sin intervenció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 de SCEP y WiFi. Los dispositivos BYOD no administrados requieren un enfoque de incorporación independiente.

Ejemplos resueltos

Un hotel Premier Inn de 200 habitaciones necesita asegurar su WiFi para el personal destinado a las tabletas de punto de venta y los 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. El hotel utiliza puntos de acceso HPE Aruba.

Implemente una PKI interna de Microsoft AD CS de dos niveles. Configure NDES en un Windows Server dedicado y publíquelo a través de Azure AD Application Proxy.
En Intune, cree un perfil de Certificado raíz de confianza que contenga los certificados de la CA raíz y de la CA emisora. Impleméntelo en un grupo de Azure AD llamado "Property Staff Devices".
Cree un perfil de Certificado SCEP en Intune que apunte a la URL externa de NDES. Establezca el formato del Nombre de sujeto en CN={{AAD_Device_ID}}, ya que se trata de dispositivos compartidos. Establezca el Uso de clave en Firma digital y Cifrado de clave, y el Uso extendido de clave en Autenticación de cliente. Impleméntelo en "Property Staff Devices".
Cree un perfil de Wi-Fi para el SSID del personal, configurando WPA2-Enterprise y EAP-TLS. Seleccione el perfil SCEP para la autenticación del cliente y la CA raíz para la validación del servidor. Impleméntelo en "Property Staff Devices".
Configure los ajustes de RADIUS de HPE Aruba para que apunten a Windows NPS. En NPS, configure 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, cambie la PSK en el antiguo SSID y programe su desactivación.

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 la exposición directa a internet es la postura de seguridad adecuada para un entorno de hospitalidad.

Una cadena 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 ni infraestructura AD CS en cada sucursal ni en su centro de datos.

Implementar un servicio de PKI en la nube y de puerta de enlace SCEP que se integre con Intune mediante el protocolo SCEP. La CA en la nube emite los certificados; la puerta de enlace SCEP en la nube gestiona la validación de la 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 Trusted Root Certificate 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 puerta de enlace SCEP en la nube. Establecer el Subject Name como CN={{UserPrincipalName}} para la autenticación basada en usuarios. Desplegar en "Corporate Laptops".
Crear un perfil de WiFi 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 las laptops se inscriben en Intune, solicitan automáticamente los 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 ubicaciones.

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 compleja infraestructura local (NDES, AD CS, NPS) en cada sitio. La puerta de enlace SCEP en la nube se escala horizontalmente y es intrínsecamente de alta disponibilidad, lo que elimina el punto único de falla que introduce el 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 con éxito los perfiles de raíz de confianza y SCEP en su grupo de Azure AD 'Corporate Users' en Intune. Luego, 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 de perfil y las reglas de asignación de grupos. Intune resuelve las dependencias de perfil en función del grupo asignado.

Ver respuesta modelo

El problema se debe a una discrepancia en la asignación de grupos. El perfil de WiFi depende del perfil SCEP, el cual 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 asignaciones de los tres perfiles - raíz de confianza, 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 usuarios frente a basado en dispositivos) 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 el servidor RADIUS determina 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 verificación estricta de la Lista de Revocación de Certificados, o la CRL se publica de manera poco frecuente. Cuando se da de baja a un empleado, el MDM debe desvincular 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 asegurar que el MDM esté configurado para activar la revocación del certificado cuando se desvincule 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 ni mostrar un Captive Portal. ¿Puede usar SCEP para estos dispositivos? Y si no, ¿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 usar SCEP para estos dispositivos. SCEP requiere que un agente MDM reciba la URL de registro y la contraseña de desafío, genere el par de claves e instale 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 según 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 (Enrolment 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

Comprensión de Cisco SUDI: Identidad anclada por hardware en el control de acceso seguro a la red

Esta guía explica cómo Cisco SUDI proporciona una identidad criptográficamente segura y anclada por hardware para la infraestructura de red empresarial. Aprenda cómo reemplazar las direcciones MAC vulnerables a la suplantación por certificados 802.1AR inmutables para proteger el control de acceso a la red de su recinto.

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.