Cómo configurar SCEP para WiFi corporativo seguro y aprovisionamiento BYOD

Esta guía técnica explica cómo configurar el protocolo SCEP (Simple Certificate Enrolment Protocol) para automatizar la autenticación segura de WiFi corporativo 802.1X y el aprovisionamiento BYOD. Proporciona a los arquitectos de red y directores de TI una secuencia de implementación definitiva, escenarios de implementación reales en los sectores de hostelería y retail, y estrategias de mitigación de riesgos para eliminar las claves precompartidas vulnerables y el bypass de autenticación MAC de las redes corporativas.

📖 8 min de lectura📝 1,754 palabras🔧 2 ejemplos prácticos❓ 4 preguntas de práctica📚 10 definiciones clave

Escuchar esta guía

Ver transcripción del podcast

Bienvenido a este informe técnico de Purple. Soy su anfitrión y hoy vamos a profundizar en la configuración de SCEP para el aprovisionamiento de WiFi corporativo seguro y BYOD.

Para los directores de TI, arquitectos de red y CTO que operan en los sectores de hostelería, comercio minorista y público, gestionar el acceso a la red es un equilibrio constante entre la seguridad y la eficiencia operativa. Se enfrentan a cientos, a veces miles, de dispositivos que se conectan a su red todos los días. Smartphones de empleados, portátiles de contratistas, tabletas de puntos de venta. Y los métodos antiguos para gestionar esto ya no son suficientes.

Confiar en las claves precompartidas, o PSK, para el WiFi de empleados y BYOD es una vulnerabilidad de seguridad que tarde o temprano será explotada. Una contraseña compartida, una vez comprometida, permite a cualquiera acceder a su red. Y el MAC Authentication Bypass, o MAB, no es mejor. Los smartphones modernos utilizan direcciones MAC aleatorias por defecto, lo que rompe por completo MAB, y las direcciones MAC se pueden suplantar en cuestión de segundos.

La arquitectura de red moderna exige la autenticación 802.1X mediante EAP-TLS. Esto garantiza que cada dispositivo se verifique criptográficamente antes de que acceda a la red. Pero aquí está el reto: ¿cómo distribuir certificados de cliente únicos a miles de dispositivos no gestionados sin saturar su servicio de asistencia técnica? La respuesta es el Protocolo de Inscripción de Certificados Simple, o SCEP.

Comencemos con la arquitectura. SCEP es el estándar del sector para el registro de dispositivos corporativos, definido en el RFC 8894. Existe desde 1999, creado originalmente por VeriSign, y ha superado la prueba del tiempo porque resuelve un problema realmente complejo de forma elegante.

En un flujo de trabajo de SCEP, el dispositivo genera su propio par de claves privada y pública de forma local. Crea una Solicitud de Firma de Certificado, o CSR, y la envía a través de un Servicio de Inscripción de Dispositivos de Red, conocido como NDES, a su Autoridad de Certificación, o CA. La CA valida la solicitud y devuelve el certificado público firmado al dispositivo.

La ventaja de seguridad crítica aquí es que la clave privada nunca sale del dispositivo. Se genera localmente y se almacena en el enclave seguro del hardware del dispositivo. En un portátil Windows, ese es el Módulo de Plataforma Segura, o TPM. En un iPhone, es el Secure Enclave. La clave privada nunca se transmite a través de la red. Esto es lo que hace que SCEP sea muy superior a alternativas como PKCS para la autenticación de red, donde la CA genera el par de claves de forma centralizada y lo transmite al dispositivo.

Ahora, hablemos de BYOD. Aquí es donde se pone realmente interesante desde el punto de vista operativo. Quiere que el personal pueda utilizar sus dispositivos personales para acceder a las herramientas internas, pero no quiere obligarles a registrarse en su MDM corporativo. Eso es un problema de privacidad y se topa con una fuerte resistencia por parte del personal.

La solución es un portal de incorporación de autoservicio. Así es como funciona. El usuario conecta su dispositivo personal a un SSID de aprovisionamiento dedicado. Esta red es un jardín vallado, que restringe el acceso a todo excepto al portal de incorporación y a su proveedor de identidad. El usuario se autentica utilizando sus credenciales corporativas, normalmente mediante la integración de SAML con Microsoft Entra ID, Okta o Google Workspace. Una vez realizada la autenticación con éxito, el sistema genera un certificado de cliente único y específico para el dispositivo a través de SCEP. Se envía un perfil de configuración al dispositivo que contiene el certificado, el certificado de la CA raíz y los ajustes de red. A continuación, el dispositivo se conecta automáticamente al SSID corporativo seguro mediante EAP-TLS.

Es un proceso transparente para el usuario y seguro para la empresa. No necesitan saber nada sobre certificados ni 802.1X. Solo tienen que iniciar sesión una vez y ya están conectados.

Ahora, analicemos la implementación en detalle. La secuencia de despliegue es fundamental, y equivocarse en ella es la causa más común de fallo.

Paso uno: desplegar el Certificado Raíz de Confianza. Antes de que cualquier dispositivo pueda solicitar un certificado de cliente o confiar en su servidor RADIUS, debe confiar en la Autoridad de Certificación emisora. Exporte su certificado de CA raíz como un archivo .cer y despliéguelo en sus grupos de dispositivos de destino. Este paso no es negociable. Sin él, toda la cadena falla.

