How to Set Up Enterprise WiFi on Android Devices with EAP-TLS

Cómo configurar WiFi empresarial en dispositivos Android con EAP-TLS Una sesión técnica de Purple — Aproximadamente 10 minutos --- INTRODUCCIÓN Y CONTEXTO — aproximadamente 1 minuto Le damos la bienvenida a la serie de sesiones técnicas de Purple. Soy su anfitrión y hoy vamos a profundizar en los detalles de la implementación de la autenticación 802.1X EAP-TLS en dispositivos Android, ya sea que gestione un complejo hotelero, una cadena de tiendas, un estadio o un campus del sector público. Si es responsable de una red que necesita autenticar dispositivos Android corporativos o BYOD sin depender de contraseñas compartidas, este episodio es para usted. EAP-TLS es el estándar de oro para la seguridad de WiFi empresarial: utiliza autenticación mutua basada en certificados, lo que significa que no hay credenciales que puedan ser objeto de phishing, no hay contraseñas que rotar y ofrece una postura de cumplimiento que satisface PCI DSS, ISO 27001 y la mayoría de los marcos de seguridad del sector público. Al final de esta sesión, comprenderá exactamente cómo funciona EAP-TLS en Android, cuáles son sus opciones de implementación y los tres errores más comunes que provocan fallos en el despliegue. Comencemos. --- ANÁLISIS TÉCNICO DETALLADO — aproximadamente 5 minutos Comencemos con la arquitectura. 802.1X es el estándar IEEE que rige el control de acceso a la red basado en puertos. Cuando un dispositivo Android se conecta a una red WiFi empresarial (una configurada como WPA2-Enterprise o WPA3-Enterprise), el punto de acceso actúa como lo que se denomina un autenticador. No toma la decisión de autenticación por sí mismo; transmite la conversación entre el dispositivo y un servidor RADIUS, que es el servidor de autenticación real. EAP-TLS (Protocolo de autenticación extensible con seguridad de la capa de transporte) es el método de autenticación que se ejecuta dentro de ese marco 802.1X. Lo que lo diferencia de EAP-PEAP o EAP-TTLS, que utilizan nombre de usuario y contraseña dentro de un túnel TLS, es que EAP-TLS utiliza certificados X.509 en ambos lados. El servidor RADIUS presenta un certificado de servidor al dispositivo, y el dispositivo presenta un certificado de cliente de vuelta al servidor RADIUS. Ambas partes se validan mutuamente. Eso es autenticación mutua, y es lo que convierte a EAP-TLS en la opción más segura disponible. Ahora, específicamente en Android, hay algunas cosas que debe comprender. Android 11 y versiones posteriores introdujeron requisitos de validación de certificados más estrictos. Si está realizando la implementación en Android 11 o superior (que en este momento es la gran mayoría de su parque de dispositivos), el dispositivo se negará a conectarse a menos que el certificado del servidor RADIUS sea de confianza explícita. No puede confiar únicamente en el almacén de confianza del sistema; debe enviar el certificado de la CA raíz al dispositivo o configurar el perfil de WiFi para que haga referencia a él de forma explícita. Hablemos de la cadena de certificados. Necesita tres componentes listos antes de que un solo dispositivo Android pueda autenticarse a través de EAP-TLS. Primero, una Entidad de Certificación (CA), ya sea su PKI interna, Microsoft Active Directory Certificate Services o una PKI en la nube como SCEP a través de Intune. Segundo, un certificado de servidor emitido para su servidor RADIUS, firmado por esa CA. Tercero, un certificado de cliente único emitido para cada dispositivo o usuario, también firmado por la misma CA. El dispositivo presenta su certificado de cliente durante el protocolo de enlace TLS, y el servidor RADIUS lo valida contra la lista de revocación de certificados de la CA (CRL) o mediante OCSP (Protocolo de Estado de Certificados en Línea). Para Android, el certificado de cliente y la clave privada se empaquetan normalmente como un archivo PKCS12 (un archivo .P12 o .PFX) que contiene tanto el certificado como la clave privada cifrada. En un dispositivo configurado manualmente, el usuario importa este archivo a través de Ajustes, luego Seguridad y, por último, Instalar un certificado. En un dispositivo gestionado por MDM, el certificado se envía de forma silenciosa al almacén de claves gestionado del dispositivo, sin necesidad de interacción por parte del usuario. Ahora hablemos del perfil de WiFi en sí. Al configurar una conexión WiFi empresarial en Android, debe especificar: el SSID, el tipo de seguridad (WPA2-Enterprise o WPA3-Enterprise), el método EAP (que es TLS), el certificado de la CA para la validación del servidor, el certificado de cliente para la autenticación del dispositivo y la cadena de identidad, que suele ser el Nombre Común (CN) del dispositivo o el UPN del usuario. En Android 11 y versiones superiores, también debe especificar la coincidencia de sufijo de dominio o el asunto del certificado del servidor para evitar ataques de intermediario (man-in-the-middle). Para despliegues de MDM (y aquí es donde entra en juego la verdadera escalabilidad), todo esto se envía como un perfil de configuración estructurado. En Microsoft Intune, se crea un perfil de certificado SCEP que solicita e instala automáticamente un certificado de cliente único en cada dispositivo Android registrado. A continuación, se crea un perfil de configuración de WiFi que hace referencia a ese perfil de certificado. Cuando el dispositivo se conecta, recibe tanto el certificado como el perfil de WiFi, y se conecta a su red 802.1X de forma automática. Sin interacción del usuario, sin llamadas de soporte. Si utiliza Intune para esto, nuestra guía complementaria sobre cómo utilizar Microsoft Intune para enviar certificados WiFi a dispositivos detalla los pasos exactos de configuración; le recomiendo leerla junto con este informe. Para VMware Workspace ONE y Jamf Connect, el proceso es idéntico desde el punto de vista de la arquitectura: un perfil de certificado SCEP o PKCS, seguido de un perfil de WiFi que hace referencia a él. La interfaz de usuario específica varía, pero la cadena de certificados y los requisitos de configuración de RADIUS son los mismos. Un detalle que vale la pena destacar en lo que respecta a RADIUS: si utilizas FreeRADIUS, Microsoft NPS o Cisco ISE, asegúrate de que el certificado de tu servidor incluya los atributos correctos de Uso mejorado de clave (EKU); específicamente, Autenticación de servidor, OID 1.3.6.1.5.5.7.3.1. Android es muy estricto con esto. Un certificado que funciona perfectamente con clientes de Windows puede fallar en Android si el EKU falta o está mal configurado. --- RECOMENDACIONES DE IMPLEMENTACIÓN Y ERRORES COMUNES — aproximadamente 2 minutos Bien, hablemos de lo que suele fallar en la práctica, porque aquí es donde la mayoría de los despliegues encuentran problemas. El primer fallo y el más común es la confianza en el certificado. Android 11 y versiones superiores no se conectarán si no se puede validar la cadena de certificados del servidor RADIUS. La solución es sencilla: distribuye el certificado de tu CA raíz en el almacén de certificados de usuario del dispositivo a través de un MDM, y haz referencia a él de forma explícita en el campo de certificado de CA del perfil de WiFi. No lo dejes como "No validar"; eso es una brecha de seguridad y, de todos modos, fallará en algunas versiones de Android. El segundo error común es la caducidad de los certificados. Los certificados de cliente suelen tener un periodo de validez de uno a dos años. Si no dispones de una renovación automatizada a través de SCEP o NDES, te despertarás una mañana y descubrirás que la mitad de tus dispositivos han perdido el acceso a la WiFi simultáneamente. Integra la automatización de la renovación de certificados en el flujo de trabajo de tu MDM desde el primer día, no como una ocurrencia tardía. El tercer problema es la capacidad del servidor RADIUS. Los intercambios de señales (handshakes) de EAP-TLS son computacionalmente más costosos que los de PEAP debido al intercambio mutuo completo de certificados. En un estadio o centro de conferencias con miles de autenticaciones simultáneas, un servidor RADIUS infradimensionado se convertirá en un cuello de botella. Dimensiona tu infraestructura RADIUS para picos de autenticaciones concurrentes, no para la carga media. Por último, en lo que respecta a Android, ten en cuenta que los diferentes fabricantes (Samsung, Google, Xiaomi) tienen implementaciones ligeramente distintas de la API de configuración de WiFi. Prueba los perfiles distribuidos por MDM en dispositivos representativos de cada fabricante en tu parque antes de realizar un despliegue a gran escala. Los dispositivos Samsung, en particular, históricamente han requerido que el campo de identidad se configure de forma explícita, incluso cuando se puede deducir del certificado. --- PREGUNTAS Y RESPUESTAS RÁPIDAS — aproximadamente 1 minuto Algunas preguntas rápidas que me hacen con frecuencia. ¿Puedo usar EAP-TLS para dispositivos BYOD? Sí, pero requiere que el usuario instale un certificado de cliente en su dispositivo personal. Para BYOD a gran escala, evalúa si EAP-TTLS con PAP o PEAP-MSCHAPv2 es una solución de compromiso más práctica, reservando EAP-TLS para los dispositivos propiedad de la empresa. ¿Funciona EAP-TLS con WPA3-Enterprise? Sí, y de hecho WPA3-Enterprise con modo de 192 bits exige obligatoriamente EAP-TLS. Si vas a desplegar WPA3-Enterprise en entornos de alta seguridad, EAP-TLS es tu única opción compatible. ¿Cuál es la versión mínima de Android que debería tener como objetivo? Android 8 y versiones superiores son compatibles con EAP-TLS de forma nativa. Para Android 11 y versiones superiores, aplique la validación explícita del certificado de CA. Para Android 13 y versiones superiores, puede aprovechar las API de gestión de certificados mejoradas para un control más detallado. ¿Puede la plataforma de Purple integrarse con redes EAP-TLS? La plataforma de analítica y WiFi para invitados de Purple funciona en un SSID independiente de su red corporativa 802.1X. Sus dispositivos corporativos se autentican a través de EAP-TLS en el SSID seguro, mientras que los dispositivos de los invitados utilizan el Captive Portal de Purple en el SSID de invitados. Ambos coexisten en la misma infraestructura de puntos de acceso, con la separación de VLAN proporcionando el límite de seguridad. --- RESUMEN Y PRÓXIMOS PASOS — aproximadamente 1 minuto Para resumir: EAP-TLS en Android es el método de autenticación WiFi empresarial más seguro disponible y, con las herramientas de MDM modernas, es totalmente viable de implementar a escala. Los tres aspectos que debe asegurar son: una PKI correctamente configurada con renovación automática de certificados, la confianza explícita en el certificado de CA en Android 11 y versiones superiores, y una infraestructura RADIUS dimensionada para picos de carga. Si está realizando el despliegue en un espacio con tráfico mixto de corporativos e invitados, la plataforma de Purple le ofrece la capa de analítica e interacción en la red de invitados, mientras que su infraestructura EAP-TLS protege el lado corporativo. Ambos se complementan a la perfección. Como próximos pasos: revise nuestro diagrama de arquitectura en la guía completa, siga el tutorial de despliegue de Intune y realice un piloto en un subconjunto de dispositivos antes de implementarlo en todo su parque. Comience con un grupo controlado de cincuenta dispositivos, valide la entrega de certificados y la conectividad WiFi, y luego escale con total confianza. Gracias por escuchar el Informe Técnico de Purple. Encontrará la guía escrita completa, los diagramas y las referencias de configuración en purple.ai. Hasta la próxima.