Cómo configurar WiFi para empresas en dispositivos Android con EAP-TLS

Android se conecta a WiFi empresarial de EAP-TLS cuando se cumplen tres condiciones. El dispositivo cuenta con su propio certificado de cliente. Confía en la CA raíz que firmó el certificado de su servidor RADIUS. Su perfil de WPA2 o WPA3-Enterprise utiliza el método EAP TLS, con un Dominio que coincide con ese certificado de servidor. Distribuya estas tres condiciones desde su MDM para configurar flotas completas sin necesidad de tocar ningún dispositivo.

¿Qué hace realmente EAP-TLS en un dispositivo Android?

IEEE 802.1X es el estándar para el control de acceso a redes basado en puertos. En WiFi, el punto de acceso no transmite tráfico de un dispositivo hasta que un servidor de autenticación lo aprueba. Ese servidor es un servidor RADIUS, el servicio que acepta o rechaza cada solicitud de conexión. El dispositivo Android es el suplicante, el punto de acceso es el autenticador y RADIUS es el servidor de autenticación.

EAP-TLS (Extensible Authentication Protocol con Transport Layer Security, definido en el RFC 5216) es la forma en que ambas partes demuestran su identidad. Utiliza certificados X.509, no contraseñas. La comprobación se realiza en ambas direcciones:

1. El servidor RADIUS presenta su certificado. Android comprueba que este encadena con una autoridad de certificación (CA) raíz de confianza. También verifica que el nombre del certificado coincida con el Dominio del perfil de WiFi.
2. El dispositivo Android presenta su propio certificado de cliente. RADIUS comprueba que su CA lo haya emitido, que esté vigente y que no haya sido revocado.

Al no existir ninguna contraseña, no hay nada que pueda ser objeto de phishing, reutilización o restablecimiento. PEAP (Protected EAP) con MSCHAPv2 funciona de forma diferente: envía un nombre de usuario y una contraseña dentro de un túnel TLS. Una contraseña de PEAP robada funciona en cualquier dispositivo. La clave privada de un certificado de cliente permanece en el dispositivo al que le fue emitido.

Comportamientos de Android que suelen tomar por sorpresa a los equipos

Cuatro comportamientos de Android condicionan cualquier despliegue:

• La validación del servidor es obligatoria. A partir de Android 11, Google eliminó la opción de omitir la validación del certificado del servidor en redes empresariales. Todos los perfiles necesitan un certificado de CA y un Dominio, de lo contrario, el dispositivo no se conectará.
• El uso extendido de claves es fundamental. El certificado del servidor RADIUS requiere el uso extendido de claves (EKU) de Autenticación de servidor, OID 1.3.6.1.5.5.7.3.1. Emita certificados de cliente con Autenticación de cliente, OID 1.3.6.1.5.5.7.3.2.
• Las instalaciones manuales requieren PKCS#12. Android requiere que el certificado de cliente y la clave privada estén empaquetados en un único archivo .p12 o .pfx.
• Las direcciones MAC se aleatorizan. Desde Android 10, los dispositivos utilizan por defecto una dirección MAC aleatoria para cada red. Nunca base la identidad o las políticas de acceso en direcciones MAC.

Comparación entre EAP-TLS y sus alternativas

¿Qué necesita antes de configurar Android para EAP-TLS?

Prepare estos seis elementos antes de tocar cualquier dispositivo. La mayoría de las implementaciones fallidas se deben a uno de ellos.

• Una infraestructura de clave pública (PKI). Necesita una CA para emitir certificados de cliente. Si ya ejecuta una CA interna, como Microsoft Active Directory Certificate Services, puede emitir tanto certificados de servidor como de cliente.
• Un certificado de servidor RADIUS creado para Android. Debe incluir un nombre alternativo del sujeto (SAN) que contenga un nombre DNS. También requiere la EKU de autenticación de servidor y una cadena de confianza hasta la raíz que vaya a distribuir. Configure RADIUS para enviar la cadena completa, incluidos los certificados intermedios.
• RADIUS configurado para EAP-TLS. Debe confiar en la CA que emite los certificados de cliente. Asimismo, debe comprobar la revocación mediante una lista de revocación de certificados (CRL) o el protocolo OCSP (Online Certificate Status Protocol).
• Un SSID Enterprise en sus puntos de acceso. Establezca WPA2-Enterprise o WPA3-Enterprise y apúntelo a RADIUS. Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme y Fortinet son compatibles con 802.1X.
• Un MDM inscrito a través de Android Enterprise. La gestión de dispositivos móviles (MDM) es la única forma práctica de emitir y renovar certificados más allá de una fase piloto. Conéctelo a su CA con SCEP, el protocolo de solicitud de certificados definido en la norma RFC 8894.
• Un plan de asignación de nombres y VLAN. Decida qué identidad incluirá cada certificado de cliente, como la ID de un dispositivo o el nombre de inicio de sesión del personal. A continuación, decida a qué VLAN (LAN virtual, un segmento de red separado lógicamente) se unirá cada grupo de dispositivos.