Paso dos: configurar el Perfil de Certificado SCEP. Esto indica a los dispositivos cómo obtener su certificado de cliente. Debe configurar el formato del nombre de sujeto. Para la autenticación dirigida por el usuario, el estándar es CN igual a UserPrincipalName. Para la autenticación de dispositivos, use CN igual al ID de dispositivo de Azure AD. Establezca el uso de clave para firma digital y cifrado de clave. En el uso mejorado de clave, especifique Autenticación de Cliente con el OID 1.3.6.1.5.5.7.3.2. Vincule este perfil al perfil de certificado raíz de confianza del paso uno. Y proporcione la URL externa de su servidor NDES.

Paso tres: desplegar el Perfil de WiFi 802.1X. Esto vincula los certificados al SSID de red. Introduzca el nombre de la red exactamente como lo transmiten sus puntos de acceso. Establezca el tipo de seguridad en WPA2-Enterprise o WPA3-Enterprise. Establezca el tipo de EAP en EAP-TLS. Seleccione el perfil de certificado SCEP como certificado de autenticación de cliente. Y especifique el certificado raíz de confianza para la validación del servidor.

Esta secuencia es lo más importante que debe recordar de toda esta sesión informativa. Confianza, luego certificado, luego WiFi. En ese orden, siempre.

Ahora permítame presentarle algunas de las mejores prácticas que le ahorrarán problemas significativos en producción.

En primer lugar, publique su servidor NDES a través de Azure AD Application Proxy. El servidor NDES debe ser accesible desde internet para permitir que los dispositivos remotos aprovisionen certificados antes de llegar a las instalaciones. Pero exponer un servidor interno directamente a internet es un riesgo de seguridad significativo. Application Proxy le proporciona acceso remoto seguro sin necesidad de abrir puertos de entrada en el cortafuegos.

En segundo lugar, implemente certificados de corta duración para dispositivos BYOD. En lugar de un certificado válido para tres años, emita certificados válidos para 90 días. Cuando el certificado caduque, el usuario deberá volver a autenticarse a través del portal de incorporación. Esto elimina de forma natural los dispositivos inactivos de la red. Un dispositivo que no se ha utilizado en 90 días simplemente se desconecta. No se requiere limpieza manual.

En tercer lugar, y esto es absolutamente crítico, configure su servidor RADIUS para aplicar una comprobación estricta de la Lista de Revocación de Certificados. Cuando un empleado deja la organización, es posible que el hecho de desactivar su cuenta de Active Directory no revoque inmediatamente su acceso WiFi si su certificado de cliente sigue siendo válido. Su servidor RADIUS debe comprobar la CRL antes de conceder el acceso. Asegúrese de que sus Puntos de Distribución de CRL estén altamente disponibles. Si el servidor RADIUS no puede acceder a la CRL, la autenticación fallará para todo el mundo. Eso supondría una interrupción generalizada del servicio.

Veamos ahora algunos fallos comunes y cómo evitarlos.

El problema más frecuente es que el perfil de WiFi no se aplica. El dispositivo recibe los certificados Trusted Root y SCEP, pero el perfil de WiFi aparece como Error en la consola de MDM. Nueve de cada diez veces, esto se debe a una discrepancia en la asignación de grupos. Si el perfil SCEP está asignado a un Grupo de usuarios, pero el perfil de WiFi está asignado a un Grupo de dispositivos, el MDM no puede resolver la dependencia. Audite sus asignaciones. Asegúrese de que los tres perfiles se dirijan exactamente al mismo grupo.

El segundo problema común son los errores NDES 403 Forbidden. Los dispositivos no consiguen recuperar el certificado SCEP y los registros de IIS de NDES muestran errores HTTP 403. Esto suele deberse a que la cuenta de servicio del conector no tiene los permisos necesarios en la plantilla de certificado, o a que un cortafuegos bloquea los parámetros de cadena de consulta específicos utilizados por SCEP. Verifique que la cuenta del conector tiene permisos de Lectura e Inscripción en la plantilla de la CA. Compruebe los registros de su cortafuegos para asegurarse de que no se bloquean las URL que contienen el parámetro operation equals GetCACaps.

Permítame presentarle dos escenarios del mundo real para ilustrar cómo funciona esto en la práctica.

Escenario uno: un hotel de 200 habitaciones con 50 empleados de limpieza que utilizan teléfonos inteligentes personales para acceder a la aplicación de horarios. El responsable de TI quiere evitar el registro completo en el MDM para respetar la privacidad del personal. La solución es un portal de autoservicio integrado con Microsoft Entra ID. El personal se conecta al SSID de aprovisionamiento, inicia sesión con sus credenciales de Microsoft Entra ID y descarga un perfil SCEP. El servidor SCEP emite un certificado de cliente de 30 días directamente al dispositivo. El dispositivo se conecta al SSID de WiFi del personal mediante EAP-TLS. El servidor RADIUS asigna estos dispositivos a una VLAN restringida que solo permite el acceso a la aplicación de horarios. Cuando un miembro del personal renuncia, su cuenta de Microsoft Entra ID se desactiva y el servidor RADIUS deniega instantáneamente el acceso a la red.

Escenario dos: una cadena minorista nacional con 500 tiendas que despliega WiFi seguro para tabletas de punto de venta corporativas. El arquitecto de red debe asegurarse de que, incluso si roban una tableta, las credenciales no se puedan extraer. La solución es Microsoft Intune desplegando certificados a través de SCEP. Intune envía el certificado raíz de confianza, seguido de un perfil SCEP que ordena a la tableta generar su propia clave privada en su enclave seguro de hardware. La tableta envía un CSR al servidor NDES, recibe el certificado de cliente y se conecta al SSID de TPV minorista mediante EAP-TLS. Debido a que la clave privada se genera localmente y nunca se transmite, las credenciales de una tableta robada no se pueden usar en ningún otro lugar. Esto cumple con los requisitos de conformidad de PCI-DSS.

