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

Hable en inglés británico con un tono seguro, autoritario y conversacional, como un consultor sénior informando a un cliente. Ritmo pausado, dicción clara, cálido pero directo. Pausas naturales ocasionales para dar énfasis: Bienvenido a la serie de sesiones informativas técnicas de Purple. Hoy hablaremos de la gestión de certificados EAP-TLS; concretamente, de cómo ejecutar un programa de autenticación WiFi basado en certificados a escala sin que se convierta en una carga operativa a tiempo completo. [medium pause] Si es responsable de la red WiFi corporativa o del personal en múltiples ubicaciones, ya sea un grupo hotelero, un sector de comercio minorista, un campus universitario o un sector público, esta sesión informativa es para usted. Cubriremos todo el ciclo de vida 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 fallan, y de cómo evitar las trampas más comunes. [medium pause] Empecemos con los aspectos fundamentales. EAP-TLS (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 una 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 mediante phishing. Sin credenciales que robar. Por eso, tanto PCI DSS 4.0 como la guía de confianza cero del NCSC apuntan hacia la autenticación basada en certificados para las redes del personal. [medium pause] Ahora, la arquitectura. Necesita tres cosas para que EAP-TLS funcione. Primero, una infraestructura de clave pública (su jerarquía de CA). Segundo, un mecanismo para instalar certificados en los dispositivos (es decir, SCEP o su plataforma MDM). Tercero, un servidor RADIUS que confíe en su CA y pueda validar certificados de cliente en tiempo real. [medium pause] La jerarquía de CA es donde la mayoría de las organizaciones suelen tener problemas al principio. El patrón correcto es un modelo de tres niveles. En la cima tiene una CA raíz (esta debe estar fuera de línea, aislada de la red y solo conectarse para firmar el certificado de su 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 ella, se emiten dos tipos de certificados: certificados de servidor para su infraestructura RADIUS y certificados de cliente para sus dispositivos y usuarios. [medium pause] ¿Por qué es esto importante? Porque si su CA raíz se ve comprometida, tendrá que reconstruir toda su PKI desde cero y volver a registrar cada dispositivo. Mantenerla fuera de línea 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 períodos de validez de los certificados. Ha habido un cambio significativo en el sector en este aspecto. Apple, Google y Mozilla han tomado medidas para imponer una duración máxima de los certificados más corta. Para los certificados de servidor TLS, el máximo actual es de 398 días. Para los certificados de cliente en redes WiFi corporativas, hay más flexibilidad (lo habitual es de uno a dos años), pero la tendencia es hacia ciclos de vida más cortos y la renovación automatizada en lugar de certificados de larga duración gestionados manualmente. El motivo es sencillo: una duración más corta limita el periodo de exposición en caso de que un certificado se vea comprometido. [medium pause] Esto nos lleva a la automatización. La gestión manual de certificados no es escalable. Si tiene 500 dispositivos, aún puede llegar a gestionar las renovaciones a mano. Si tiene 5000 dispositivos en 50 centros, es imposible. 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 ello sin ninguna interacción del usuario. [medium pause] Para los dispositivos Windows en un entorno de Active Directory, existe una alternativa: la autoinscripción basada en Directivas de grupo a través de Active Directory Certificate Services. El dispositivo se autentica en el dominio, la CA emite un certificado automáticamente y este se renueva antes de que expire sin ninguna intervención manual. Esta es la vía más fluida para infraestructuras con una alta presencia de Windows. [medium pause] Hablemos ahora de la revocación. Este es el aspecto en el que las organizaciones suelen invertir menos de lo necesario y, sin embargo, es el que más importa cuando algo sale mal. Si un dispositivo se pierde o se roba, o si 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 realiza la comprobación con ella. El problema de las CRL es la latencia: si su CRL tiene un periodo de validez de 24 horas, un certificado revocado aún podría autenticarse durante un máximo de 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 sistema de respuesta OCSP en cada intento de autenticación y obtiene una respuesta en directo sobre si es válido o está revocado. La contrapartida es que el sistema de respuesta OCSP se convierte en una dependencia crítica: si no está disponible, debe decidir si permite el acceso por defecto (fail open) o si lo deniega (fail closed). Para entornos de alta seguridad, denegar el acceso por defecto es la respuesta correcta. Para entornos de producción donde la disponibilidad es prioritaria, puede configurar un periodo de gracia corto para OCSP. [medium pause] Permítame presentarle dos escenarios concretos para ilustrar esto de forma práctica. [medium pause] Primero: una cadena hotelera de 150 propiedades. Utilizaban PEAP con una contraseña compartida para el WiFi del personal. La rotación de contraseñas era trimestral, lo que significaba una ventana de dos semanas cada trimestre en la que el personal se quedaba fuera o utilizaba la contraseña antigua. Pasaron 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, renovación de certificados gestionada automáticamente 30 días antes de la expiración y, cuando un miembro del personal se marchaba, su certificado se revocaba en el MDM a los pocos minutos de desactivar 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. [medium pause] Segundo: una cadena de tiendas multisede con 3.000 dispositivos de personal en 200 tiendas. El reto aquí era la diversidad de dispositivos: una mezcla de portátiles Windows, terminales Android y dispositivos iOS. Utilizaban Jamf Pro para los 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 la autenticación RADIUS gestionada por un servicio RADIUS alojado en la nube e integrado con Purple. La decisión clave de diseño fue emitir certificados con una validez de 12 meses y configurar la renovación automática a los 60 días antes de la expiración. Esto proporcionó un margen de renovación cómodo sin generar sobrecarga operativa. [medium pause] Ahora, los errores comunes. Hay cuatro que veo de forma constante. [medium pause] Primero: no probar la revocación. Las organizaciones configuran su PKI, despliegan los 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 detecta la revocación dentro del plazo previsto y confirme que se deniega el acceso al dispositivo. [medium pause] Segundo: acantilados de expiración. Si emite todos sus certificados al mismo tiempo con el mismo periodo de validez, todos expirarán a la vez. Escale la emisión o, como mínimo, escalone los activadores de renovación. Una tasa de fallo de renovación del 10% en 5.000 dispositivos de forma simultánea es un incidente grave. [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 pilla desprevenidas a las organizaciones cuando tienen dispositivos BYOD o portátiles 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 bloquear el acceso en caso de errores de OCSP, toda su red WiFi dejará de funcionar. Añada redundancia a su infraestructura OCSP o configure un periodo de gracia corto con la monitorización adecuada. [medium pause] Bien, preguntas rápidas. [medium pause] ¿Puedo utilizar 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 insertar certificados en 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 mediante OCSP. Pruébelo 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 de certificados se active automáticamente cuando se desaprovisione 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 endpoint CRL u OCSP. La arquitectura independiente del hardware de Purple permite que esto funcione en Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist y el resto de la lista de hardware habitual; no estará limitado a las herramientas de PKI de un único proveedor. [medium pause] Siguientes pasos: audite su inventario de certificados actual. Si no sabe cuántos certificados tiene, cuándo caducan 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 su atención.