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.

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

Escucha esta guía

Ver transcripción del podcast

INTRODUCTION AND CONTEXT - 0:00 to 1:00

Hola y bienvenidos a este informe técnico de Purple. Hoy analizaremos SCEP, el Protocolo de Inscripción de Certificados Simple, y cómo implementarlo para la inscripción automatizada de certificados WiFi. Si es arquitecto de redes, director de TI o administra la infraestructura de grandes recintos como cadenas minoristas, hospitales o estadios, este informe es para usted. Vamos directo al grano para analizar cómo implementar EAP-TLS a escala, por qué SCEP es la opción correcta para la identidad de los dispositivos y cómo puede implementarlo de manera práctica en su entorno. Comencemos.

TECHNICAL DEEP-DIVE - 1:00 to 6:00

Entonces, ¿cuál es exactamente el desafío que estamos resolviendo aquí? En el mundo de la seguridad WiFi empresarial, EAP-TLS representa el estándar de oro. A diferencia de los métodos heredados como PEAP o EAP-TTLS, que dependen de contraseñas de usuario, EAP-TLS exige una autenticación mutua basada en certificados. Esto significa que el dispositivo cliente debe verificar la identidad de la red a través de un certificado de servidor, y la red debe verificar la identidad del cliente a través de un certificado de cliente único.

Piense en la vulnerabilidad de las contraseñas. Se pueden compartir, pescar mediante phishing o robar. En un entorno empresarial en expansión, una contraseña comprometida puede otorgar a un actor malicioso acceso a toda su red interna. EAP-TLS elimina por completo este vector. La autenticación se basa en certificados X.509 emitidos por una Infraestructura de Clave Pública, o PKI.

Pero el desafío principal con EAP-TLS no es el protocolo en sí. Es la logística de llevar certificados de cliente únicos a miles de dispositivos, ya sean computadoras portátiles con Windows, iPads o tabletas de punto de venta. No se pueden instalar certificados manualmente en miles de dispositivos. Aquí es donde entran en juego las plataformas de gestión de dispositivos móviles (MDM) como Microsoft Intune o Jamf. Pero, ¿cómo se entregan esos certificados de forma segura?

Por lo general, tiene dos opciones: PKCS o SCEP. Permítame ser absolutamente claro en esto. Para la autenticación WiFi, lo que necesita es SCEP. He aquí por qué es importante. Con SCEP, el MDM indica al dispositivo endpoint que genere su propia clave privada localmente. Esa clave permanece bloqueada en el hardware seguro del dispositivo. Nunca viaja a través de la red. El dispositivo simplemente envía una Solicitud de Firma de Certificado a su Autoridad de Certificación a través de una puerta de enlace, que generalmente es un servidor NDES.

Contraste eso con PKCS, donde la Autoridad de Certificación genera la clave privada de forma centralizada y la envía al dispositivo a través de la red. Si bien PKCS tiene su lugar, por ejemplo, para el cifrado de correo electrónico donde se necesita el depósito de claves, transmitir claves privadas a través de la red es un riesgo que no necesita correr para la autenticación de red. Conserve las claves en el dispositivo. Utilice SCEP.

Ahora, hablemos de la implementación. Si se queda con una sola cosa de este informe, que sea esta regla general: Confianza antes de la autenticación. No puede simplemente enviar un perfil de WiFi y esperar que funcione. Hay una secuencia de implementación estricta de tres pasos que debe seguir.

Paso uno: Implementar el Certificado de Raíz de Confianza. Antes de que un dispositivo pueda solicitar un certificado de cliente o confiar en su servidor RADIUS, debe confiar en la Autoridad de Certificación emisora. Envíe este perfil primero.

Paso dos: Configurar y enviar el Perfil de Certificado SCEP. Esto le indica al dispositivo cómo comunicarse con la puerta de enlace SCEP, qué formato usar para el nombre de su sujeto y para qué sirve realmente el certificado. En este caso, Autenticación de Cliente. Debe vincular este perfil a la Raíz de Confianza que implementó en el paso uno.

Paso tres: Implementar el Perfil de WiFi 802.1X. Aquí es donde une todo. Especifica el SSID, selecciona WPA3-Enterprise, establece el tipo de EAP en EAP-TLS y lo vincula al certificado SCEP para la autenticación del cliente.

IMPLEMENTATION RECOMMENDATIONS AND PITFALLS - 6:00 to 8:00

Aquí hay un error importante que vemos todo el tiempo. Un cliente nos llama y nos dice: los certificados están en el dispositivo, pero el perfil de WiFi muestra un error en Intune. Casi siempre se trata de una discrepancia en la asignación de grupos. Si asigna el perfil SCEP a un grupo de Usuarios, pero asigna el perfil de WiFi a un grupo de Dispositivos, el MDM no puede resolver la dependencia. Haga coincidir sus objetivos exactamente en los tres perfiles.

Veamos un escenario del mundo real. Imagine un hotel de 200 habitaciones. Tienen 150 dispositivos iOS administrados para el personal de limpieza. Actualmente, utilizan una red con contraseña estándar y el personal sigue compartiendo la contraseña con los huéspedes. Es un verdadero dolor de cabeza operativo. Al migrar a WPA2-Enterprise con EAP-TLS a través de SCEP, el Director de TI elimina la contraseña por completo. Los dispositivos iOS se autentican de forma silenciosa en segundo plano utilizando sus certificados.