Ahora, hablemos del caso de negocio. La transición al despliegue de certificados SCEP 802.1X ofrece retornos medibles en seguridad y operaciones.

El WiFi basado en contraseñas genera un volumen significativo de incidencias en el servicio de soporte. Caducidad de contraseñas, bloqueos, errores de escritura. La autenticación basada en certificados es invisible para el usuario. Los dispositivos se conectan automáticamente. Esto suele reducir el volumen de soporte relacionado con WiFi en un 70%. Se trata de una reducción sustancial de los costes operativos.

EAP-TLS elimina el riesgo de robo de credenciales y de ataques Man-in-the-Middle. Esto es fundamental para cumplir con PCI-DSS en entornos minoristas y con el GDPR en todos los sectores. El coste de una brecha de datos supera con creces el coste de desplegar una infraestructura PKI adecuada.

Y para las organizaciones que ya utilizan la plataforma de analítica y Guest WiFi de Purple, ampliar la incorporación segura a los dispositivos BYOD de los empleados proporciona una estrategia de gestión de red unificada. La capa de nube de Purple, que es independiente del hardware, se integra con Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti, UniFi, Cambium, Extreme Networks y Fortinet, por lo que no estará limitado a un solo proveedor de hardware. Purple opera en más de 80.000 recintos en vivo y ha procesado 440 millones de inicios de sesión en 2024, contando con las certificaciones ISO 27001, GDPR, CCPA y Cyber Essentials.

Permítame concluir con un resumen rápido de las decisiones clave que debe tomar.

¿Debería usar SCEP o PKCS? Use SCEP para la autenticación WiFi. La clave privada permanece en el dispositivo. Use PKCS solo para el cifrado de correo electrónico donde se requiera el depósito de claves.

¿Cuánto tiempo deben ser válidos los certificados? 90 días para BYOD. Uno a dos años para dispositivos gestionados por la empresa.

¿Debería utilizar la asignación por usuario o por dispositivo en su MDM? Utilice la asignación por dispositivo para los dispositivos corporativos que necesitan conectarse antes de que el usuario inicie sesión. Utilice la asignación por usuario para BYOD, donde el certificado debe estar vinculado al individuo.

¿Cómo se gestiona la fragmentación de Android? Utilice Passpoint, también conocido como Hotspot 2.0, siempre que sea posible. Ofrece una experiencia de conexión constante en los distintos fabricantes de Android.

Y por último, ¿qué es lo más importante que hay que configurar correctamente? La comprobación de CRL en su servidor RADIUS. Sin ella, un certificado revocado aún podría conceder acceso a la red.

Con esto finaliza el boletín de hoy. Si desea profundizar en alguno de estos temas, las guías técnicas de Purple sobre seguridad de WiFi empresarial y autenticación de certificados EAP-TLS están disponibles en el sitio web de Purple en purple.ai. Gracias por escucharnos.

Conclusiones clave

✓802.1X EAP-TLS es el estándar para redes WiFi empresariales seguras, lo que requiere certificados de cliente en todos los dispositivos. Las claves precompartidas y el MAC Authentication Bypass no son viables para entornos empresariales.
✓SCEP automatiza la implementación de certificados a escala. La clave privada se genera en el dispositivo y nunca se transmite, lo que la convierte en la opción correcta para la autenticación WiFi sobre PKCS.
✓La secuencia de implementación no es negociable: primero el certificado raíz de confianza, segundo el perfil de certificado SCEP y tercero el perfil de WiFi. Los tres perfiles deben dirigirse exactamente al mismo grupo en su MDM.
✓Para BYOD, un Captive Portal de autoservicio integrado con Microsoft Entra ID, Okta o Google Workspace permite al personal incorporar dispositivos personales sin necesidad de una inscripción completa en el MDM.
✓Emita certificados de 90 días para dispositivos BYOD para eliminar automáticamente los dispositivos obsoletos. Configure su servidor RADIUS para una comprobación estricta de CRL o OCSP para revocar el acceso de forma instantánea cuando el personal deje la empresa.
✓Publique su servidor NDES a través de Azure AD Application Proxy para permitir el aprovisionamiento remoto de certificados sin exponer la infraestructura interna a Internet.
✓La solución 802.1X basada en SCEP suele reducir el volumen de incidencias de soporte técnico relacionadas con el WiFi en un 70 % y cumple con los requisitos de conformidad de PCI-DSS y GDPR para entornos de retail, hostelería y sanidad.

Resumen Ejecutivo

Para los entornos empresariales que operan en los sectores de la hostelería, el comercio minorista y el sector público, confiar en las claves compartidas previamente (PSK) o en el bypass de autenticación MAC (MAB) para proporcionar acceso WiFi al personal y a dispositivos BYOD es un riesgo de seguridad. La arquitectura de red moderna exige una autenticación 802.1X utilizando EAP-TLS (protocolo de autenticación extensible-seguridad de la capa de transporte), lo que garantiza que cada dispositivo se verifique mediante criptografía antes de acceder a la red. El desafío operativo radica en distribuir certificados de cliente únicos a miles de dispositivos no gestionados sin saturar al servicio de soporte de TI con solicitudes de asistencia.

