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 informes técnicos de Purple. Hoy hablaremos de la gestión de certificados EAP-TLS; específicamente, de 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. [pausa media] Si usted es responsable del WiFi corporativo o para el personal en múltiples sitios - ya sea un grupo hotelero, una cadena de tiendas de retail, un campus universitario o un sector público - este informe es para usted. Vamos a cubrir el ciclo de vida completo del certificado: 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 salir mal las cosas, porque sí salen mal, y de cómo evitar las trampas más comunes. [pausa media] Comencemos con lo fundamental. EAP-TLS - que es el 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 usuario y contraseña, EAP-TLS utiliza autenticación mutua basada en certificados. El dispositivo prueba su identidad con un certificado de cliente. El servidor RADIUS prueba su identidad con un certificado de servidor. Ambas partes verifican a la otra. No hay contraseña que pescar. No hay credenciales que robar. Es por eso que PCI DSS 4.0 y la guía de zero-trust del NCSC apuntan hacia la autenticación basada en certificados para las redes del personal. [pausa media] 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 llevar los certificados a los dispositivos - que es SCEP o su plataforma de MDM. Tercero, 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 ponerse 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 eso, usted emite 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 importante esto? Porque si su CA Raíz se ve comprometida, tiene 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. [pausa media] 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 periodos máximos de vida de los certificados más cortos. Para los certificados de servidor TLS, el máximo actual es de 398 días. Para los certificados de cliente en redes WiFi empresariales, se tiene más flexibilidad - de uno a dos años es lo común - pero la tendencia es hacia periodos de vida más cortos y la renovación automatizada en lugar de certificados de larga duración gestionados de forma manual. La razón es simple: un periodo 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 se tienen 500 dispositivos, se pueden gestionar las renovaciones a mano con cierta dificultad. Si se tienen 5,000 dispositivos en 50 sitios, es imposible. Se necesita SCEP - el Protocolo de Inscripción de Certificados Simple - o su sucesor moderno, EST. SCEP se integra directamente con plataformas MDM, incluyendo 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 esto sin ninguna interacción del usuario. [medium pause] Para dispositivos Windows en un entorno de Active Directory, se tiene otra alternativa: la autoinscripción impulsada por directivas de grupo a través de Active Directory Certificate Services. El dispositivo se autentica en el dominio, la CA emite un certificado de forma automática y el certificado se renueva antes de su vencimiento sin ninguna intervención manual. Este es el camino más fluido para entornos con una gran presencia de Windows. [medium pause] Ahora, la revocación. Esta es la parte en la que las organizaciones suelen invertir menos y es la que más importa cuando algo sale mal. Si un dispositivo se pierde, es robado o un empleado deja la empresa, se necesita revocar su certificado de inmediato. Existen dos mecanismos: CRL - Listas de Revocación de Certificados - y OCSP - Protocolo de Estado de Certificados en Línea. [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 de forma periódica 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 obtiene una respuesta en vivo de activo 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 o denegarlo por defecto. Para entornos de alta seguridad, denegar por defecto es la respuesta correcta. Para entornos operativos donde la disponibilidad es lo más importante, se puede configurar un periodo de gracia de OCSP corto. [medium pause] Permítame presentarle dos escenarios concretos para ilustrar esto. [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 una ventana de dos semanas cada trimestre donde el personal se quedaba fuera de la red o seguía usando 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 y iOS. Utilizaron Active Directory Certificate Services como la CA. El resultado: cero eventos de rotación de contraseñas, la renovación de certificados se gestionó automáticamente 30 días antes del vencimiento, y cuando un miembro del personal se retiraba, su certificado se revocaba en el MDM a los pocos minutos de inhabilitar su cuenta en Microsoft Entra ID. El equipo de TI calculó que ahorraron aproximadamente 40 horas por trimestre en restablecimientos de contraseñas y tickets de soporte. [medium pause] Segundo: una cadena de tiendas minoristas multi-sitio con 3,000 dispositivos de personal en 200 tiendas. El reto aquí era la diversidad de dispositivos - una mezcla de laptops Windows, terminales portátiles 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 del vencimiento. Esto proporcionó un margen de renovación cómodo sin generar sobrecarga operativa. [medium pause] Ahora, los errores comunes. Hay cuatro que observo constantemente. [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 detecta la revocación dentro del plazo previsto y confirme que se le deniega el acceso al dispositivo. [medium pause] Segundo: los vencimientos masivos simultáneos. Si emite todos sus certificados al mismo tiempo con el mismo periodo de validez, todos vencerán al mismo tiempo. Distribuya su 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 simultáneos representa un incidente significativo. [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 suena obvio, pero toma por sorpresa a las organizaciones cuando tienen dispositivos BYOD o laptops 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 de WiFi dejará de funcionar. Integre redundancia en su infraestructura de 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 está bien y simplifica la distribución de la confianza. [medium pause] ¿Qué pasa con el BYOD? El BYOD es el caso difícil. 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 el modo de seguridad de 192 bits para entornos sensibles, lo que requiere suites de cifrado específicas. 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 bien 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 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 de certificados se active automáticamente al desactivar una cuenta. [medium pause] Si tiene 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 compatible - no está atado a las herramientas de PKI de un solo proveedor. [medium pause] Próximos pasos: audite su inventario actual de certificados. 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.