Pero, ¿qué sucede si un miembro del personal de limpieza pierde un dispositivo o deja la empresa? Deshabilitar su cuenta de Active Directory no es suficiente, porque el certificado en ese dispositivo sigue siendo criptográficamente válido. Esto nos lleva a un control de seguridad crítico: la verificación estricta de CRL. Debe configurar su servidor RADIUS para verificar la Lista de Revocación de Certificados. Si un dispositivo se pierde, se revoca el certificado en la CA. El servidor RADIUS detecta la revocación en la CRL y bloquea inmediatamente el acceso a la red. Sin una verificación estricta de CRL, su postura de seguridad está incompleta.

RAPID-FIRE Q&A - 8:00 to 9:00

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

Pregunta uno: ¿Se requiere EAP-TLS para WPA3 Enterprise? Aunque WPA3 Enterprise admite otros métodos, se recomienda encarecidamente EAP-TLS y es obligatorio si está implementando la suite de seguridad WPA3 Enterprise de 192 bits, a menudo llamada Suite B.

Pregunta dos: ¿Podemos usar certificados públicos para los clientes? No. Debe usar una CA interna privada para los certificados de cliente. Las CA públicas son para servidores web de acceso público. Su servidor RADIUS interno necesita confiar en su CA raíz interna específica para validar sus dispositivos corporativos.

Pregunta tres: ¿Cómo encaja esto con OpenRoaming? OpenRoaming se basa en Passpoint y 802.1X. Purple actúa como un proveedor de identidad gratuito para servicios como OpenRoaming bajo la licencia Connect, lo que facilita un roaming seguro y sin interrupciones en todos los recintos utilizando marcos de identidad y certificados subyacentes.

SUMMARY AND NEXT STEPS - 9:00 to 10:00

Para resumir, la transición a la implementación automatizada de certificados SCEP ofrece retornos reales y medibles. Verá una reducción del 70 al 80 por ciento en los tickets de soporte técnico relacionados con WiFi, porque los usuarios no se quedarán fuera de la red ni escribirán mal las contraseñas. Lo que es más importante, elimina el riesgo de extracción de credenciales, lo que garantiza que cumpla con los marcos de cumplimiento como PCI DSS y GDPR.

Automatizar la seguridad WiFi empresarial no se trata solo de bloquear las cosas. Se trata de hacer que el camino seguro sea el más fácil para sus usuarios. Sus próximos pasos: audite su implementación actual de 802.1X. Si todavía depende de contraseñas, diseñe su PKI y planifique la migración a EAP-TLS con SCEP. Verifique si su servidor RADIUS está aplicando una verificación estricta de CRL o OCSP. Y compruebe que sus tres perfiles de implementación se dirijan al mismo grupo.

Gracias por escuchar este informe técnico de Purple. Para obtener guías de implementación más detalladas y comprender cómo nuestras plataformas de análisis e identidad pueden integrarse con sus redes seguras, visite purple dot ai.

Puntos clave

✓SCEP (RFC 8894) automatiza la inscripción de certificados X.509 para dispositivos administrados. La clave privada se genera localmente en el dispositivo y nunca se transmite a través de la red; esta es la principal ventaja de seguridad sobre PKCS.
✓Para la autenticación WiFi 802.1X EAP-TLS, utilice siempre SCEP. Reserve PKCS para casos de uso que requieran el depósito de claves, como el cifrado de correo electrónico S/MIME.
✓La secuencia de implementación no es negociable: primero el Certificado de Raíz de Confianza, luego el Perfil de Certificado SCEP y después el Perfil de WiFi 802.1X. Los tres perfiles deben dirigirse exactamente al mismo grupo de Azure AD.
✓La verificación estricta de CRL o OCSP en el servidor RADIUS es obligatoria. Deshabilitar una cuenta de AD no revoca un certificado. Revoque en la CA y asegúrese de que el servidor RADIUS actúe en consecuencia.
✓EAP-TLS cumple con el Requisito 8.6 de PCI DSS 4.0 para la autenticación multifactor en la capa de red y es necesario para implementaciones de WPA3 Enterprise de 192 bits (Suite B).
✓Las organizaciones que migran de WiFi basado en contraseñas a EAP-TLS con SCEP suelen reportar una reducción del 70-80% en los tickets de soporte técnico relacionados con WiFi (datos internos de Purple, 2024).
✓Para propiedades distribuidas (grupos hoteleros, cadenas minoristas, sector público multisitio), las puertas de enlace SCEP alojadas en la nube y los servicios de PKI administrados eliminan el requisito de infraestructura NDES local sin comprometer la seguridad.

Resumen ejecutivo

Para los operadores de recintos que ofrecen Guest WiFi en hoteles, tiendas minoristas, estadios y centros de conferencias, depender de claves precompartidas o de portales cautivos básicos para el acceso a la red del personal representa un riesgo de seguridad. La arquitectura de red moderna exige una autenticación 802.1X mediante EAP-TLS (Extensible Authentication Protocol - Transport Layer Security), lo que garantiza que cada dispositivo se verifique criptográficamente antes de acceder a la red. El desafío radica en la distribución: ¿cómo implementar certificados de cliente únicos en miles de dispositivos Windows, iOS y Android sin saturar a su equipo de soporte técnico?

La respuesta es SCEP (Simple Certificate Enrollment Protocol). Formalizado por el IETF como RFC 8894 en 2020, SCEP automatiza la inscripción de certificados en flotas de dispositivos administrados. Cuando se integra con una plataforma MDM como Microsoft Intune o Jamf, SCEP ofrece un aprovisionamiento de certificados sin intervención: los dispositivos solicitan, reciben y renuevan sus propios certificados sin ninguna intervención de TI. La clave privada se genera localmente en el dispositivo y nunca se transmite a través de la red, lo que representa una ventaja de seguridad fundamental sobre la entrega basada en PKCS.