El protocolo simple de inscripción de certificados (SCEP), definido en la norma RFC 8894, resuelve este problema de distribución mediante la gestión automatizada del ciclo de vida de los certificados. Al aprovechar SCEP, los equipos de TI pueden implementar certificados raíz de confianza y certificados de cliente en los terminales, garantizando que la clave privada nunca salga del dispositivo. Esta guía proporciona el diseño arquitectónico definitivo y la estrategia de implementación paso a paso para el despliegue de certificados WiFi mediante SCEP. Cubrimos la secuencia de despliegue crítica necesaria para el éxito, escenarios del mundo real de la hostelería y el comercio minorista, y estrategias de mitigación de riesgos para mantener sus redes de WiFi de invitados y corporativas seguras y con un alto rendimiento.

Análisis Técnico Detallado: Arquitectura SCEP

SCEP es el estándar de la industria para el registro de dispositivos empresariales, creado por VeriSign y publicado como un borrador de Internet de la IETF en 1999. Automatiza la emisión de certificados X.509 dentro de un entorno de infraestructura de clave pública (PKI), eliminando la necesidad de gestionar certificados manualmente a escala.

En un flujo de trabajo SCEP, el dispositivo genera su propio par de claves pública y privada localmente. Crea una Solicitud de Firma de Certificado (CSR) y la envía a través de un servidor del Servicio de Inscripción de Dispositivos de Red (NDES) a su Autoridad de Certificación (CA). La CA valida la solicitud utilizando un secreto compartido y devuelve el certificado público firmado al dispositivo. La ventaja de seguridad crítica es que la clave privada nunca sale del dispositivo. Se genera localmente y se almacena en el enclave seguro de hardware del dispositivo: el Trusted Platform Module (TPM) en Windows, o el Secure Enclave en iOS. Esto convierte a SCEP en el método fuertemente recomendado para la autenticación 802.1X, a diferencia de PKCS (Public Key Cryptography Standards), donde la CA genera el par de claves de forma centralizada y lo transmite a través de la red.

Los cuatro pasos de la inscripción del certificado SCEP son los siguientes. En primer lugar, el dispositivo se conecta a la URL del endpoint SCEP alojada por el servidor NDES. En segundo lugar, el dispositivo presenta el secreto compartido SCEP (una contraseña estática o un desafío dinámico generado por la plataforma MDM) para validar la solicitud de inscripción. En tercer lugar, el dispositivo genera una CSR que contiene su clave pública e información de identificación. En cuarto lugar, la CA valida la CSR y emite un certificado X.509 firmado, que se devuelve al dispositivo.

SCEP frente a PKCS: Elegir el mecanismo adecuado

Al diseñar su estrategia de despliegue de certificados, la elección entre SCEP y PKCS afecta directamente a la seguridad. La siguiente tabla resume las diferencias clave.

Atributo	SCEP	PKCS
Generación de clave privada	En el dispositivo (enclave seguro)	En el servidor CA
Transmisión de clave privada	Nunca se transmite	Transmitida a través de la red
Requisitos de infraestructura	Requiere un servidor NDES	No requiere NDES
Más adecuado para	Autenticación WiFi y VPN	Cifrado de correo electrónico S/MIME
Enfoque de seguridad para 802.1X	Recomendado	No recomendado

Para el WiFi empresarial con SCEP, elija siempre SCEP. Mantener la clave privada en el dispositivo es la propiedad de seguridad fundamental que hace que la autenticación 802.1X basada en certificados sea superior a cualquier método de autenticación basado en credenciales.

El flujo de incorporación de autoservicio para BYOD

La base de una incorporación BYOD segura consiste en la transición de la autenticación heredada a EAP-TLS sin necesidad de una inscripción completa en la gestión de dispositivos móviles (MDM). Obligar al personal a inscribir sus smartphones personales en el MDM corporativo plantea preocupaciones legítimas sobre la privacidad y encuentra una fuerte resistencia. Un portal de incorporación de autoservicio resuelve este problema.

Los usuarios conectan su dispositivo personal a un SSID de aprovisionamiento dedicado, que actúa como un jardín vallado que restringe el acceso únicamente al portal de incorporación y al proveedor de identidad. Los usuarios se autentican mediante la integración de SAML o OAuth con Microsoft Entra ID, Okta o Google Workspace. Una vez autenticado correctamente, el sistema genera un certificado de cliente único y específico para el dispositivo a través de SCEP. Se envía al dispositivo un perfil de configuración (un archivo .mobileconfig para Apple o un perfil Android Passpoint). A continuación, el dispositivo se conecta automáticamente al SSID corporativo seguro mediante EAP-TLS. El usuario no necesita entender nada sobre certificados o 802.1X.

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

Configurar correctamente SCEP para 802.1X requiere cumplir estrictamente con una secuencia de despliegue específica. Se debe establecer la confianza antes de poder configurar la autenticación. Desviarse de esta secuencia es la causa más común de fallos en los despliegues.

Paso 1: Desplegar el certificado raíz de confianza. Antes de que cualquier dispositivo pueda solicitar un certificado de cliente o confiar en su servidor RADIUS, primero debe confiar en la autoridad de certificación (CA) emisora. Exporte su certificado CA raíz (y cualquier certificado CA intermedio) como un archivo .cer. Despliegue este perfil en sus grupos de dispositivos de destino a través de su plataforma MDM. Este paso es innegociable.

