Gestión de certificados digitales para la autenticación WiFi EAP-TLS

Habla en inglés británico con un tono confiado, con autoridad y conversacional, como un consultor senior informando a un cliente. Ritmo pausado, dicción clara, cálido pero directo. Pausas naturales ocasionales para enfatizar: Bienvenido a la serie de sesiones informativas técnicas de Purple. Hoy hablaremos sobre la gestión de certificados EAP-TLS; específicamente, cómo ejecutar un programa de autenticación WiFi basado en certificados a escala sin que se convierta en una carga operativa de tiempo completo. [medium pause] Si eres responsable del WiFi corporativo o del personal en múltiples sitios —ya sea un grupo hotelero, una cadena de tiendas de retail, un campus universitario o un complejo del sector público—, esta sesión informativa es para ti. Cubriremos el ciclo de vida completo de los certificados: desde la configuración de su jerarquía de CA, pasando por la implementación automatizada a través de SCEP y MDM, hasta la renovación y revocación. Y hablaremos de dónde suelen fallar las cosas, porque sí fallan, y de cómo evitar las trampas más comunes. [medium pause] Comencemos con los aspectos fundamentales. EAP-TLS —es decir, Protocolo de Autenticación Extensible con Seguridad de la Capa de Transporte— es el estándar de oro para la autenticación WiFi 802.1X. A diferencia de PEAP, que depende de un nombre de usuario y contraseña, EAP-TLS utiliza una autenticación mutua basada en certificados. El dispositivo demuestra su identidad con un certificado de cliente. El servidor RADIUS demuestra su identidad con un certificado de servidor. Ambas partes se verifican mutuamente. Sin contraseñas que pescar con phishing. Sin credenciales que robar. Es por eso que tanto PCI DSS 4.0 como la guía de confianza cero (zero-trust) de la NCSC apuntan hacia la autenticación basada en certificados para las redes del personal. [medium pause] Ahora, la arquitectura. Necesitas tres cosas para que EAP-TLS funcione. Primero, una Infraestructura de Clave Pública (PKI): tu jerarquía de CA. Segundo, un mecanismo para instalar certificados en los dispositivos: es decir, SCEP o tu plataforma MDM. Tercero, un servidor RADIUS que confíe en tu CA y pueda validar los certificados de cliente en tiempo real. [medium pause] La jerarquía de CA es donde la mayoría de las organizaciones tienen problemas desde el principio. El patrón correcto es un modelo de tres niveles. Tienes una CA Raíz en la parte superior; esta debe estar desconectada, aislada físicamente (air-gapped) y solo ponerse en línea para firmar el certificado de tu CA Intermedia. La CA Intermedia —a veces llamada CA Emisora— es la que realmente firma los certificados del día a día. Está en línea, pero su clave privada está bien protegida. Por debajo de eso, emites dos tipos de certificados: certificados de servidor para tu infraestructura RADIUS y certificados de cliente para tus dispositivos y usuarios. [medium pause] ¿Por qué es importante esto? Porque si tu CA Raíz se ve comprometida, tendrás que reconstruir toda tu PKI desde cero y volver a registrar cada dispositivo. Mantenerla desconectada elimina ese riesgo. La CA Intermedia se puede reemplazar sin tocar la Raíz. Ese es el argumento de resiliencia operativa para el modelo de tres niveles. [medium pause] Hablemos de los periodos de validez de los certificados. Ha habido un cambio significativo en la industria en este aspecto. Apple, Google y Mozilla han tomado medidas para imponer un tiempo de vida máximo más corto para los certificados. Para los certificados de servidor TLS, el máximo actual es de 398 días. Para los certificados de cliente en WiFi empresarial, se tiene más flexibilidad (lo común es de uno a dos años), pero la tendencia se inclina hacia tiempos de vida más cortos y la renovación automatizada en lugar de certificados de larga duración gestionados manualmente. La razón es simple: un tiempo de vida más corto limita la ventana de exposición si un certificado se ve comprometido. [medium pause] Esto nos lleva a la automatización. La gestión manual de certificados no es escalable. Si tiene 500 dispositivos, apenas puede gestionar las renovaciones de forma manual. Si tiene 5,000 dispositivos en 50 sitios, no es posible. Necesita SCEP (Simple Certificate Enrolment Protocol) o su sucesor moderno, EST. SCEP se integra directamente con plataformas MDM como Microsoft Intune, Jamf Pro y VMware Workspace ONE. El MDM envía un perfil de configuración SCEP al dispositivo. El dispositivo genera un par de claves, envía una solicitud de firma de certificado a su servidor SCEP y recibe de vuelta un certificado firmado, todo sin ninguna interacción del usuario. [medium pause] Para los dispositivos Windows en un entorno de Active Directory, existe una alternativa: la autoinscripción impulsada por directivas de grupo mediante Active Directory Certificate Services. El dispositivo se autentica en el dominio, la CA emite un certificado automáticamente y este se renueva antes de vencer sin ninguna intervención manual. Esta es la vía más fluida para infraestructuras con un gran volumen de dispositivos Windows. [medium pause] Ahora, la revocación. Este es el aspecto en el que las organizaciones suelen invertir menos, y es el que más importa cuando algo sale mal. Si un dispositivo se pierde, es robado o un empleado deja la empresa, es necesario revocar su certificado de inmediato. Existen dos mecanismos: CRL (Certificate Revocation Lists) y OCSP (Online Certificate Status Protocol). [medium pause] CRL es el mecanismo más antiguo. Su CA publica una lista de números de serie de certificados revocados en una URL conocida. El servidor RADIUS descarga esta lista periódicamente y la coteja. El problema con CRL es la latencia: si su CRL tiene un periodo de validez de 24 horas, un certificado revocado aún puede autenticarse hasta 24 horas después de su revocación. [medium pause] OCSP es la alternativa en tiempo real. El servidor RADIUS envía una consulta al respondedor OCSP para cada intento de autenticación y recibe una respuesta en vivo de válido o revocado. La desventaja es que su respondedor OCSP se convierte en una dependencia crítica: si no está disponible, debe decidir si permitir el acceso de forma predeterminada (fail open) o bloquearlo (fail closed). Para entornos de alta seguridad, bloquear el acceso (fail closed) es la respuesta correcta. Para entornos operativos donde la disponibilidad es lo más importante, puede configurar un breve periodo de gracia de OCSP. [medium pause] Permítame presentarle dos escenarios concretos para ilustrar esto de forma práctica. [medium pause] Primero: un grupo hotelero con 150 propiedades. Operaban con PEAP utilizando una contraseña compartida para el WiFi del personal. La rotación de contraseñas era trimestral, lo que significaba un intervalo de dos semanas cada trimestre en el que el personal se quedaba sin acceso o utilizaba la contraseña anterior. Migraron a EAP-TLS utilizando Microsoft Intune para el despliegue de certificados. Los perfiles SCEP se enviaron a todos los dispositivos Windows e iOS. Utilizaron Active Directory Certificate Services como CA. El resultado: cero eventos de rotación de contraseñas, la renovación de certificados se gestionó automáticamente 30 días antes de su vencimiento y, cuando un miembro del personal dejaba la empresa, su certificado se revocaba en el MDM a los pocos minutos de haber inhabilitado su cuenta en Microsoft Entra ID. El equipo de TI estimó que ahorraron aproximadamente 40 horas por trimestre en restablecimientos de contraseñas y tickets de soporte técnico. [medium pause] Segundo: una cadena de retail multisitio con 3,000 dispositivos de personal en 200 tiendas. El desafío aquí era la diversidad de dispositivos: una mezcla de laptops Windows, terminales portátiles Android y dispositivos iOS. Utilizaron Jamf Pro para dispositivos Apple y Microsoft Intune para Windows y Android, ambos apuntando al mismo servidor SCEP respaldado por una CA intermedia de Microsoft ADCS. La infraestructura de WiFi era Cisco Meraki, con autenticación RADIUS gestionada por un servicio RADIUS alojado en la nube e integrado con Purple. La decisión de diseño clave fue emitir certificados con una validez de 12 meses y configurar la renovación automática 60 días antes de su vencimiento. Esto ofreció un margen de renovación cómodo sin generar sobrecarga operativa. [medium pause] Ahora, los errores comunes. Hay cuatro que veo de manera constante. [medium pause] Primero: no probar la revocación. Las organizaciones configuran su PKI, despliegan certificados y nunca prueban realmente si la revocación funciona de extremo a extremo. Pruébelo. Revoque un certificado de prueba, confirme que el servidor RADIUS detecte la revocación dentro del intervalo esperado y confirme que se le deniegue el acceso al dispositivo. [medium pause] Segundo: vencimientos masivos simultáneos. Si emite todos sus certificados al mismo tiempo con el mismo periodo de validez, todos vencerán a la vez. Distribuya la emisión de forma escalonada o, como mínimo, escalone los activadores de renovación. Una tasa de fallo de renovación del 10% en 5,000 dispositivos de manera simultánea es un incidente crítico. [medium pause] Tercero: no distribuir el certificado de la CA raíz a todos los dispositivos antes de desplegar EAP-TLS. Si el dispositivo no confía en su CA raíz, rechazará el certificado del servidor RADIUS y la autenticación fallará. Esto parece obvio, pero toma desprevenidas a las organizaciones cuando tienen dispositivos BYOD o laptops de contratistas que no están registrados en el MDM. [medium pause] Cuarto: disponibilidad del respondedor OCSP. Si su respondedor OCSP se cae y su servidor RADIUS está configurado para denegar el acceso ante errores de OCSP, toda su red WiFi dejará de funcionar. Incorpore redundancia en su infraestructura OCSP o configure un periodo de gracia corto con el monitoreo adecuado. [medium pause] Muy bien, preguntas rápidas. [medium pause] ¿Puedo usar una CA pública para los certificados de cliente EAP-TLS? Técnicamente sí, pero en la práctica no. Las CA públicas no emitirán certificados de cliente para dispositivos arbitrarios. Necesita su propia CA para los certificados de cliente. Para el certificado del servidor RADIUS, una CA pública es adecuada y simplifica la distribución de la confianza. [medium pause] ¿Qué pasa con BYOD? BYOD es el caso difícil. No se pueden enviar certificados a dispositivos no gestionados a través de MDM. Las opciones incluyen un portal de control de acceso a la red que emita certificados de corta duración tras la autenticación del usuario, o simplemente mantener BYOD en un SSID independiente con un método de autenticación diferente. [medium pause] ¿Cómo interactúa esto con WPA3? WPA3-Enterprise exige un modo de seguridad de 192 bits para entornos sensibles, lo que requiere conjuntos de cifrado específicos. EAP-TLS es totalmente compatible con WPA3-Enterprise y es, de hecho, el método de autenticación recomendado. [medium pause] En resumen, la gestión de certificados EAP-TLS no es sencilla, pero es manejable si se define correctamente la arquitectura desde el principio. Jerarquía de CA de tres niveles. Inscripción automatizada a través de SCEP o MDM. Ciclos de vida de certificados cortos con renovación automatizada. Revocación en tiempo real a través de OCSP. Pruebe todo, especialmente la revocación. E integre el ciclo de vida de sus certificados con su proveedor de identidad (Microsoft Entra ID, Okta o Google Workspace) para que la revocación del certificado se active automáticamente cuando se desactive una cuenta. [medium pause] Si utiliza servidores RADIUS vinculados a Purple, los puntos de integración son la URL de su servidor SCEP, el certificado de su servidor RADIUS y su punto de conexión CRL u OCSP. La arquitectura agnóstica de hardware de Purple significa que esto funciona en Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist y el resto de la lista de hardware canónico; no está limitado a las herramientas de PKI de un solo proveedor. [medium pause] Siguientes pasos: audite su inventario de certificados actual. Si no sabe cuántos certificados tiene, cuándo vencen y quién los emitió, eso es lo primero que debe solucionar. A partir de ahí, el camino hacia la automatización completa está bien definido. Gracias por escuchar.