Esta guía detalla el flujo de trabajo completo de la implementación de SCEP: la arquitectura de PKI, la configuración de la puerta de enlace NDES, la secuencia obligatoria de implementación de tres pasos en el MDM y los controles operativos (particularmente la verificación de CRL y la asignación de grupos) que determinan si una implementación tiene éxito o se estanca. Dos escenarios del mundo real ilustran este enfoque en entornos de hotelería y comercio minorista. Purple opera en más de 80,000 recintos activos y cuenta con 350 millones de usuarios únicos; los patrones descritos aquí reflejan lo que funciona a esa escala.

Análisis técnico profundo

Qué hace realmente SCEP

SCEP se ubica entre su plataforma MDM y su Autoridad de Certificación (CA). Proporciona un mecanismo estandarizado basado en HTTP para que los dispositivos soliciten, reciban y renueven certificados X.509 sin requerir una credencial unida al dominio o la intervención manual de un administrador. El protocolo se desarrolló originalmente a principios de la década de 2000 y obtuvo una adopción generalizada en entornos MDM empresariales antes de que el IETF lo publicara formalmente como RFC 8894.

El flujo de inscripción de seis pasos funciona de la siguiente manera. Primero, el dispositivo administrado se conecta a la URL de la puerta de enlace SCEP preconfigurada en su perfil de MDM. Segundo, el dispositivo genera un par de claves privada y pública localmente y crea una Solicitud de Firma de Certificado (CSR). Tercero, la puerta de enlace SCEP valida la autorización del dispositivo mediante una contraseña de desafío o un OTP integrado en la política de MDM. Cuarto, la puerta de enlace reenvía la CSR validada a la CA. Quinto, la CA firma el certificado y lo devuelve a la puerta de enlace. Sexto, la puerta de enlace entrega el certificado firmado al dispositivo. Las renovaciones futuras siguen la misma ruta automatizada: el dispositivo se vuelve a inscribir antes del vencimiento sin ninguna acción por parte del usuario o del administrador.

SCEP frente a PKCS: la decisión clave

Microsoft Intune y la mayoría de las plataformas MDM admiten dos mecanismos de entrega de certificados: SCEP y PKCS. La distinción es arquitectónica, no estética.

Con SCEP, la clave privada se genera en el dispositivo y permanece allí. La CA nunca la ve. El TPM del dispositivo (en Windows) o el Secure Enclave (en iOS/macOS) protegen la clave a nivel de hardware. Con PKCS, la CA genera el par de claves de forma centralizada y lo transmite al dispositivo a través de la red. La CA conserva una copia, lo que permite el depósito de claves, algo útil para el cifrado de correo electrónico S/MIME pero que introduce un riesgo innecesario para la autenticación de red.

Para la autenticación WiFi 802.1X, utilice SCEP. La clave privada nunca sale del dispositivo. Esa es la regla.

Criterio	SCEP	PKCS
Clave privada generada en	Dispositivo	CA (centralizado)
Clave privada transmitida por la red	Nunca	Sí
Admite TPM / Secure Enclave	Sí	No
Recomendado para autenticación WiFi	Sí	No
Recomendado para cifrado de correo (S/MIME)	No	Sí
Depósito de claves posible	No	Sí

802.1X y EAP-TLS: el marco de autenticación

IEEE 802.1X es el estándar de control de acceso a la red basado en puertos que sustenta la seguridad WiFi empresarial. Define tres roles: el suplicante (el dispositivo cliente), el autenticador (el punto de acceso: Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme o Fortinet) y el servidor de autenticación (un servidor RADIUS como Microsoft NPS, FreeRADIUS o Cisco ISE).

EAP-TLS es el método EAP más seguro para 802.1X. Ambas partes presentan certificados: el servidor RADIUS presenta su certificado al cliente, y el cliente presenta su certificado provisto por SCEP al servidor RADIUS. Ninguna de las partes puede suplantar a la otra sin un certificado válido y no revocado de la jerarquía de CA de confianza. Este modelo de autenticación mutua elimina el robo de credenciales, los ataques de gemelo malvado (Evil Twin) y los riesgos de puntos de acceso no autorizados en una sola decisión arquitectónica.

EAP-TLS cumple con el Requisito 8.6 de PCI DSS 4.0 para la autenticación multifactor en la capa de red. Es necesario para implementaciones de WPA3 Enterprise de 192 bits (Suite B). Para cualquier red inalámbrica dentro del alcance del procesamiento de datos de titulares de tarjetas: comercio minorista punto de venta, recepción de hotel, taquilla de estadio: EAP-TLS es la opción correcta.

Para analizar más a fondo la arquitectura de WiFi seguro y cómo la autenticación basada en certificados se integra en una postura de seguridad más amplia, consulte nuestra guía esencial.

Guía de implementación

La secuencia de implementación no es negociable. Intune y Jamf resuelven las dependencias de los perfiles en orden: el perfil WiFi depende del perfil SCEP, el cual a su vez depende del perfil de Raíz de Confianza. Si los implementa fuera de orden, el perfil WiFi no se aplicará.

Paso 1: Diseñe su PKI

Antes de tocar una consola MDM, diseñe su jerarquía de certificados. Una PKI de dos niveles es el estándar: una CA raíz fuera de línea (offline) y una CA emisora en línea (online). La clave privada de la CA raíz es el ancla de confianza maestra para toda su infraestructura de certificados; manténgala aislada de la red (air-gapped). La CA emisora se encarga de la emisión diaria de certificados y publica la Lista de Revocación de Certificados (CRL) y el respondedor OCSP.

