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

Hable en un inglés británico con un tono seguro, autoritario y conversacional, como un consultor senior que informa a un cliente. Ritmo pausado, dicción clara, cálido pero directo. Pausas naturales ocasionales para enfatizar: Bienvenido a la serie de informes técnicos 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. [pausa media] Si es usted responsable de la red WiFi corporativa o del personal en múltiples ubicaciones - ya sea un grupo hotelero, un sector minorista, un campus universitario o un patrimonio del sector público - este informe es para usted. Vamos a cubrir todo el ciclo de vida de los certificados: desde la configuración de su jerarquía de CA, pasando por el despliegue automatizado 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. [pausa media] Empecemos por lo fundamental. EAP-TLS - es decir, Extensible Authentication Protocol con Transport Layer Security - 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. No hay contraseña que pescar con phishing. No hay credenciales que robar. Por eso tanto la norma PCI-DSS 4.0 como la guía de confianza cero del NCSC apuntan a la autenticación basada en certificados para las redes del personal. [pausa media] Ahora, la arquitectura. Necesita tres cosas para que EAP-TLS funcione. En primer lugar, una infraestructura de clave pública - su jerarquía de CA. En segundo lugar, un mecanismo para introducir los certificados en los dispositivos - es decir, SCEP o su plataforma MDM. En tercer lugar, un servidor RADIUS que confíe en su CA y pueda validar los certificados de cliente en tiempo real. [pausa media] La jerarquía de CA es donde la mayoría de las organizaciones tienen problemas al principio. El patrón correcto es un modelo de tres niveles. Tiene una CA raíz en la parte superior - esta debe estar fuera de línea, aislada de la red, y sólo se conecta en línea para firmar su certificado de 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. [pausa media] ¿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 puede sustituirse sin tocar la raíz. Ese es el argumento de resiliencia operativa para el modelo de tres niveles. [pausa media] Hablemos de los periodos de validez de los certificados. Se ha producido un cambio muy importante en el sector. Apple, Google y Mozilla han pasado a exigir periodos máximos de validez de los certificados más cortos. En el caso de los certificados de servidor TLS, el máximo actual es de 398 días. Para los certificados de cliente en redes WiFi corporativas, se dispone de más flexibilidad (lo habitual es de uno a dos años), pero la tendencia es hacia periodos de validez más cortos y una renovación automatizada en lugar de gestionar manualmente certificados de larga duración. La razón es sencilla: un periodo de validez más corto limita el tiempo 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 tienes 500 dispositivos, es posible gestionar las renovaciones a mano. Si tienes 5000 dispositivos en 50 ubicaciones, no es viable. Necesitas SCEP (Simple Certificate Enrolment Protocol) o su sucesor moderno, EST. SCEP se integra directamente con las plataformas MDM, incluidas 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 tu servidor SCEP y recibe 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: el registro automático controlado por políticas 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 caduque sin ninguna intervención manual. Esta es la vía más sencilla para las infraestructuras con una gran presencia de Windows. [medium pause] Pasemos ahora a la revocación. Este es el aspecto en el que las organizaciones suelen invertir menos, y es el más crítico cuando algo sale mal. Si un dispositivo se pierde o es robado, 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. Tu 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. El problema de la CRL es la latencia: si tu 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 directo que indica si el certificado es válido o está revocado. El inconveniente es que tu respondedor OCSP se convierte en una dependencia crítica: si no está disponible, debes decidir si permites el acceso o lo bloqueas. Para entornos de alta seguridad, bloquear el acceso es la opción adecuada. Para entornos operativos donde la disponibilidad es lo más importante, puedes configurar un breve periodo de gracia de OCSP. [medium pause] Permíteme presentarte dos escenarios concretos para ilustrar esto de forma práctica. [medium pause] Primero: un grupo hotelero 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 un intervalo de dos semanas cada trimestre en el que el personal se quedaba sin acceso o utilizaba la contraseña antigua. Pasaron a EAP-TLS utilizando Microsoft Intune para el despliegue de certificados. Perfiles SCEP distribuidos a todos los dispositivos Windows y iOS. 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 su 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 al 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 combinación de portátiles Windows, terminales de mano 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 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 costes operativos adicionales. [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 llegan a probar 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: el abismo de las expiraciones masivas. Si emite todos sus certificados al mismo tiempo con el mismo periodo de validez, todos expirarán a la vez. Escalone 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 simultáneamente 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: la 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. Añada redundancia a su infraestructura OCSP o configure un periodo de gracia corto con la monitorización adecuada. [medium pause] Muy bien, pasemos a las 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 emiten 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 el BYOD? El BYOD es el caso más complejo. No se pueden enviar certificados a dispositivos no gestionados a través de un 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 el 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. Registro automatizado mediante 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 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 endpoint CRL u OCSP. La arquitectura de Purple, independiente del hardware, permite que esto funcione en Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist y el resto de la lista de hardware habitual; no está 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 ha emitido, eso es lo primero que debe solucionar. A partir de ahí, el camino hacia la automatización completa está claramente definido. Gracias por su atención.