¿Cómo se configura EAP-TLS en Android?

Dispone de dos vías. La configuración manual valida su diseño en unos pocos dispositivos. Los perfiles distribuidos por MDM lo extienden a toda la infraestructura.

Opción 1: configuración manual para pruebas piloto y grupos pequeños

Las rutas de menú varían entre versiones de Android y fabricantes, por lo que se recomienda seguir las etiquetas de los campos en lugar de una ruta fija.

1. Entregue los archivos de forma segura. El dispositivo necesita el certificado de la CA raíz y un archivo .p12 que contenga su certificado de cliente y su clave privada. Envíe la contraseña del archivo .p12 a través de un canal independiente.
2. Instale los certificados. Abra el instalador de certificados en los ajustes de seguridad del dispositivo. Instale la CA raíz como certificado de WiFi; a continuación, instale el archivo .p12 e introduzca su contraseña.
3. Añada la red. En los ajustes de WiFi, añada una red manualmente e introduzca el SSID exactamente.
4. Elija la seguridad Enterprise. Seleccione la opción WPA2-Enterprise o WPA3-Enterprise. Las etiquetas varían según la versión.
5. Establezca el método EAP en TLS.
6. Configure el certificado CA. Seleccione la raíz que instaló. Si una CA pública emitió su certificado RADIUS, elija en su lugar la opción de certificados del sistema.
7. Establezca el estado del certificado en línea. "Solicitar estado del certificado" pide a RADIUS el estado OCSP de su propio certificado.
8. Establezca el dominio. Introduzca el nombre DNS del SAN del certificado RADIUS. Este es el campo en el que la mayoría de los equipos se equivocan.
9. Seleccione el certificado de cliente. Elija el que se instaló desde el archivo .p12.
10. Establezca la identidad. Utilice el nombre del certificado de cliente, como el ID del dispositivo, nunca una dirección MAC.

La configuración manual conlleva un coste oculto. Cada certificado caduca, y luego cada dispositivo requiere nuevamente el mismo trabajo manual.

Opción 2: Perfiles distribuidos por MDM mediante Android Enterprise

Android Enterprise es el marco de trabajo de Google para gestionar dispositivos Android. Tres de sus modos son relevantes aquí:

• Totalmente gestionado se adapta a teléfonos y tabletas propiedad de la empresa.
• Perfil de trabajo aisla las aplicaciones y certificados corporativos en dispositivos personales.
• Dedicado se adapta a dispositivos portátiles de un solo uso, quioscos y terminales TPV.

El orden de creación es el mismo en Microsoft Intune, Workspace ONE y la mayoría de las demás plataformas MDM:

1. Conecte el MDM a su CA. Instale el conector SCEP para que el MDM pueda gestionar las solicitudes de certificados.
2. Distribuya un perfil de certificado de confianza. Entregará su CA raíz, y cualquier intermedia, a cada dispositivo.
3. Distribuya un perfil de certificado SCEP. El dispositivo genera su propia clave privada y solicita un certificado de cliente. Establezca el asunto o SAN a partir de una variable de dispositivo. Configure también el EKU de autenticación de cliente, el periodo de validez y el umbral de renovación.
4. Distribuya el perfil de WiFi. Configure el SSID, la seguridad Enterprise y el tipo EAP TLS. Seleccione el perfil SCEP como el certificado de cliente. Para la confianza del servidor, seleccione el perfil de CA raíz e introduzca el nombre del servidor RADIUS de su SAN.
5. Asigne primero a un grupo piloto. Lea los registros de RADIUS durante varios días antes de ampliar la asignación.