Para la mayoría de las implementaciones en establecimientos empresariales, Microsoft Active Directory Certificate Services (AD CS) ejecutado en Windows Server proporciona la CA emisora. Los servicios de PKI alojados en la nube de proveedores como SCEPman o SecureW2 eliminan por completo el requisito de infraestructura local y vale la pena evaluarlos para implementaciones distribuidas en grupos hoteleros, cadenas de retail o dependencias del sector público con múltiples sedes.

Paso 2: Implemente el servidor NDES (o la puerta de enlace SCEP en la nube)

NDES (Network Device Enrollment Service) es el rol de Microsoft Windows Server que actúa como la puerta de enlace SCEP entre su MDM y su CA. Requisitos clave de configuración:

Publique la URL de NDES de forma externa a través del Proxy de Aplicaciones de Azure AD (o un proxy inverso equivalente). Esto permite que los dispositivos remotos se registren antes de llegar al sitio, sin necesidad de abrir puertos de entrada en el firewall.
La cuenta de servicio de NDES requiere permisos de Lectura e Inscripción (Read and Enroll) en la plantilla de certificado de la CA.
Configure la plantilla de certificado con el Uso de clave (Key Usage) establecido en Firma digital (Digital Signature) y Cifrado de clave (Key Encipherment), y el Uso extendido de clave (Extended Key Usage) en Autenticación de cliente (Client Authentication) (OID: 1.3.6.1.5.5.7.3.2).
Establezca un período de validez de certificado adecuado. Un año es el estándar para certificados de cliente; dos años es aceptable para certificados de dispositivo en flotas estables.

Si prefiere evitar la infraestructura local de NDES, las puertas de enlace SCEP en la nube se integran directamente con Intune y su CA a través de una API, eliminando por completo la dependencia de IIS.

Paso 3: Implemente el perfil de Certificado de Raíz de Confianza

En su plataforma MDM, cree un perfil de Certificado de Confianza y cargue su certificado de CA raíz (y cualquier certificado de CA intermedia) como archivos .cer. Implemente este perfil en sus grupos de dispositivos de destino antes de cualquier otro perfil de certificado o WiFi. Sin este paso, los dispositivos no podrán validar el certificado del servidor RADIUS durante el handshake EAP-TLS, ni podrán confiar en la CA emisora al solicitar su propio certificado SCEP.

Regla general: Diríjase siempre al mismo grupo de Azure AD (ya sea de Usuarios o de Dispositivos) en los tres perfiles relacionados. Una discrepancia aquí es la causa más común de fallas en la implementación de perfiles WiFi.

Paso 4: Configure el perfil de Certificado SCEP

Cree un perfil de configuración de certificado SCEP en su MDM:

Formato del nombre del sujeto: Para la autenticación basada en el usuario, use CN={{UserPrincipalName}}. Para la autenticación de dispositivos (recomendada para dispositivos compartidos e IoT), use CN={{AAD_Device_ID}}.
Uso de clave: Firma digital, Cifrado de clave.
Uso extendido de clave: Autenticación de cliente (OID: 1.3.6.1.5.5.7.3.2).
URL del servidor SCEP: La URL de NDES publicada externamente.
Certificado raíz: Vincule al perfil de Raíz de Confianza del Paso 3.
Período de validez del certificado: Debe coincidir con la plantilla configurada en la CA.

Paso 5: Implemente el perfil WiFi 802.1X

Cree un perfil de configuración WiFi:

SSID: Ingrese el nombre de la red exactamente como lo transmiten sus puntos de acceso.
Tipo de seguridad: WPA2-Enterprise o WPA3-Enterprise.
Tipo de EAP: EAP-TLS.
Certificado de autenticación de cliente: Seleccione el perfil de certificado SCEP del Paso 4.
Validación del servidor: Especifique el certificado de Raíz de Confianza del Paso 3 e ingrese el nombre esperado del servidor RADIUS. Esto evita que los dispositivos se conecten a puntos de acceso no autorizados que presenten certificados fraudulentos.

Mejores prácticas

Exija una verificación estricta de CRL en su servidor RADIUS

La revocación de certificados es el control operativo que cierra la brecha entre deshabilitar una cuenta y bloquear el acceso a la red. Cuando un dispositivo se pierde, se roba o un empleado se va, deshabilite la cuenta de AD y revoque el certificado en la CA. Su servidor RADIUS debe estar configurado para verificar la CRL en cada intento de autenticación. Si la CRL no está disponible (porque el CDP [punto de distribución de CRL] es inaccesible), la mayoría de los servidores RADIUS fallan por defecto en modo abierto (fail open), lo que representa un riesgo de seguridad. Asegúrese de que sus CDP tengan alta disponibilidad y que su servidor RADIUS esté configurado para fallar en modo cerrado (fail closed) si no se puede obtener la CRL.

Para la revocación en tiempo real, configure OCSP (Online Certificate Status Protocol) además de la CRL. OCSP proporciona respuestas de estado por certificado sin requerir que el servidor RADIUS descargue y analice toda la CRL.

Utilice certificados de dispositivo para dispositivos compartidos e IoT

Para dispositivos compartidos (tabletas de limpieza de hoteles, terminales POS de retail, lectores de control de acceso de estadios), use certificados de dispositivo en lugar de certificados de usuario. Los certificados de dispositivo están vinculados a la identidad de la máquina, no a una cuenta de usuario. Esto significa que el dispositivo se autentica independientemente de qué usuario haya iniciado sesión, y la revocación está vinculada al registro del dispositivo en lugar de a la salida de un empleado.