Paso 2: Configurar el perfil de certificado SCEP. Esto indica a los dispositivos cómo obtener su certificado de cliente. Configure el formato del nombre del sujeto: para la autenticación basada en el usuario, el estándar es CN={{UserPrincipalName}}; para la autenticación de dispositivos, use CN={{AAD_Device_ID}}. Establezca el uso de la clave en Digital signature y Key encipherment. En el uso extendido de la clave, especifique Client Authentication (OID: 1.3.6.1.5.5.7.3.2). Vincule este perfil al perfil de certificado raíz de confianza del Paso 1. Proporcione la URL externa de su servidor NDES.

Paso 3: Desplegar el perfil WiFi 802.1X. Envíe la configuración WiFi que vincula el certificado al SSID de red. Introduzca el nombre de la red exactamente igual a como lo emiten sus puntos de acceso (APs). Establezca el tipo de seguridad en WPA2-Enterprise o WPA3-Enterprise. Establezca el tipo de EAP en EAP-TLS. Seleccione el perfil de certificado SCEP como el certificado de autenticación de cliente. Especifique el certificado raíz de confianza para la validación del servidor, asegurando que los dispositivos solo se conecten a su servidor RADIUS legítimo.

Esta secuencia se aplica a todas las plataformas de hardware compatibles: Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme y Fortinet. La capa superpuesta en la nube de Purple es independiente del hardware y se integra con todas estas plataformas, lo que significa que su infraestructura de certificados no está vinculada a un único proveedor de hardware.

Buenas prácticas

Publicar NDES a través de Azure AD Application Proxy. El servidor NDES debe estar accesible desde internet para que los dispositivos remotos puedan aprovisionar certificados antes de llegar a la oficina. Exponer un servidor interno directamente a internet presenta un riesgo de seguridad significativo. Publicar a través de Azure AD Application Proxy proporciona un acceso remoto seguro sin abrir puertos de entrada en el cortafuegos, y permite aplicar políticas de acceso condicional al flujo de inscripción.

Emitir certificados de corta duración para BYOD. Debido a que los dispositivos BYOD no están gestionados, el riesgo de que un dispositivo comprometido permanezca en la red es mayor. Emita certificados válidos por 90 días en lugar de años. Cuando un certificado caduca, el usuario debe volver a autenticarse a través del portal de incorporación. Esto elimina de forma natural los dispositivos inactivos de la red sin intervención manual de TI.

Forzar una comprobación estricta de CRL en el servidor RADIUS. El despliegue de certificados es solo la mitad de la ecuación de seguridad. Si un empleado se marcha, desactivar su cuenta de Active Directory puede no revocar inmediatamente su acceso WiFi mientras su certificado de cliente siga siendo válido. Configure su servidor RADIUS para forzar una comprobación estricta de la lista de revocación de certificados (CRL). Asegúrese de que su punto de distribución de CRL (CDP) sea altamente disponible. Si el servidor RADIUS no puede acceder a la CRL, la autenticación fallará para todos los usuarios, provocando una interrupción del servicio a gran escala.

Segmentar BYOD en una VLAN dedicada. Los dispositivos BYOD no están gestionados. No tiene control sobre las actualizaciones de su sistema operativo, el estado del antivirus o las aplicaciones instaladas. Ubique los dispositivos BYOD en una VLAN dedicada que proporcione únicamente acceso a internet, restringido a las aplicaciones internas específicas requeridas para la función del empleado. Nunca coloque dispositivos BYOD en la misma VLAN que los servidores corporativos o los dispositivos gestionados.

Resolución de problemas y mitigación de riesgos

Error al aplicar el perfil WiFi. El dispositivo ha recibido el certificado raíz de confianza y el certificado SCEP, pero el perfil WiFi se muestra como "Error" en la consola MDM. Esto casi siempre se debe a un desajuste en la asignación de grupos. Si el perfil SCEP está asignado a un "grupo de usuarios" mientras que el perfil WiFi está asignado a un "grupo de dispositivos", el MDM no puede resolver la dependencia. Audite sus asignaciones y asegúrese de que el certificado raíz de confianza, el SCEP y los perfiles WiFi apunten exactamente al mismo grupo de Azure AD.

Errores 403 Forbidden de NDES. Los dispositivos no pueden recuperar los certificados SCEP y los registros de NDES IIS muestran errores HTTP 403. Lo más probable es que esto se deba a que la cuenta de servicio del conector carece de los permisos necesarios en la plantilla de certificado, o a que su cortafuegos está bloqueando los parámetros de cadena de consulta específicos que utiliza SCEP. 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 estén bloqueando las URL que contienen ?operation=GetCACaps.

Fragmentación de Android. Los dispositivos Apple iOS gestionan los perfiles .mobileconfig de forma muy consistente. Android, sin embargo, está muy fragmentado: los distintos fabricantes y versiones de SO gestionan los perfiles de WiFi y la instalación de certificados de forma diferente. Proporcione instrucciones claras y específicas para cada SO en el portal de incorporación. El uso de Passpoint (Hotspot 2.0) proporciona un flujo de conexión uniforme entre fabricantes, lo que mejora significativamente la experiencia en Android.

Retrasos en la revocación de certificados. Cuando un empleado se marcha, su acceso debe ser revocado inmediatamente. Deshabilitar su cuenta de IdP es el primer paso, pero el servidor RADIUS también debe validar el estado del certificado. Configure su servidor RADIUS para utilizar el Online Certificate Status Protocol (OCSP) además de la comprobación CRL. OCSP proporciona el estado de revocación en tiempo real en lugar de depender de una lista actualizada periódicamente.

ROI e impacto empresarial