Con SCEP, la clave privada nunca sale del dispositivo. El MDM renueva los certificados antes de que caduquen, por lo que los dispositivos permanecen conectados sin generar una incidencia. Para ver los pasos pantalla por pantalla, siga la documentación propia del proveedor de su MDM.

¿Qué método se adapta a su parque de dispositivos?

¿Cómo es un despliegue de EAP-TLS en Android en la práctica?

Escenario práctico: un hotel de 200 habitaciones que retira una contraseña compartida de personal

Situación. Los equipos de limpieza, mantenimiento y recepción compartían 60 terminales Android. Todos se conectaban a una única red WPA2-Personal cuya contraseña no se había cambiado desde la apertura. El personal antiguo aún la conocía. Cambiarla implicaba reconfigurar 60 dispositivos a mano.

Qué se hizo. El departamento de TI inscribió los terminales como dispositivos Android Enterprise totalmente gestionados. El MDM distribuyó la CA raíz, un certificado de cliente SCEP válido durante 12 meses y un perfil de WiFi EAP-TLS. El servidor RADIUS asignó cada terminal aceptado a la VLAN de operaciones. Los huéspedes permanecieron en una red independiente de Guest WiFi con su propio Captive Portal, la página de inicio de sesión que se muestra antes de acceder a internet.

Resultado. Se retiró la contraseña compartida en los 60 dispositivos. La pérdida de un terminal ahora solo requiere la revocación de un certificado; los otros 59 dispositivos no se ven afectados. El personal no tiene ninguna contraseña de WiFi que olvidar, por lo que el restablecimiento de contraseñas de WiFi desaparece por completo. Más información sobre el sector en Hotels.

Escenario práctico: una cadena minorista de 150 tiendas dentro del alcance de PCI-DSS

Situación. Cada tienda utilizaba cuatro terminales de inventario y dos tabletas TPV con Android: 900 dispositivos en total. La WiFi de la tienda transportaba tráfico de pagos, lo que la situaba dentro del alcance de PCI-DSS. El requisito 4.2.1.2 de PCI-DSS v4.0 exige una criptografía sólida para la autenticación y transmisión inalámbricas. Una clave compartida rotada tienda por tienda era difícil de justificar documentalmente.

Qué se hizo. El departamento de TI inscribió cada dispositivo como un dispositivo dedicado de Android Enterprise. El perfil SCEP escribió la función de cada dispositivo en su certificado. RADIUS hizo coincidir ese campo y devolvió una VLAN utilizando los atributos de túnel de la norma RFC 3580. Las tabletas TPV se unieron a la VLAN de pagos; los terminales de mano se unieron a la VLAN de inventario. Los compradores utilizaron un SSID de Guest WiFi independiente, con WiFi Analytics recopilando datos únicamente en esa red.

Resultado. Los 900 dispositivos se inscribieron sin que ningún empleado de la tienda tuviera que escribir una credencial. La rotación de claves en las 150 tiendas llegó a su fin. Cada conexión aparece ahora en los registros de RADIUS asociada al certificado de un dispositivo identificado, lo que ofrece al auditor pruebas individuales por dispositivo. Más información sobre el sector en Retail.

¿Cómo comprobar que Android se está autenticando con EAP-TLS?

Un icono de conexión solo demuestra que el dispositivo se ha unido a algo. Compruebe tres capas y, a continuación, demuestre que los controles fallan en modo seguro (fail-closed).

• En el dispositivo. Los detalles de la red muestran el SSID conectado y una dirección IP procedente de la VLAN esperada.
• En el servidor RADIUS. El registro muestra un Access-Accept, el tipo de EAP TLS y el asunto del certificado de cliente presentado.
• En el controlador o panel de WiFi. El registro del cliente muestra 802.1X con WPA2 o WPA3-Enterprise, además de la VLAN asignada por RADIUS.

A continuación, ejecute cuatro pruebas negativas en un dispositivo piloto:

1. Revoque su certificado, publique la CRL y vuelva a conectarlo. Debería recibir un Access-Reject.
2. Cambie el dominio del perfil a un nombre incorrecto. Android debería rechazar el servidor.
3. Instale un certificado de cliente de una CA diferente. Verifique que recibe un Access-Reject.
4. Emita un certificado con una duración corta. Confirme que el MDM lo renueva sin que el dispositivo pierda la conexión.