Para implementaciones de retail , los certificados de dispositivo en el hardware POS también cumplen con el requisito de PCI DSS para la identidad del dispositivo a nivel de red, sin introducir la complejidad de las credenciales de usuario en el punto de venta.

Automatice la renovación de certificados

SCEP admite la renovación automática: el MDM le indica al dispositivo que vuelva a registrarse antes de que certificado expire. Configure su perfil SCEP para activar la renovación al 20% del periodo de validez restante del certificado. Para un certificado de un año, la renovación comienza aproximadamente 73 días antes del vencimiento. Este intervalo proporciona tiempo suficiente para resolver cualquier fallo de renovación antes de que el certificado expire y los dispositivos pierdan el acceso a la red.

Los certificados vencidos que causan fallos de autenticación masivos son el incidente operativo más común en las implementaciones de 802.1X. La renovación automatizada a través de SCEP elimina este riesgo por completo.

Segmentar redes por atributo de certificado

Los servidores RADIUS pueden leer los atributos de los certificados (Subject, SAN o OID personalizados) y utilizarlos para asignar dispositivos a VLAN de forma dinámica. Una tableta de limpieza con un certificado emitido desde la plantilla HousekeepingDevices se asigna a la VLAN de limpieza. Una terminal POS con un certificado de la plantilla RetailPOS se asigna a la VLAN dentro del alcance de PCI. Esta es una segmentación de red aplicada criptográficamente, mucho más confiable que los enfoques basados en SSID o en direcciones MAC.

Para los operadores de hospitalidad que ejecutan WiFi de invitados junto con WiFi de personal en la misma infraestructura física, la asignación de VLAN a través de atributos de certificado garantiza que los invitados y el personal estén siempre en segmentos de red separados, independientemente del SSID al que se conecte un dispositivo.

Resolución de problemas y mitigación de riesgos

El perfil de WiFi muestra 'Error' o 'No aplicable' en Intune

Causa raíz: Desajuste en la asignación de grupos. El perfil SCEP está asignado a un grupo diferente al del perfil de WiFi. Intune no puede resolver la dependencia del certificado.

Solución: Audite los tres perfiles (Trusted Root, SCEP, WiFi). Asegúrese de que todos estén asignados exactamente al mismo grupo de Azure AD. Si está realizando la implementación para Usuarios, los tres perfiles deben dirigirse a un grupo de Usuarios. Si la realiza para Dispositivos, los tres deben dirigirse a un grupo de Dispositivos.

NDES devuelve errores HTTP 403

Causa raíz: La cuenta de servicio de Intune Certificate Connector carece de permisos de lectura (Read) o inscripción (Enroll) en la plantilla de certificado de la CA, o el filtrado de URL del firewall está bloqueando las cadenas de consulta de SCEP.

Solución: Verifique que la cuenta del conector tenga permisos de lectura (Read) e inscripción (Enroll) en la plantilla dentro de la consola de la CA. Revise los registros del firewall en busca de solicitudes bloqueadas que contengan ?operation=GetCACaps o ?operation=PKIOperation. Estas cadenas de consulta deben pasar sin modificaciones.

Los dispositivos no renuevan los certificados antes de su vencimiento

Causa raíz: El intervalo de renovación de SCEP es demasiado corto o el servidor NDES no está accesible en el momento de la renovación.

Solución: Establezca el límite de renovación al 20% de la validez del certificado. Asegúrese de que la URL de NDES se publique a través de un proxy inverso de alta disponibilidad. Monitoree los registros de IIS de NDES para detectar fallos en las solicitudes de renovación y genere alertas de manera proactiva.

RADIUS rechaza certificados válidos

Causa raíz: El almacén de CA de confianza del servidor RADIUS no incluye el certificado de la CA emisora, o la CRL está desactualizada.

Solución: Importe la cadena de CA completa (Root CA + Issuing CA) en el almacén de confianza del servidor RADIUS. Verifique que la CRL se esté obteniendo correctamente y que la URL de CDP sea accesible desde el servidor RADIUS. Revise la marca de tiempo de la próxima actualización de la CRL; si ya pasó, la CA debe publicar una nueva CRL.

Para conocer consideraciones más amplias sobre el rendimiento de la red junto con la seguridad, consulte nuestra guía de gestión de ancho de banda .

ROI e impacto empresarial

El caso de negocio para el registro de certificados basado en SCEP es sencillo. El WiFi basado en contraseñas genera un volumen predecible de tickets de soporte: vencimientos de contraseñas, bloqueos de cuentas, personal que comparte credenciales con invitados y fricciones en la incorporación de nuevos empleados. La autenticación basada en certificados es invisible para el usuario final. Los dispositivos se conectan automáticamente. No hay contraseñas que venzan, se compartan o se olviden.

Las organizaciones que migran de WiFi basado en contraseñas a EAP-TLS con SCEP suelen reportar una reducción del 70-80% en los tickets de soporte relacionados con WiFi (datos internos de Purple, 2024, basados en implementaciones en propiedades de hospitalidad y comercio minorista). El ahorro en soporte técnico por sí solo suele justificar el costo de implementación dentro del primer año.

El impacto en el cumplimiento es igualmente concreto. EAP-TLS cumple con el Requisito 8.6 de PCI DSS 4.0 para la autenticación multifactor en la capa de red. Para entornos de atención médica , se alinea con los requisitos de salvaguardas técnicas de HIPAA para el acceso a redes inalámbricas. Para las organizaciones del sector público, respalda los requisitos de certificación Cyber Essentials Plus de la NCSC para el control de acceso a la red.