La transición a la implantación de certificados SCEP 802.1X ofrece un rendimiento medible tanto en seguridad como en operaciones. El acceso WiFi basado en contraseñas genera un gran volumen de incidencias en el servicio de asistencia técnica debido a la caducidad de las contraseñas, los bloqueos y los errores de escritura. La autenticación basada en certificados es invisible para el usuario: los dispositivos se conectan automáticamente. Por lo general, esto reduce la carga de trabajo de soporte relacionada con el WiFi en un 70%, lo que permite al personal de TI centrarse en tareas estratégicas.

EAP-TLS elimina el riesgo de robo de credenciales y de ataques de intermediario (MitM). Esto es fundamental para el cumplimiento de PCI-DSS en entornos de comercio minorista y para el cumplimiento de GDPR en todos los sectores. En el sector de la hostelería , donde el personal maneja datos de pago e información personal de los huéspedes, el coste de una filtración de datos supera con creces el coste de implantar una infraestructura PKI bien diseñada. Los mismos factores de cumplimiento se aplican a los operadores de transporte y a los centros de atención sanitaria .

Para los centros que ya utilizan las plataformas de Guest WiFi y WiFi Analytics de Purple, ampliar la incorporación segura a los dispositivos BYOD del personal proporciona una estrategia de gestión de red unificada y sólida. Purple opera en más de 80.000 espacios físicos en todo el mundo, procesó 440 millones de inicios de sesión en 2024 (datos internos de Purple) y cuenta con las certificaciones ISO 27001, GDPR, CCPA y Cyber Essentials. Nuestros complementos de seguridad SecurePass y Shield se integran directamente con la arquitectura de autenticación basada en certificados descrita en esta guía.

Para obtener una perspectiva más amplia sobre la seguridad de las redes corporativas, consulte nuestra Seguridad WiFi corporativa: la guía completa de 2026 . Para conocer las consideraciones de cumplimiento del GDPR específicas para los administradores de red, consulte La guía del administrador de red sobre el cumplimiento del GDPR y la privacidad de los datos de los invitados .

Definiciones clave

SCEP (Simple Certificate Enrolment Protocol)

Un protocolo definido en RFC 8894 que automatiza la emisión de certificados digitales X.509 a dispositivos dentro de un entorno PKI. El dispositivo genera su propia clave privada localmente, la cual nunca sale del dispositivo.

Se utiliza para implementar certificados de autenticación WiFi en dispositivos corporativos y BYOD a gran escala sin intervención manual de TI. Es el estándar del sector para el aprovisionamiento de certificados 802.1X.

802.1X

Un estándar IEEE (IEEE Std 802.1X-2020) para el control de acceso a la red basado en puertos. Proporciona un mecanismo de autenticación a los dispositivos que desean conectarse a una LAN o WLAN antes de que se les conceda acceso a los recursos de la red.

La base del WiFi empresarial seguro, que sustituye a las vulnerables claves precompartidas. Requiere un servidor RADIUS, un suplicante en el dispositivo del cliente y un autenticador en el punto de acceso.

EAP-TLS (Protocolo de autenticación extensible - Seguridad de la capa de transporte)

Un marco de autenticación que requiere que tanto el servidor como el cliente presenten certificados digitales válidos. Proporciona autenticación mutua, garantizando que el dispositivo confíe en la red y la red confíe en el dispositivo.

El método más seguro para la autenticación 802.1X. Elimina el robo de credenciales y los ataques de tipo Man-in-the-Middle. El protocolo de autenticación de destino que el despliegue de certificados SCEP está diseñado para habilitar.

NDES (Servicio de inscripción de dispositivos de red)

Un rol de Windows Server de Microsoft que actúa como puente, permitiendo que los dispositivos sin credenciales de dominio obtengan certificados de una CA de Active Directory Certificate Services a través de SCEP.

Un componente de infraestructura necesario cuando se implementa SCEP con Microsoft Intune. Debe publicarse a través de Azure AD Application Proxy para permitir el aprovisionamiento remoto seguro de certificados.

BYOD (Trae tu propio dispositivo)

La práctica de permitir que los empleados utilicen sus propios smartphones, tabletas o portátiles personales para acceder a las redes y aplicaciones de la empresa.

Requiere una segmentación cuidadosa de la red y una incorporación segura para evitar que los dispositivos no gestionados comprometan la red corporativa. El registro completo en MDM a menudo no es viable para dispositivos personales debido a problemas de privacidad.

CRL (Lista de revocación de certificados)

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 expiración.

Debe ser verificada por el servidor RADIUS durante cada intento de autenticación para garantizar que los empleados despedidos o los dispositivos comprometidos no puedan acceder a la red. Los puntos de distribución de CRL deben ser de alta disponibilidad.

CSR (Solicitud de firma de certificado)

Un mensaje generado por un dispositivo y enviado a una Autoridad de Certificación para solicitar un certificado de identidad digital. Contiene la clave pública del dispositivo y la información de identidad.

Generada por el dispositivo durante el proceso SCEP. La clave privada utilizada para firmar la CSR permanece en el dispositivo y nunca se transmite.

RADIUS (Servicio de autenticación remota de usuario de marcación telefónica)

Un protocolo de red que proporciona una gestión centralizada de Autenticación, Autorización y Contabilidad (AAA) para los usuarios y dispositivos que se conectan a una red.

El servidor que valida el certificado del cliente durante la autenticación 802.1X y concede o deniega el acceso a la red. Debe configurarse para imponer una verificación estricta de CRL u OCSP.

PKCS (Estándares de criptografía de clave pública)