Si los cuatro escenarios responden según lo previsto, su diseño es sólido.

¿Qué suele fallar con EAP-TLS en Android y cómo se soluciona?

La mayoría de los fallos proceden de la cadena de certificados o del perfil, no de la radio.

¿Cómo encaja Purple junto a EAP-TLS?

EAP-TLS es el control adecuado para los dispositivos propios y gestionados. Su espacio también acoge a personas cuyos dispositivos nunca gestionará.

• WiFi de invitados en su propio SSID. WiFi de invitados ofrece a visitantes, compradores y pasajeros un Captive Portal personalizado con consentimiento explícito. Esto recopila datos de primera fuente que cumplen con el GDPR. WiFi Analytics genera informes sobre esa red, manteniéndola aislada del tráfico EAP-TLS.
• WiFi de empleados para dispositivos sin MDM. Las redes basadas en la identidad de Purple, incluidas SecurePass e iPSK, asignan a cada persona su propia credencial. El acceso se vincula a Microsoft Entra ID, Okta o Google Workspace, por lo que las altas, modificaciones y bajas de usuarios se gestionan directamente desde su directorio.
• El hardware del que ya dispone. Purple es una capa cloud independiente del hardware que funciona sobre Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme Networks y Fortinet. No se requiere sustitución de infraestructura.

Esta división funciona en múltiples sectores. En la Sanidad, los dispositivos clínicos Android utilizan EAP-TLS mientras que los pacientes y visitantes usan la WiFi de invitados. En los Trenes, las tabletas de la tripulación utilizan EAP-TLS y los pasajeros usan la WiFi de invitados. Purple opera en más de 80 000 ubicaciones activas en más de 90 países (datos de Purple) y cuenta con las certificaciones ISO 27001 y Cyber Essentials.

¿Cuánto cuesta implementar EAP-TLS en Android y qué beneficios se obtienen?

Lo que se paga

• PKI. Una CA interna existente apenas genera costes adicionales. Si no dispone de una, deberá crear una CA o suscribirse a una PKI en la nube.
• Licencias de MDM. Si su flota de dispositivos Android ya está inscrita, este coste ya está cubierto.
• RADIUS. Necesita compatibilidad con EAP-TLS, comprobación de revocación y un certificado de servidor correctamente creado.
• Tiempo de ingeniería. Reserve presupuesto para el piloto, la creación del perfil y un despliegue gradual.

Lo que obtiene a cambio

• Una sola revocación en lugar de una rotación en toda la flota. En el caso de un hotel, la pérdida de un terminal afecta a un solo dispositivo, no a 60.
• Sin restablecimientos de contraseñas de WiFi. Los certificados sustituyen a las contraseñas, por lo que esa categoría de incidencias desaparece.
• Resistencia a la captura de credenciales. Un punto de acceso falso no consigue nada. Android rechaza su certificado y no hay ninguna contraseña que capturar.
• Pruebas de cumplimiento normativo. Los registros de RADIUS por dispositivo respaldan el requisito 4.2.1.2 de PCI DSS, el artículo 32 de GDPR y el control de acceso de ISO 27001.
• Una vía hacia WPA3. El modo de 192 bits de WPA3-Enterprise, compatible a partir de Android 10, está diseñado en torno a EAP-TLS. El trabajo realizado con los certificados se aprovecha de cara al futuro.

La regla de decisión es sencilla. Si gestiona más de un puñado de dispositivos Android a través de un MDM, configure EAP-TLS como opción predeterminada. Coloque los dispositivos no gestionados del personal en redes basadas en la identidad y a los visitantes en la WiFi para invitados WiFi.

Preguntas frecuentes

¿Funciona EAP-TLS en todos los dispositivos Android que podamos tener?

Sí. Cualquier dispositivo Android que sea probable que gestione hoy en día admite EAP-TLS en WPA2-Enterprise, y Android 10 y versiones posteriores añaden WPA3-Enterprise. Lo que ha cambiado es la validación del servidor. A partir de Android 11, todos los perfiles empresariales necesitan un certificado CA y un dominio, por lo que las guías más antiguas que omiten la validación ya no funcionan. Las etiquetas y las rutas de menú también varían según el fabricante, lo que constituye otra razón para aplicar los perfiles desde un MDM.