Para los operadores de transporte (concesiones ferroviarias, operadores aeroportuarios, redes de autobuses), la autenticación basada en certificados en los dispositivos del personal garantiza que las redes operativas que transportan datos críticos para la seguridad estén aisladas del WiFi de pasajeros y protegidas contra ataques basados en credenciales.

La plataforma WiFi Analytics de Purple se integra con redes protegidas por 802.1X para ofrecer información de datos de primera mano sin comprometer la postura de seguridad de la infraestructura subyacente. Los 29 mil millones de puntos de datos recopilados a través de la red de Purple demuestran que la seguridad y la analítica son objetivos complementarios, no opuestos.

Para la gestión de comentarios y experiencias junto con la implementación de su red segura, consulte nuestro manual de recopilación de comentarios en establecimientos .

Definiciones clave

SCEP (Simple Certificate Enrollment Protocol)

Un protocolo estandarizado por el IETF (RFC 8894) que automatiza la inscripción de certificados X.509 para dispositivos administrados. El dispositivo genera su propia clave privada localmente y envía únicamente una Solicitud de Firma de Certificado (CSR) a la CA a través de una puerta de enlace. La clave privada nunca sale del dispositivo.

Los equipos de TI se encuentran con SCEP al configurar plataformas MDM (Intune, Jamf) para implementar certificados de autenticación WiFi a escala. Es el mecanismo recomendado para implementaciones de 802.1X EAP-TLS porque la clave privada está protegida por hardware en el endpoint.

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

El método de autenticación 802.1X más seguro. Tanto el dispositivo cliente como el servidor RADIUS presentan certificados X.509. Ninguna de las partes puede autenticarse sin un certificado válido y no revocado de la jerarquía de CA de confianza.

EAP-TLS es el protocolo de autenticación de destino que habilita la implementación de certificados SCEP. Cumple con el Requisito 8.6 de PCI DSS 4.0 y es necesario para implementaciones de WPA3 Enterprise de 192 bits (Suite B).

PKCS (Public Key Cryptography Standards)

Un mecanismo de entrega de certificados en el que la CA genera el par de claves pública y privada de forma centralizada y las transmite al endpoint. La CA conserva una copia de la clave privada, lo que permite el depósito de claves.

Los equipos de TI eligen entre SCEP y PKCS al configurar perfiles de certificado en Intune. PKCS es adecuado para el cifrado de correo electrónico S/MIME donde se requiere el depósito de claves (key escrow). No se recomienda para la autenticación WiFi porque la clave privada se transmite a través de la red.

NDES (Network Device Enrollment Service)

Un rol de Microsoft Windows Server que actúa como puerta de enlace SCEP entre una plataforma MDM y una Autoridad de Certificación. Valida las solicitudes de inscripción de dispositivos y reenvía las CSR a la CA.

NDES es un componente de infraestructura requerido para implementaciones locales de SCEP con Microsoft Intune. Debe publicarse externamente a través de un proxy de aplicación para permitir que los dispositivos remotos se inscriban. Las puertas de enlace SCEP en la nube son una alternativa que elimina la dependencia de NDES local.

CRL (Certificate Revocation List)

Una lista publicada por la CA que contiene los números de serie de los certificados que han sido revocados antes de su fecha de vencimiento. Los servidores RADIUS verifiquen la CRL para garantizar que los dispositivos con certificados revocados no puedan autenticarse.

La verificación de CRL es el control operativo que aplica la revocación de certificados. Los equipos de TI deben configurar su servidor RADIUS para verificar la CRL en cada intento de autenticación y garantizar que el Punto de Distribución de CRL (CDP) sea altamente disponible.

802.1X

Un estándar IEEE para el control de acceso a redes basado en puertos. Define el marco de autenticación de tres partes (suplicante, autenticador, servidor de autenticación) utilizado en redes WiFi y cableadas empresariales.

802.1X es el marco dentro del cual operan EAP-TLS y SCEP. Los equipos de TI se encuentran con él al configurar SSIDs WPA2-Enterprise o WPA3-Enterprise y al establecer políticas de servidor RADIUS.

RADIUS (Remote Authentication Dial-In User Service)

Un protocolo de red que proporciona autenticación, autorización y contabilidad (AAA) centralizadas para el acceso a la red. En implementaciones de 802.1X, el servidor RADIUS valida los certificados de los clientes y aplica las políticas de asignación de VLAN.

El servidor RADIUS es el punto de decisión de autenticación en cada implementación de 802.1X. Las implementaciones comunes incluyen Microsoft NPS, FreeRADIUS y Cisco ISE. Debe configurarse con la cadena de CA de confianza y una verificación estricta de CRL o OCSP.

CSR (Certificate Signing Request)

Un bloque de texto codificado generado por un dispositivo que contiene la clave pública del dispositivo y la información de identidad. El dispositivo envía la CSR a la CA (a través de la puerta de enlace SCEP) para solicitar un certificado firmado. La clave privada correspondiente se genera y se conserva en el dispositivo.

La CSR es el elemento central en el flujo de inscripción de SCEP. Los equipos de TI configuran el formato de la CSR (nombre del sujeto, uso de la clave, EKU) en el perfil de certificado SCEP dentro de su plataforma MDM.

PKI (Public Key Infrastructure)

La combinación de hardware, software, políticas y procedimientos necesarios para crear, administrar, distribuir y revocar certificados digitales. Una PKI empresarial estándar consta de una CA raíz fuera de línea y una CA emisora en línea.

La PKI es el requisito previo para cualquier implementación de EAP-TLS. Los equipos de TI deben diseñar e implementar una jerarquía de CA de dos niveles antes de configurar SCEP. Los servicios de PKI alojados en la nube reducen la carga de infraestructura para implementaciones en propiedades distribuidas.

