Roban la laptop de la empresa en el tren. El soporte técnico deshabilita la cuenta de Active Directory del empleado, el dispositivo desaparece del registro de activos y todos asumen que el riesgo se ha eliminado. Dos días después, la laptop todavía aparece en el SSID corporativo porque su suplicante 802.1X contiene un certificado de cliente que no ha expirado y nadie lo ha revocado.
Esa es la brecha que el proceso de una lista de revocación de certificados está diseñado a cerrar. La expiración del certificado establece el límite máximo de confianza, mientras que la revocación interrumpe la confianza antes de tiempo cuando una clave se ve comprometida, se pierde un dispositivo o un usuario se va. Para un administrador de red WiFi empresarial, la pregunta crucial no es si existen los certificados. Es si RADIUS y los controles de red relacionados se enteran rápidamente de un certificado revocado y fallan de manera segura.
El acceso WiFi que no se quería ir
Un despliegue de WiFi basado en certificados a menudo parece seguro desde el exterior. El cliente utiliza EAP-TLS, el servicio RADIUS valida la cadena de certificados y las contraseñas compartidas no se pasan entre el personal. Pero ese diseño aún depende de un ciclo de vida funcional. Emitir un certificado es solo el comienzo. También debe saber quién es el propietario, cuándo expira y qué sucede si el dispositivo o la clave privada ya no son de confianza.
En el ejemplo de la laptop robada, eliminar la cuenta de Active Directory puede detener la autenticación futura del directorio, pero no invalida necesariamente un certificado ya instalado en el dispositivo. Si el servicio de WiFi confía en el certificado basándose únicamente en su cadena y fechas de validez, la laptop puede seguir presentando credenciales aparentemente válidas. La notAfter date del certificado dice que sigue dentro de su vida útil programada. No dice que la organización emisora aún desee confiar en él.
Regla práctica: Trate el vencimiento del certificado y la revocación del certificado como controles separados. El vencimiento es la gestión planificada del ciclo de vida. La revocación es el freno de mano de emergencia.
El modelo de PKI del sector público del Reino Unido hace explícita esa distinción. Una Lista de Revocación de Certificados, o CRL, es una lista firmada de números de serie de certificados revocados antes de su vencimiento, que indica a las partes que confían en ellos que dichos certificados ya no deben ser de confianza. La guía de infraestructura de clave pública del Reino Unido también identifica a las CRL como uno de los métodos comunes de revocación y espera que los clientes verifiquen si un certificado presentado aparece en la lista de la CA emisora.
Esto es importante en la WiFi porque las decisiones de autenticación ocurren en el extremo de la red, a menudo a través de muchos controladores, puntos de acceso, servidores RADIUS y almacenes de validación en caché. Una actualización manual de la CRL puede dejar una brecha de seguridad, mientras que una política de falla de cierre mal diseñada puede generar una interrupción si el punto de distribución de la CRL deja de estar disponible.
El modelo mental de trabajo es sencillo: la CA emite y firma la información de estado, la parte de confianza la verifica y la red deniega un certificado que ha sido revocado. El resto de esta guía examina cómo funciona ese proceso, en qué se diferencian CRL y OCSP, y cómo los controles de acceso basados en directorios pueden eliminar gran parte del cuello de botella de la revocación manual.
Qué es realmente un certificado de lista de revocación
En lenguaje sencillo, una Lista de Revocación de Certificados es un aviso oficial de "no confiar más en estos certificados" de una autoridad de certificación. Identifica los certificados por sus números de serie, no por un nombre de dispositivo descriptivo o la dirección de correo electrónico de un empleado. Un cliente que encuentre el número de serie del certificado presentado en la lista correspondiente debe rechazarlo, incluso si la fecha de vencimiento del certificado aún está en el futuro.
La definición del Reino Unido es formal. Describe una CRL como una lista firmada de números de serie de certificados revocados antes de su vencimiento, de modo que las partes que confían ya no deben confiar en dichos certificados. La firma es importante porque un servidor RADIUS u otro validador debe confirmar que la lista proviene del emisor esperado y no ha sido modificada en tránsito. Una lista de bloqueo en texto sin formato mantenida por un administrador no proporciona esa garantía criptográfica.
Tres partes hacen que el proceso sea útil:
- La autoridad de certificación: La CA, o un emisor de CRL autorizado, crea la lista y la firma mediante una clave privada asociada con la jerarquía de confianza emisora.
- La parte que confía: Un servidor RADIUS, suplicante, controlador, sistema operativo o herramienta administrativa descarga la lista, valida su firma y la información de validez, y luego busca el número de serie del certificado.
- El titular del certificado: La persona, dispositivo o servicio cuyo certificado ha sido revocado. Su número de serie permanece en la lista para que los validadores puedan identificarlo como no confiable.
Normalmente, una CRL no es un certificado en el mismo sentido que un certificado de usuario o dispositivo. Es un artefacto de PKI firmado que contiene información del emisor, validez y publicación. A veces se utiliza "certificado de lista de revocación" como abreviatura para el mecanismo de revocación de certificados, pero el objeto operativo que se verifica es la CRL firmada.
La parte confiable no suele pedir a la CA que explique por qué se debe rechazar a un usuario. Sigue la información de revocación del certificado, recupera la CRL actual del emisor, verifica la CRL y comprueba el número de serie. Si hay una coincidencia, el certificado se revoca. Si no la hay, el resultado sigue estando limitado por la frescura de la CRL y el propio caché de la parte confiable.
Ese último punto causa muchos incidentes. Un certificado puede estar ausente en una lista antigua almacenada en caché y presente en una más nueva. Por lo tanto, la decisión de la red depende tanto de lo que publicó la CA como de cuándo lo obtuvo el autenticador por última vez.
Cómo funciona una CRL tras bambalinas
El ciclo de vida de una CRL sigue una cadena de eventos predecible. Primero, la CA genera una lista base de acuerdo con su política de certificados. Firma la lista, agrega campos de publicación y validez, y la pone a disposición a través de un punto de distribución. Los certificados emitidos comúnmente hacen referencia a esas ubicaciones a través de la extensión CRL Distribution Points, lo que permite que un validador descubra a dónde pertenece la información de estado.
Cuando un administrador revoca el certificado de un dispositivo, la CA registra su número de serie y la información del motivo. El certificado no aparecerá necesariamente en la caché de cada parte confiable de inmediato. La siguiente CRL publicada debe contener la entrada, y cada servidor RADIUS o controlador debe recuperar una copia actual antes de poder tomar la decisión correcta.
Algunos entornos de PKI también utilizan CRL delta. Una delta contiene los cambios desde una CRL base, lo que puede reducir el trabajo de transferencia y procesamiento cuando la lista completa es grande. Esa eficiencia no elimina la necesidad de administrar la lista base, validar firmas, rastrear la actualización o asegurarse de que cada componente de la red comprenda el modelo de publicación elegido.
La ventana de frescura
Las políticas del Reino Unido proporcionan puntos de referencia útiles para pensar en la propagación. La declaración de prácticas de la CVCA del gobierno del Reino Unido exige que las CRL se emitan como máximo cada 90 días, y requiere que un certificado revocado aparezca en la CRL correspondiente dentro de las 72 horas posteriores a la revocación. Esos límites se describen en la política nacional de certificados del Reino Unido.
Otras políticas del Reino Unido utilizan diferentes expectativas de servicio. HM Land Registry establece que su lista de revocación para certificados revocados y suspendidos debe actualizarse al menos una vez al día, mientras que la declaración de prácticas de certificación de la University of York otorga una latencia máxima de 10 días entre la revocación y la emisión de la CRL. Estos ejemplos, incluido el punto de publicación de la HMPO Country Signing Certificate Authority, demuestran por qué un administrador debe leer la política real de la CA emisora en lugar de asumir que todas las CRL se comportan de la misma manera.
Al momento de la autenticación, el servidor RADIUS compara el número de serie del certificado con su CRL disponible localmente. También comprueba si la CRL está dentro de su período de validez, si la firma se encadena con el emisor esperado y si se puede acceder al punto de distribución cuando vence una actualización. Luego, el servidor almacena el resultado en caché de acuerdo con su implementación y el valor nextUpdate de la CRL.
Eso genera una ecuación de riesgo práctica sin necesidad de matemáticas complicadas: la latencia de revocación incluye el tiempo de publicación de la CA, el retraso de la distribución, la duración de la caché y la frecuencia de autenticación. Una política puede publicarse rápidamente, pero una caché de RADIUS desconectada o desactualizada aún puede retrasar la aplicación de la norma.
CRL vs OCSP y por qué es importante en WiFi
CRL y OCSP resuelven el mismo problema básico de diferentes maneras. Una CRL le da al validador un lote firmado de números de serie revocados. OCSP le pregunta a un respondedor autorizado por el estado de un certificado en el momento en que se está verificando.
Para un administrador de WiFi empresarial, la elección afecta más que la elegancia de la PKI. Cambia la forma en que se comporta un controlador a través de una WAN congestionada, lo que la infraestructura de CA debe manejar y si un intento de autenticación se puede completar cuando un respondedor o punto de distribución no está disponible.
| Criterio | CRL | OCSP |
|---|---|---|
| Frescura | Periódica. Un certificado recién revocado espera a la publicación y a la actualización del cliente. | La consulta por certificado puede proporcionar un estado más actualizado cuando el respondedor está accesible. |
| Carga de infraestructura | Los clientes descargan y procesan una lista, lo cual puede ser eficiente para comprobaciones repetidas en un parque gestionado, pero puede generar tráfico de distribución. | El respondedor gestiona las solicitudes de estado individuales, lo que evita la descarga de la lista completa pero incrementa el volumen de solicitudes. |
| Privacidad | La parte de confianza obtiene una lista y no necesita revelar cada comprobación de certificado a la CA. | Una consulta directa puede revelar al respondedor qué certificado se está comprobando. |
| Modo de fallo | Una CRL inaccesible o expirada puede impedir la validación confiable del estado. Las cachés locales pueden seguir funcionando hasta su límite de frescura. | Un respondedor inaccesible afecta la consulta de estado individual, y el comportamiento de fallo suave (soft-fail) o fallo duro (hard-fail) configurado determina el resultado de la conexión WiFi. |
Un controlador que atiende a un campus grande podría preferir una CRL almacenada localmente en caché, ya que puede verificar muchos números de serie de certificados sin enviar una solicitud por separado para cada autenticación. Ese modelo funciona bien cuando los puntos de distribución son accesibles, se monitorean las actualizaciones y la política de RADIUS maneja una lista caducada de manera deliberada.
OCSP puede adaptarse a un diseño donde el operador necesita una respuesta por certificado y acepta la dependencia de un respondedor. Puede reducir la necesidad de transferir una lista completa, pero introduce una dependencia de red en vivo durante la autenticación. El grapado (stapling) puede trasladar la interacción del respondedor a otra parte en algunos protocolos; sin embargo, el diseño de WiFi aún necesita una respuesta clara para los datos de estado no disponibles o desactualizados.
La guía del Reino Unido es útil en este caso porque no presenta la CRL como el único método. La política del Reino Unido describe las CRL como uno de los mecanismos de revocación comunes, mientras que la guía del sector de justicia las trata como un mecanismo primario fuera de línea y destaca los requisitos de disponibilidad para los servicios de revocación en la declaración de divulgación de PKI.
Para dispositivos 802.1X administrados, la CRL suele ser práctica para la validación periódica por lotes, especialmente cuando el parque tecnológico cuenta con una distribución interna confiable. OCSP es preferible cuando es esencial una mayor frescura del estado y la disponibilidad del contestador está diseñada en consecuencia. Las redes de alta seguridad pueden ejecutar ambos, pero solo si el comportamiento de respaldo está documentado y probado en lugar de asumirse.
La revocación en la práctica en una red Purple WiFi
La diferencia operativa aparece cuando el acceso WiFi está vinculado a un directorio de identidad en vivo en lugar de a una lista de certificados mantenida manualmente. Una integración de directorio puede hacer que el estado actual de la cuenta del usuario forme parte de la decisión de autenticación, por lo que deshabilitar una cuenta se convierte en un evento de control de acceso en lugar de un ticket que alguien debe traducir más tarde en una revocación de la CA.
Un flujo típico se ve así:
- El directorio registra el estado de la identidad. Se crea, modifica, suspende o inhabilita una cuenta en Active Directory, Entra ID o Google Workspace.
- El servicio de identidad WiFi recibe el cambio. El servicio mapea el estado del directorio con la política de autenticación de la organización.
- La siguiente autenticación se evalúa contra ese estado. Una identidad inhabilitada ya no cumple con la regla de acceso, incluso si una credencial emitida anteriormente sigue dentro del periodo de validez de su certificado.
- La red deniega el acceso. La decisión de RADIUS evita que se autorice una nueva sesión 802.1X bajo la identidad inactiva.
Ese modelo aborda una debilidad en las operaciones que solo utilizan CRL. Una CRL depende de la publicación de la CA, los puntos de distribución, las actualizaciones de caché y las comprobaciones de las partes confiables. El cumplimiento impulsado por el directorio convierte al sistema de identidad en la fuente operativa de verdad para el estado de la cuenta, lo que reduce la necesidad de que un administrador busque cada número de serie de certificado asociado con un usuario que se va.
Distinción operativa: Una CRL responde si un certificado está revocado. La autenticación dirigida por el directorio puede responder si la identidad está actualmente autorizada para usar la red.
Purple proporciona controles de WiFi corporativos basados en certificados y RADIUS administrados con integraciones de directorio como Entra ID y Google Workspace. Su oferta de RADIUS-as-a-Service es relevante cuando una organización desea conectar el estado de identidad con la autenticación 802.1X sin mantener ella misma cada componente de revocación y RADIUS de forma local.
Esto no hace que el trabajo del ciclo de vida de PKI desaparezca. Los certificados aún necesitan emisión, renovación, gestión de la cadena de confianza y comprobaciones de revocación donde la arquitectura lo requiera. Sin embargo, elimina un cuello de botella manual de la ruta de salida de empleados. El centro de soporte puede desactivar la identidad a través del flujo de trabajo de directorio establecido, mientras que la capa de autenticación de red aplica ese estado en la siguiente decisión de acceso.
Prácticas recomendadas operativas para WiFi empresarial
Un diseño de revocación confiable combina controles criptográficos con una disciplina operativa ordinaria. Comience con la vida útil del certificado. Para dispositivos WiFi administrados, una vida útil de certificado de 12 a 24 meses es una referencia operativa común en la guía de implementación suministrada, pero la elección correcta depende de la propiedad del dispositivo, la capacidad de renovación y el daño que podría causar una clave privada expuesta. Los certificados de patrocinadores de invitados generalmente deben tener vidas útiles más cortas porque su contexto de acceso cambia con mayor frecuencia.
Integre la renovación en el ciclo de vida del dispositivo
Utilice SCEP, una plataforma MDM u otra ruta de inscripción automatizada para renovar los certificados antes de que caduquen. La renovación manual funciona durante una fase piloto, pero se vuelve frágil en una infraestructura distribuida. Pruebe la renovación en laptops en modo de suspensión, dispositivos remotos, dispositivos reinstalados y dispositivos que no se hayan conectado a la red corporativa recientemente.
Monitoree los puntos de distribución de CRL desde las mismas rutas de red que utilizan RADIUS y los controladores. Verifique la accesibilidad, la validez de la firma, la identidad del emisor y el parámetro nextUpdate, no solo si una solicitud web devuelve contenido. Una CRL accesible pero caducada sigue siendo un control de revocación fallido.
Mantenga limpio el lado de RADIUS
Los certificados del servidor RADIUS necesitan validez vigente, una cadena de emisión confiable y un proceso de renovación que no dependa de una ventana de mantenimiento de último minuto. Revise los almacenes de confianza en los servidores, controladores y clientes administrados para que un certificado de CA antiguo no genere decisiones inconsistentes entre los diferentes sitios.
Documente el manual de procedimientos de revocación en un lenguaje que un ingeniero de guardia pueda seguir:
- Identificar la credencial: Registrar el usuario, el dispositivo, el número de serie del certificado y la CA emisora.
- Inhabilitar la identidad: Aplicar la acción de baja aprobada en el directorio o en recursos humanos.
- Revocar cuando sea necesario: Actualizar el estado de la CA y confirmar la publicación.
- Actualizar a las partes que confían: Forzar o programar la recuperación de CRL donde sea compatible.
- Probar la denegación: Intentar la autenticación con la credencial afectada y conservar el resultado.
Alinee los activadores de RR. HH. con los cambios en el directorio. Si la mesa de ayuda debe esperar por un ticket de PKI independiente, la red puede seguir confiando en una identidad que la organización ya ha marcado como inactiva. El aprovisionamiento y la renovación automatizados reducen ese desfase, mientras que una ruta manual documentada sigue siendo importante para dispositivos robados y sospechas de claves comprometidas.
Para el acceso de personal sin contraseña, revise cómo encajan estos controles con el despliegue de WPA-Enterprise, incluyendo el registro de certificados, la validación de RADIUS y la propiedad del proceso de baja.
Resolución de problemas comunes de revocación
La mayoría de los incidentes de CRL entran en tres categorías: el validador tiene información antigua, no puede encontrar el punto de publicación correcto o el almacén de revocación se ha vuelto difícil de operar. Diagnostique la ruta de decisión en lugar de comenzar por volver a emitir certificados.
Un caché local obsoleto
Es posible que un servidor RADIUS o controlador aún conserve una CRL anterior a la revocación. Confirme los campos thisUpdate y nextUpdate de la CRL, valide su firma contra la CA emisora e inspeccione la copia guardada en caché en el autenticador. Compare el número de serie presentado por el cliente con las entradas de la CRL recién publicada.
La solución inmediata es forzar una actualización de CRL si la plataforma lo admite, y luego repetir una prueba de autenticación con el certificado afectado. Si la caché sigue devolviendo datos antiguos, inspeccione el comportamiento del proxy, el almacenamiento en caché del punto de distribución y la política de actualización del validador.
Un punto de distribución faltante
Lea las extensiones CDP y AIA del certificado emitido. El CDP le indica a la parte de confianza dónde encontrar la información de revocación, mientras que el AIA puede ayudarle a identificar la información del emisor necesaria para la validación de la cadena. Confirme que la URL sea correcta, accesible desde la red RADIUS y que sirva una CRL firmada por el emisor esperado.
Si la plantilla de CA contiene la ubicación incorrecta, corrija la plantilla y emita certificados de reemplazo. Actualizar el punto final por sí solo no reparará los certificados que ya contienen un punto de distribución inutilizable.
Un almacén de revocación difícil de gestionar
Las entradas antiguas pueden complicar la administración y aumentar el trabajo de procesamiento. Depure las entradas únicamente bajo la política de retención de la CA y solo después de haber considerado la vida útil del certificado relevante y los requisitos de auditoría. Nunca elimine un número de serie solo porque el ticket del incidente está cerrado.
Los ejemplos de políticas del Reino Unido muestran por qué la "frescura" debe definirse localmente. Algunas autoridades del Reino Unido requieren actualizaciones diarias, mientras que la política nacional de la CVCA exige la publicación dentro de las 72 horas para un certificado revocado y establece un período máximo de emisión de 90 días. Trate estos puntos como líneas base de políticas, no como un permiso para aceptar datos empresariales desactualizados.
Una herramienta de análisis de certificados puede ayudar a inspeccionar los detalles del emisor, la validez, el CDP y la cadena. El comprobador de certificados SSL de Purple es una opción para examinar el estado del certificado, mientras que la aplicación basada en directorios puede evitar depender únicamente de una actualización retrasada de la CRL para la baja de usuarios.
Implementando todo esto esta semana
Convierta la revocación en una tarea asignada en lugar de un párrafo de política. Incluya estas acciones en la próxima ventana de cambios y asigne un responsable con nombre a cada una.
- Equipo de PKI, auditen las rutas de certificación: Realicen un inventario de cada plantilla de certificado de cliente WiFi, CA emisora, CDP y relación de confianza de RADIUS. Confirmen que cada punto de distribución sea accesible desde cada sitio de autenticación.
- Equipos de PKI y endpoints, definan un tiempo de vida defendible: Reduzcan los certificados de cliente WiFi a 12 meses o menos siempre que el proceso de renovación del dispositivo pueda soportarlo. Un tiempo de vida más corto reduce la dependencia de la revocación de emergencia, pero solo si la renovación está automatizada y probada.
- Equipo de endpoints, automaticen la renovación: Utilicen MDM o SCEP para registrar y renovar certificados sin intervención del usuario. Prueben el proceso después de restablecer un dispositivo, tras un periodo prolongado sin conexión y después de un cambio de usuario.
- Mesa de servicio y equipo de identidad, conecten la baja con la denegación de acceso: Aseguren que el estado inactivo de RR. HH. o de la mesa de servicio fluya directamente hacia el control de directorio utilizado por la autenticación WiFi. Verifiquen que una identidad deshabilitada no pueda establecer una nueva sesión 802.1X.
- Equipo de red, monitoreen las dependencias de revocación: Activen alertas para puntos de distribución no disponibles, CRL expiradas, firmas inválidas y comprobaciones de estado fallidas. Suscríbanse a las notificaciones de cambios en la CA para que una modificación en la publicación no afecte la autenticación de forma silenciosa.
Mida dos resultados durante el siguiente período de revisión. Primero, registre la latencia entre un evento de desactivación de directorio y la terminación o denegación de una nueva sesión de WiFi. Segundo, mida cuántas autenticaciones RADIUS completaron con éxito una verificación de CRL en lugar de continuar a través de una ruta de falla suave. Esas medidas le indican si el diseño funciona bajo presión, no solo si los certificados se ven correctos en una hoja de cálculo.
Si su equipo desea reducir la administración manual de PKI mientras mantiene el WiFi empresarial basado en la identidad, Purple puede proporcionar autenticación administrada de grado de certificado, decisiones de acceso conectadas al directorio y servicios RADIUS que admiten la verificación de revocación. Visite Purple para evaluar cómo su enfoque podría adaptarse a su flujo de trabajo de ciclo de vida de certificados y baja de WiFi.