¿Necesitamos un MDM para desplegar EAP-TLS en Android?

No, pero lo necesitará más allá de una fase piloto. La configuración manual funciona para un grupo reducido de dispositivos. Sin embargo, cada dispositivo requiere 10 pasos de configuración, la copia de una clave privada y una renovación manual en cada vencimiento. Un MDM inscrito a través de Android Enterprise genera claves en el dispositivo y renueva los certificados automáticamente. Si ya dispone de licencias de Microsoft Intune o Workspace ONE para Android, el coste adicional consistirá principalmente en tiempo de configuración.

¿Puede el personal utilizar EAP-TLS en teléfonos Android personales?

Sí, a través de un perfil de trabajo de Android Enterprise, que mantiene los certificados y las aplicaciones corporativas independientes de los datos personales. El MDM instala el certificado y el perfil de WiFi únicamente dentro del perfil de trabajo. Algunos empleados rechazarán la inscripción en sus teléfonos personales. Para esos dispositivos, la WiFi para empleados WiFi de Purple ofrece a cada persona su propia credencial iPSK o SecurePass, vinculada a su proveedor de identidades, sin necesidad de gestión de dispositivos.

¿Se ejecutará EAP-TLS en nuestros puntos de acceso actuales?

Sí. EAP-TLS es un método 802.1X, y Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme y Fortinet admiten 802.1X. El punto de acceso solo retransmite el intercambio. Las comprobaciones de certificados se realizan entre Android y su servidor RADIUS. Debe configurar un SSID de nivel Enterprise que apunte a RADIUS y, si segmenta el tráfico, habilitar las VLAN asignadas por RADIUS.

¿Cómo se compara EAP-TLS con PEAP-MSCHAPv2 para Android?

EAP-TLS es más seguro, porque no hay ninguna contraseña que se pueda robar. PEAP-MSCHAPv2 envía un nombre de usuario y una contraseña dentro de un túnel TLS, por lo que una contraseña obtenida por phishing funciona desde cualquier dispositivo. EAP-TLS requiere un certificado cuya clave privada se mantenga en el dispositivo emitido. PEAP es más rápido de implementar porque no requiere PKI. Muchas organizaciones utilizan PEAP mientras construyen la infraestructura de certificados que necesita EAP-TLS.

¿Ayuda EAP-TLS a cumplir con PCI-DSS y GDPR?

Sí, proporciona controles y evidencias para ambos. El requisito 4.2.1.2 de PCI-DSS v4.0 exige una criptografía sólida para la autenticación inalámbrica por donde viajan los datos de los titulares de tarjetas. Los certificados por dispositivo registrados por RADIUS muestran qué dispositivo se conectó y cuándo. El artículo 32 del GDPR exige una seguridad adecuada para los datos personales, lo cual se logra mediante la autenticación mutua. EAP-TLS no le otorga el cumplimiento por sí solo; la segmentación, el registro de actividad y las directivas se siguen aplicando.

¿Cómo migramos dispositivos Android de una contraseña de WiFi compartida a EAP-TLS?

Ejecute ambas redes en paralelo y, a continuación, retire la antigua. Cree el SSID de EAP-TLS y envíe la entidad de certificación raíz (CA), el certificado SCEP y los perfiles de WiFi a un grupo piloto. Confirme que se superan las pruebas negativas y, después, amplíe la asignación por fases mientras la red de clave compartida sigue activa. Una vez que los registros de RADIUS muestren que la organización se autentica con certificados, elimine el perfil antiguo y desactive el SSID de clave compartida.

¿Dónde encaja Purple si los dispositivos de nuestro personal usan EAP-TLS?

Purple cubre todas las conexiones que EAP-TLS no cubre. El WiFi para invitados atiende a los visitantes en un SSID independiente con un Captive Portal, consentimiento informado y WiFi Analytics. El WiFi para el personal utiliza redes basadas en identidad (Identity-Based Networks) para proporcionar credenciales propias a los dispositivos no gestionados del personal. Purple funciona como una superposición en la nube sobre los puntos de acceso que ya posee, en más de 80.000 recintos activos en más de 90 países (datos de Purple).