VLAN (Virtual Local Area Network)

Un segmento de red lógico que aísla el tráfico en la Capa 2. En implementaciones de 802.1X, los servidores RADIUS asignan dispositivos a VLANs de forma dinámica según los atributos del certificado, la identidad del usuario o la política.

La asignación de VLAN a través de RADIUS es el mecanismo que aplica la segmentación de red en el WiFi empresarial. Los equipos de TI lo utilizan para separar los dispositivos POS en VLANs dentro del alcance de PCI, los dispositivos de invitados en VLANs de solo internet y los dispositivos del personal en VLANs corporativas, todo desde una única infraestructura física.

Ejemplos resueltos

Una propiedad de Premier Inn con 200 habitaciones necesita implementar WiFi seguro para 150 dispositivos iOS del personal de limpieza. Actualmente, el personal comparte una contraseña WPA2-Personal con los huéspedes, lo que genera un riesgo operativo y de cumplimiento. El Director de TI necesita eliminar la contraseña compartida sin interrumpir las operaciones diarias.

El Director de TI implementa una implementación de SCEP impulsada por Jamf en tres fases. Fase uno: el certificado de la CA raíz se envía a los 150 dispositivos iOS a través de un perfil de Certificado de Confianza de Jamf, dirigido al grupo inteligente 'Housekeeping Devices'. Fase dos: se implementa un perfil de certificado SCEP, que dirige los dispositivos a un servidor NDES publicado mediante Azure AD App Proxy. El nombre del sujeto utiliza CN={{SERIALNUMBER}} para vincular el certificado al hardware del dispositivo. Fase tres: se envía un perfil de WiFi WPA2-Enterprise, especificando EAP-TLS y vinculándolo al certificado SCEP. Los dispositivos se autentican de forma silenciosa. El SSID con contraseña compartida se retira del servicio. El servidor RADIUS se configura con una verificación estricta de CRL y asignación de VLAN: los dispositivos de limpieza se asignan a la VLAN 20 (operaciones) y los dispositivos de huéspedes a la VLAN 10 (solo internet).

Comentario del examinador: Las decisiones de diseño clave aquí son los certificados de dispositivo (no de usuario) para el hardware compartido, y la asignación de VLAN a través de atributos de certificado en lugar de SSID. Esto significa que un dispositivo que de alguna manera se conecte al SSID de huéspedes seguirá cayendo en la VLAN correcta. La configuración de verificación de CRL no es negociable: cuando un miembro del personal de limpieza se va, el certificado del dispositivo se revoca en la CA y el servidor RADIUS bloquea el acceso dentro del intervalo de actualización de la CRL, que suele ser de 15 minutos con OCSP, o de hasta una hora con CRL.

Una cadena minorista con 500 ubicaciones necesita proteger el WiFi corporativo para tabletas POS con Windows que ejecutan software de procesamiento de pagos. El cumplimiento de PCI DSS 4.0 requiere autenticación multifactor en la capa de red. La configuración actual de WPA2-Personal no supera la evaluación del Requisito 8.6 de PCI DSS.

El arquitecto de red implementa EAP-TLS a través de Microsoft Intune y SCEP en las 500 ubicaciones. La implementación utiliza certificados de dispositivo con CN={{AAD_Device_ID}} como nombre de sujeto, vinculando cada certificado al registro del dispositivo en Intune. La secuencia de tres perfiles (Raíz de Confianza, SCEP, WiFi) se implementa en el grupo de Azure AD 'POS Devices', el mismo grupo para los tres perfiles. El servidor RADIUS asigna los dispositivos POS a una VLAN dedicada dentro del alcance de PCI (VLAN 100) según la plantilla de emisión del certificado. La CRL se publica en un endpoint altamente disponible alojado en una CDN con una ventana de validez de cuatro horas. Se habilita OCSP para la verificación de revocación en tiempo real. La implementación es validada por el QSA frente al Requisito 8.6 de PCI DSS 4.0.

Comentario del examinador: La alineación con PCI DSS se logra mediante la combinación de EAP-TLS (algo que se tiene: el certificado) y la identidad del dispositivo vinculada al registro de Intune (algo que se es: el dispositivo administrado inscrito). La asignación de VLAN a través de la plantilla de certificado garantiza que los dispositivos POS estén siempre en el segmento de red dentro del alcance de PCI, independientemente de su ubicación física en las 500 sedes. El endpoint de CRL alojado en CDN es una decisión crítica de confiabilidad: si la CRL no está accesible, la autenticación falla, lo que provoca una interrupción en todo el sitio. La alta disponibilidad para la CRL es tan importante como la alta disponibilidad para el propio servidor RADIUS.

Preguntas de práctica

Q1. Ha implementado perfiles de certificado de Raíz de Confianza y SCEP para el grupo de usuarios 'All Staff' en Intune. Luego, implementa el perfil de WiFi para el grupo de dispositivos 'Corporate Devices'. Los dispositivos reciben los certificados, pero el perfil de WiFi muestra 'Error' en la consola de Intune. ¿Cuál es la causa más probable y cómo lo soluciona?

Sugerencia: Considere cómo Intune resuelve las dependencias entre perfiles y qué sucede cuando los perfiles se dirigen a diferentes tipos de grupos.

Ver respuesta modelo