Un conjunto de estándares donde tanto la clave pública como la privada son generadas por la Autoridad de Certificación y luego se entregan de forma segura al endpoint.

Menos adecuado que SCEP para la autenticación WiFi porque la clave privada se transmite a través de la red. Es más adecuado para el cifrado de correo electrónico S/MIME, donde se requiere el depósito de claves.

OCSP (Protocolo de estado de certificado en línea)

Un protocolo que proporciona el estado de revocación de certificados en tiempo real, como alternativa a la CRL que se actualiza periódicamente.

Se prefiere a la CRL para entornos de alta seguridad porque proporciona el estado de revocación de forma instantánea en lugar de depender de una lista que podría tener horas de antigüedad.

Ejemplos prácticos

Un hotel de 200 habitaciones necesita proporcionar acceso seguro a WiFi a 50 empleados de limpieza que utilizan sus smartphones personales (BYOD) para acceder a la aplicación de gestión de turnos de limpieza. El director de TI desea evitar el registro completo en un MDM para respetar la privacidad del personal, pero necesita garantizar que el acceso se revoque de inmediato si un miembro del personal dimite.

El hotel implementa un portal de incorporación de autoservicio integrado con Microsoft Entra ID. El personal se conecta a un SSID de aprovisionamiento abierto, se autentica con sus credenciales de Microsoft Entra ID y descarga un perfil SCEP. El servidor SCEP emite un certificado de cliente de 30 días directamente al dispositivo, con la clave privada generada y almacenada localmente en el enclave seguro del smartphone. El dispositivo se conecta automáticamente al SSID 'Staff_WiFi' utilizando EAP-TLS. El servidor RADIUS asigna estos dispositivos a una VLAN restringida que solo permite el acceso a la aplicación de gestión de turnos y a internet. Cuando un miembro del personal dimite, se deshabilita su cuenta de Microsoft Entra ID. El servidor RADIUS, configurado para una comprobación estricta de CRL, deniega el acceso a la red en el siguiente intento de autenticación. La validez del certificado de 30 días garantiza que, incluso si se retrasara la comprobación de la CRL, el acceso caducaría en un plazo de un mes.

Comentario del examinador: Este enfoque equilibra la seguridad con la privacidad del personal. Al utilizar SCEP a través de un Captive Portal en lugar de un registro completo en un MDM, el hotel evita instalar un perfil de gestión en los dispositivos personales. La validez del certificado de 30 días y la comprobación estricta de CRL proporcionan un control de acceso por niveles. La segmentación de VLAN garantiza que incluso un dispositivo BYOD comprometido no pueda acceder a los servidores corporativos ni a los sistemas de pago.

Una cadena minorista nacional con 500 tiendas necesita implementar WiFi seguro para tabletas de punto de venta (POS) propiedad de la empresa que ejecutan Windows. El arquitecto de red debe asegurarse de que, incluso si se roba una tableta, las credenciales de red no se puedan extraer ni utilizar para acceder a la red corporativa desde otro dispositivo. El cumplimiento de PCI-DSS es obligatorio.

El arquitecto de red configura Microsoft Intune para implementar certificados a través de SCEP. Intune envía el certificado raíz de confianza al grupo 'POS Devices' (Dispositivos POS) y, a continuación, un perfil SCEP que indica a cada tableta que genere su propia clave privada en el TPM de Windows. La tableta envía una solicitud de firma de certificado (CSR) al servidor NDES, recibe el certificado de cliente y se conecta al SSID 'Retail_POS' utilizando WPA3-Enterprise y EAP-TLS. El servidor RADIUS autentica el certificado y ubica el dispositivo en la VLAN de POS aislada, que solo permite el tráfico hacia el procesador de pagos y el sistema de gestión de inventario. Los tres perfiles de Intune (raíz de confianza, SCEP y WiFi) se asignan al mismo grupo de dispositivos 'POS Devices' para evitar fallos de dependencia. NDES se publica a través de Azure AD Application Proxy para permitir la renovación de certificados sin necesidad de que la tableta esté en las instalaciones de la empresa.

Comentario del examinador: Esta es la arquitectura óptima para dispositivos corporativos en un entorno PCI-DSS. Dado que SCEP garantiza que la clave privada se genere localmente en el TPM y nunca se transmita, las credenciales de una tableta robada no se pueden extraer ni replicar desde otro dispositivo. El estándar WPA3-Enterprise proporciona confidencialidad directa perfecta (forward secrecy), lo que garantiza que el tráfico capturado no se pueda descifrar de forma retroactiva. El aislamiento de la VLAN limita el radio de impacto de cualquier dispositivo comprometido únicamente al segmento de red de POS.

Preguntas de práctica

Q1. Está implementando un perfil SCEP a través de Intune en una flota de portátiles Windows. Los dispositivos reciben correctamente el certificado raíz de confianza, pero el perfil de WiFi no se aplica y se muestra como "Error" en la consola de Intune. El perfil SCEP está asignado al grupo de Azure AD "All Users", mientras que el perfil de WiFi está asignado al grupo de dispositivos "Corporate Laptops". ¿Cuál es la causa del fallo y cómo lo solucionaría?

Sugerencia: Considere las dependencias entre los perfiles y cómo Intune resuelve la asignación de grupos cuando un perfil depende de otro perfil.

Ver respuesta modelo