La causa principal es una discrepancia en la asignación de grupos. El perfil de WiFi depende del perfil SCEP, que a su vez depende del perfil de Raíz de Confianza. Intune no puede resolver estas dependencias cuando los perfiles se dirigen a diferentes tipos de grupos (Usuarios frente a Dispositivos). Solución: vuelva a implementar los tres perfiles en el mismo grupo. Si el perfil de WiFi se dirige a 'Corporate Devices' (un grupo de dispositivos), los perfiles SCEP y de Raíz de Confianza también deben dirigirse a 'Corporate Devices'. Alternativamente, mueva los tres a un grupo de usuarios si se requiere autenticación basada en el usuario.

Q2. Se informa del robo de un iPad del personal de limpieza de un hotel. Inmediatamente deshabilita la cuenta de Active Directory del empleado. A la mañana siguiente, el iPad robado sigue conectándose a la red WPA2-Enterprise del hotel. ¿Por qué sucede esto y qué dos acciones debe tomar para evitarlo?

Sugerencia: Piense en lo que realmente valida el servidor RADIUS durante la autenticación EAP-TLS y qué controles rigen la validez del certificado.

Ver respuesta modelo

Deshabilitar la cuenta de AD no revoca el certificado de cliente almacenado en el iPad. El servidor RADIUS valida el certificado, no el estado de la cuenta de AD, durante la autenticación EAP-TLS. Las dos acciones requeridas son: (1) revocar el certificado del dispositivo en la CA; esto agrega el número de serie del certificado a la CRL; (2) asegurarse de que el servidor RADIUS esté configurado con una verificación estricta de CRL para que obtenga la CRL actualizada y rechace el certificado revocado en el siguiente intento de autenticación. Para una revocación más rápida, configure OCSP en el servidor RADIUS para realizar comprobaciones del estado del certificado en tiempo real.

Q3. Una cadena minorista está implementando WiFi 802.1X en 500 ubicaciones de POS. El arquitecto de seguridad propone utilizar la entrega de certificados PKCS en lugar de SCEP para evitar la implementación de un servidor NDES. El QSA que revisa la evaluación de PCI DSS 4.0 plantea una preocupación. ¿Cuál es la preocupación y cuál es la recomendación correcta?

Sugerencia: Considere lo que dice PCI DSS sobre el manejo de claves privadas y qué hace PKCS con la clave privada durante la entrega.

Ver respuesta modelo

La preocupación del QSA es que PKCS transmite la clave privada a través de la red desde la CA hasta el dispositivo. El Requisito 3.5 de PCI DSS 4.0 exige que las claves privadas utilizadas para la autenticación estén protegidas contra la divulgación. Transmitir la clave privada a través de la red, incluso cifrada, introduce un riesgo que SCEP elimina por completo. La recomendación correcta es utilizar SCEP, donde la clave privada se genera en el dispositivo POS y nunca sale de él. Para evitar la infraestructura local de NDES, el arquitecto debería evaluar un servicio de puerta de enlace SCEP en la nube que se integre directamente con Intune y la CA a través de una API.

Q4. Está diseñando una red WiFi para un gran centro de conferencias que alberga más de 50 eventos al año. Los dispositivos del personal deben estar en una red segura 802.1X. Quiere asegurarse de que si el dispositivo de un contratista se ve comprometido, pueda aislarse de la red en un plazo de 15 minutos. ¿Qué mecanismo de revocación de certificados configura y por qué?

Sugerencia: Compare CRL y OCSP en términos de latencia de revocación y qué determina la rapidez con la que un servidor RADIUS actúa ante una revocación.

Ver respuesta modelo

Configure OCSP (Online Certificate Status Protocol) en el servidor RADIUS. La revocación basada en CRL tiene una latencia determinada por el período de validez de la CRL (normalmente de una a 24 horas), lo que significa que un certificado revocado aún podría autenticarse hasta que el servidor RADIUS obtenga la siguiente CRL. OCSP proporciona respuestas de estado en tiempo real por certificado: cuando se revoca un certificado en la CA, el respondedor OCSP devuelve inmediatamente un estado de 'revocado' en la siguiente consulta. Con OCSP configurado en el servidor RADIUS, el certificado de un contratista revocado se bloquea en el siguiente intento de autenticación, normalmente en cuestión de segundos. Asegúrese de que el respondedor OCSP sea altamente disponible; si no está accesible y el servidor RADIUS está configurado para fallar en modo cerrado (fail closed), todas las autenticaciones fallarán.

Continúe leyendo esta serie

Cómo configurar un Captive Portal en Starlink: Una guía para ubicaciones remotas y marítimas

Esta guía detalla cómo omitir el hardware nativo de Starlink e integrar un Captive Portal administrado en la nube utilizando equipos de enrutamiento empresariales. Aprenderá cómo superar la limitación de CGNAT, aplicar la segmentación de VLAN, administrar las restricciones de ancho de banda satelital y garantizar el cumplimiento normativo.

Hotel Guest WiFi Management: Integrating PMS, Portals, and Brand Standards

Esta guía técnica detalla cómo diseñar redes de WiFi para hoteles de nivel empresarial, enfocándose en la segmentación de VLAN, la integración de PMS para la gestión automatizada de sesiones y la optimización de Captive Portal para la captura de datos de conformidad con el GDPR.

Mejores prácticas de Captive Portal: Diseñando para una alta conversión y cumplimiento

Esta guía técnica ofrece a los gerentes de TI, arquitectos de red y directores de operaciones de establecimientos un plan completo para implementar captive portals que equilibren la seguridad de la red con una alta conversión de usuarios. Cubre toda la arquitectura, desde la segmentación de VLAN y la autenticación RADIUS hasta el diseño de consentimiento conforme a GDPR y la selección del método de autenticación. Basada en la experiencia operativa de Purple en más de 80,000 establecimientos y 440 millones de inicios de sesión en 2024, cada recomendación se fundamenta en datos reales de implementación.