El fallo se debe a una discrepancia en la asignación de grupos. Intune no puede resolver la dependencia entre el perfil SCEP y el perfil de WiFi porque se dirigen a tipos de grupos diferentes: uno se dirige a usuarios y el otro a dispositivos. Para solucionar esto, audite las asignaciones de los tres perfiles y asegúrese de que los perfiles de raíz de confianza, SCEP y WiFi se implementen exactamente en el mismo grupo de Azure AD. Elija la asignación por usuario o por dispositivo de forma coherente en todos los perfiles.

Q2. Un establecimiento comercial quiere proteger sus tabletas de punto de venta. El director de TI sugiere utilizar PKCS en lugar de SCEP porque simplifica la infraestructura al eliminar la necesidad de un servidor NDES. Como arquitecto de red, ¿por qué debería recomendar SCEP para la autenticación de WiFi 802.1X y en qué circunstancias sería PKCS la opción correcta?

Sugerencia: Piense en dónde se genera y almacena la clave privada en ambos protocolos, y considere las implicaciones de seguridad para la autenticación de red frente al cifrado de correo electrónico.

Ver respuesta modelo

Recomiende SCEP para la autenticación de WiFi 802.1X porque la clave privada se genera localmente en el dispositivo y se almacena en su enclave seguro de hardware. La clave privada nunca sale del dispositivo y nunca se transmite a través de la red. Si roban una tableta, las credenciales no se pueden extraer ni utilizar desde otro dispositivo. Con PKCS, la CA genera el par de claves de forma centralizada y lo transmite al dispositivo, lo que introduce un riesgo de transmisión inaceptable para la autenticación de red. PKCS es la opción correcta únicamente para el cifrado de correo electrónico S/MIME, donde se requiere el depósito de claves para permitir que los correos electrónicos cifrados se descifren si se pierde el dispositivo original.

Q3. Está diseñando un portal de incorporación BYOD para un hospital de 500 camas. El personal clínico utilizará sus smartphones personales para acceder a aplicaciones internas no críticas, como el cuadrante de turnos y la mensajería interna. Debe minimizar el riesgo de que los dispositivos inactivos permanezcan en la red después de que el personal se marche, sin requerir la intervención manual de TI para cada baja. ¿Qué configuración de certificado específica debería implementar?

Sugerencia: Considere el ciclo de vida del certificado y cómo puede obligar a los dispositivos a volver a autenticarse periódicamente sin necesidad de que el departamento de TI revoque manualmente cada certificado.

Ver respuesta modelo

Implemente certificados de corta duración con un periodo de validez de 30 a 90 días. Cuando el certificado caduca, el dispositivo BYOD se ve obligado a volver a autenticarse a través del Captive Portal utilizando las credenciales del IdP corporativo del miembro del personal. Si el empleado se ha marchado y su cuenta de IdP se ha desactivado, no podrá completar la nueva autenticación y no recibirá un nuevo certificado. Esto elimina de forma natural los dispositivos inactivos de la red sin necesidad de que TI revoque manualmente cada certificado. Combine esto con la comprobación OCSP en el servidor RADIUS para garantizar la revocación inmediata cuando se desactive una cuenta, proporcionando una defensa en profundidad entre los ciclos de caducidad de los certificados.

Q4. Su servidor NDES devuelve errores HTTP 403 Forbidden para todas las solicitudes de certificados SCEP. Se puede acceder al servidor NDES desde Internet a través de Azure AD Application Proxy. ¿Cuáles son las dos causas más probables de este error y cómo diagnosticaría cada una?

Sugerencia: Considere tanto los permisos en la plantilla de certificado como la ruta de red entre el dispositivo y el servidor NDES.

Ver respuesta modelo

Las dos causas más probables son: en primer lugar, que la cuenta de servicio del Intune Certificate Connector carezca de los permisos necesarios en la plantilla de certificado de la CA. Verifique que la cuenta de servicio tenga permisos de "Lectura" e "Inscripción" en la plantilla dentro de la consola de la CA. En segundo lugar, que el cortafuegos o el Proxy de aplicaciones esté bloqueando los parámetros específicos de la cadena de consulta que utiliza SCEP. Revise los registros del cortafuegos y del Proxy de aplicaciones en busca de solicitudes que contengan parámetros como "?operation=GetCACaps" o "?operation=PKIOperation". Estas son operaciones estándar de SCEP que deben permitirse. Si el Proxy de aplicaciones está eliminando las cadenas de consulta, ajuste la configuración de preautenticación para permitir el paso directo (pass-through) para la ruta URL de NDES.

Continúe leyendo esta serie

Cómo segregar de forma segura las redes WiFi de empleados y de invitados

Esta guía técnica autorizada proporciona a los responsables de TI estrategias prácticas para segregar de forma segura las redes WiFi de empleados, invitados e IoT utilizando VLANs y 802.1X. Detalla cómo proteger la infraestructura empresarial, mantener el cumplimiento de PCI-DSS y aprovechar los Captive Portals para capturar datos de origen.

La mejor filtración DNS: una guía completa para empresas

Esta guía de referencia técnica explica cómo la filtración DNS empresarial protege las redes públicas al bloquear dominios maliciosos en la capa de resolución - antes de que se establezca una conexión. Proporciona a los directores de TI, arquitectos de redes y equipos de operaciones de las instalaciones la arquitectura de despliegue, la configuración del firewall y el contexto de cumplimiento normativo que necesitan para proteger el WiFi de invitados en entornos de hostelería, comercio minorista y sector público. Purple Shield bloquea el malware, las botnets y el contenido inapropiado a nivel de DNS en más de 80.000 instalaciones activas.

Comprensión de Cisco SUDI: Identidad con Anclaje por Hardware en el Control de Acceso Seguro a la Red

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