Un portátil de la empresa es robado en el tren. El servicio de soporte técnico deshabilita la cuenta de Active Directory del empleado, el dispositivo desaparece del registro de activos y todos asumen que el riesgo ha sido eliminado. Dos días después, el portátil sigue apareciendo en el SSID corporativo porque su suplicante 802.1X contiene un certificado de cliente que no ha caducado y nadie lo ha revocado.
Ese es el vacío que un proceso de lista de revocación de certificados está diseñado a cerrar. La caducidad del certificado establece el límite exterior de la confianza, mientras que la revocación interrumpe la confianza antes si una clave se ve comprometida, se pierde un dispositivo o un usuario se marcha. Para un administrador de WiFi empresarial, la pregunta clave no es si existen los certificados. Es si RADIUS y los controles de red asociados se enteran rápidamente de un certificado revocado y fallan de manera segura.
El acceso WiFi que no quería desaparecer
Un despliegue de WiFi basado en certificados suele parecer seguro desde fuera. El cliente utiliza EAP-TLS, el servicio RADIUS valida la cadena de certificados y las contraseñas compartidas no se distribuyen entre el personal. Pero ese diseño sigue dependiendo de un ciclo de vida que funcione. Emitir un certificado es solo el principio. También debe saber quién es su propietario, cuándo caduca y qué ocurre si el dispositivo o la clave privada ya no son de confianza.
En el ejemplo del portátil robado, eliminar la cuenta de Active Directory puede detener la autenticación futura del directorio, pero no necesariamente invalida 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, el portátil puede seguir presentando credenciales aparentemente válidas. La fecha notAfter date del certificado indica que sigue dentro de su vida útil programada. No dice que la organización emisora todavía quiera confiar en él.
Regla práctica: Trate la expiración del certificado y la revocación del certificado como controles separados. La expiración es una 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 expiración, que indica a las partes de confianza que ya no se debe confiar en esos certificados. Las directrices de la infraestructura de clave pública del Reino Unido también identifican las CRL como uno de los métodos de revocación comunes y esperan que los clientes comprueben si un certificado presentado aparece en la lista de la CA emisora.
Esto es importante en las redes WiFi porque las decisiones de autenticación se toman en el extremo de la red, a menudo a través de múltiples 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 exclusión por fallo mal diseñada puede provocar una interrupción del servicio 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 comprueba y la red deniega un certificado que ha sido revocado. El resto de esta guía analiza 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 un 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 amigable 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 expiración del certificado aún no ha llegado.
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 usuarias ya no deben confiar en dichos certificados. La firma es importante porque un servidor RADIUS u otro validador debe confirmar que la lista procede del emisor esperado y no ha sido alterada en tránsito. Una lista de bloqueo de texto sin formato mantenida por un administrador no ofrece 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 utilizando una clave privada asociada con la jerarquía de confianza emisora.
- La parte usuaria: 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.
Una CRL no suele ser 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 del mecanismo de revocación de certificados, pero el objeto operativo que se comprueba es la CRL firmada.
La parte usuaria 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 la propia caché de la parte usuaria.
Este ú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 por última vez el autenticador.
Cómo funciona una CRL entre bastidores
El ciclo de vida de una CRL sigue una cadena de eventos predecible. En primer lugar, la CA genera una lista base de acuerdo con su política de certificación. Firma la lista, añade los campos de publicación y validez, y la pone a disposición a través de un punto de distribución. Los certificados emitidos suelen hacer referencia a esas ubicaciones a través de la extensión CRL Distribution Points, lo que permite a un validador descubrir a dónde pertenece la información de estado.
Cuando un administrador revoca un certificado de 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 usuaria de forma inmediata. La siguiente CRL publicada debe contener la entrada, y cada servidor RADIUS o controlador debe recuperar una copia actualizada antes de poder tomar la decisión correcta.
Algunos entornos PKI también utilizan CRL delta. Una delta contiene los cambios realizados 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 gestionar la lista base, validar las firmas, realizar un seguimiento de 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 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 UK national certificate policy.
Otras políticas del Reino Unido utilizan diferentes expectativas de servicio. El 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.
En el momento de la autenticación, el servidor RADIUS comprueba el número de serie del certificado con su CRL disponible localmente. También comprueba si la CRL se encuentra dentro de su periodo 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. A continuación, el servidor almacena en caché el resultado de acuerdo con su implementación y el valor nextUpdate de la CRL.
Esto produce 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 distribución, la duración de la caché y la frecuencia de autenticación. Una política puede publicarse rápidamente, pero una caché RADIUS desconectada o desactualizada aún puede retrasar la aplicación.
CRL frente a OCSP y por qué es importante en WiFi
CRL y OCSP resuelven el mismo problema básico de formas diferentes. Una CRL proporciona al validador un lote firmado de números de serie revocados. OCSP pregunta a un respondedor autorizado por el estado de un único certificado en el momento en que se está comprobando.
Para un administrador de WiFi empresarial, la elección afecta a algo más que a la elegancia de la PKI. Cambia la forma en que se comporta un controlador a través de una WAN congestionada, lo que debe gestionar la infraestructura de CA y si un intento de autenticación puede completarse cuando un respondedor o un punto de distribución no están accesibles.
| 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 solicitudes de estado individuales, lo que evita descargas de la lista completa pero aumenta 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 caducada puede impedir una validación de estado fiable. Las cachés locales pueden seguir funcionando hasta su límite de frescura. | Un respondedor inaccesible afecta a la consulta de estado individual, y el comportamiento configurado de fallo permisivo (soft-fail) o fallo estricto (hard-fail) determina el resultado de la conexión WiFi. |
Un controlador que da servicio a un gran campus podría preferir una CRL almacenada en caché localmente porque puede comprobar muchos números de serie de certificados sin tener que enviar una solicitud individual para cada autenticación. Ese modelo funciona bien cuando los puntos de distribución son accesibles, se supervisan las actualizaciones y la política RADIUS gestiona una lista caducada de forma deliberada.
OCSP puede adaptarse a un diseño en el que 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 directo durante la autenticación. El grapado (stapling) puede trasladar la interacción del respondedor a otra parte en algunos protocolos, pero el diseño de WiFi sigue requiriendo una respuesta clara para los datos de estado no disponibles o desactualizados.
La guía del Reino Unido resulta ú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 comunes de revocación, mientras que la guía del sector judicial 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 la PKI.
Para los dispositivos de red gestionados con 802.1X, la CRL suele ser práctica para la validación periódica por lotes, especialmente cuando la infraestructura dispone de una distribución interna fiable. OCSP es preferible cuando es fundamental una mayor frescura del estado y la disponibilidad del respondedor se ha diseñado en consecuencia. Las redes de alta seguridad pueden ejecutar ambos, pero solo si el comportamiento de reserva está documentado y probado en lugar de simplemente 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 identidades activo 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 en un ticket que alguien debe traducir más tarde en una revocación de la CA.
Un flujo típico se estructura de la siguiente manera:
- El directorio registra el estado de la identidad. Se crea, modifica, suspende o desactiva una cuenta en Active Directory, Entra ID o Google Workspace.
- El servicio de identidad WiFi recibe el cambio. El servicio asocia el estado del directorio con la política de autenticación de la organización.
- La siguiente autenticación se evalúa conforme a ese estado. Una identidad desactivada deja de cumplir la regla de acceso, incluso si una credencial emitida previamente sigue dentro del periodo de validez de su certificado.
- La red deniega el acceso. La decisión de RADIUS impide que se autorice una nueva sesión 802.1X bajo la identidad inactiva.
Este modelo aborda una debilidad de 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 usuarias. La aplicación basada en directorios 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 a un usuario que se marcha.
Distinción operativa: Una CRL responde si un certificado está revocado. La autenticación dirigida por directorio puede responder si la identidad está autorizada actualmente para usar la red.
Purple proporciona controles de WiFi corporativos gestionados con RADIUS y basados en certificados 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 la identidad con la autenticación 802.1X sin tener que mantener por sí misma todos los componentes locales de RADIUS y revocación.
Esto no hace que el trabajo del ciclo de vida de la PKI desaparezca. Los certificados siguen requiriendo emisión, renovación, gestión de la cadena de confianza y comprobaciones de revocación cuando la arquitectura lo exige. Sin embargo, elimina un cuello de botella manual de la ruta de baja de usuarios. El servicio de soporte técnico 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.
Mejores prácticas operativas para WiFi empresarial
Un diseño de revocación fiable combina controles criptográficos con una disciplina operativa ordinaria. Comience con la vida útil del certificado. Para dispositivos de WiFi gestionados, una vida útil del certificado de 12 a 24 meses es una referencia operativa común en la guía de despliegue proporcionada, 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 deberían tener vidas útiles más cortas porque su contexto de acceso cambia con más frecuencia.
Integre la renovación en el ciclo de vida del dispositivo
Utilice SCEP, una plataforma MDM u otra vía 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 un entorno distribuido. Pruebe la renovación en portátiles en modo de suspensión, dispositivos remotos, dispositivos reconstruidos y dispositivos que no se hayan conectado recientemente a la red corporativa.
Supervise los puntos de distribución de CRL desde las mismas rutas de red utilizadas por RADIUS y los controladores. Compruebe la accesibilidad, la validez de la firma, la identidad del emisor y 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 una validez actual, una cadena de emisión de confianza y un proceso de renovación que no dependa de una ventana de mantenimiento de último minuto. Revise los almacenes de confianza en servidores, controladores y clientes gestionados para que un certificado de CA antiguo no genere decisiones inconsistentes en los distintos 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.
- Desactivar la identidad: Aplicar la acción de baja aprobada en el directorio o en el departamento de recursos humanos.
- Revocar cuando sea necesario: Actualizar el estado de la CA y confirmar la publicación.
- Actualizar las partes usuarias: 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 recursos humanos con los cambios en el directorio. Si el servicio de soporte técnico debe esperar a 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 mantener una vía manual documentada sigue siendo importante para dispositivos robados y sospechas de claves comprometidas.
Para el acceso del personal sin contraseña, revise cómo encajan estos controles con el despliegue de WPA-Enterprise, incluyendo la inscripción de certificados, la validación de RADIUS y la propiedad del proceso de baja de usuarios.
Resolución de problemas comunes de revocación
La mayoría de las incidencias de CRL se dividen 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 empezar por emitir de nuevo los certificados.
Una caché local obsoleta
Es posible que un servidor o controlador RADIUS aún conserve una CRL anterior a la revocación. Confirme los campos thisUpdate y nextUpdate de la CRL, valide su firma frente a 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 la 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 que falta
Lea las extensiones CDP y AIA del certificado emitido. El CDP indica a la parte que confía dónde encontrar la información de revocación, mientras que el AIA puede ayudarla a identificar la información del emisor necesaria para la validación de la cadena. Confirme que la URL es correcta, accesible desde la red RADIUS y que ofrece una CRL firmada por el emisor esperado.
Si la plantilla de la CA contiene la ubicación incorrecta, corrija la plantilla y emita certificados de reemplazo. Actualizar el endpoint 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 manejar
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 correspondiente y los requisitos de auditoría. Nunca elimine un número de serie solo porque el ticket de incidencia esté cerrado.
Los ejemplos de políticas del Reino Unido muestran por qué "fresco" debe definirse localmente. Algunas autoridades del Reino Unido exigen 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 esto como líneas base de políticas, no como un permiso para aceptar datos empresariales obsoletos.
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 de los certificados, mientras que la aplicación de políticas basada en directorios puede evitar depender únicamente de una actualización retrasada de la CRL para la baja de usuarios.
Poniéndolo todo en práctica esta semana
Convierta la revocación en una tarea asignada en lugar de un mero párrafo de política. Incluya estas acciones en la próxima ventana de cambios y asigne a cada una de ellas un responsable específico.
- Equipo de PKI, auditad las rutas de los certificados: Inventariad cada plantilla de certificado de cliente WiFi, CA emisora, CDP y relación de confianza de RADIUS. Confirmad que cada punto de distribución sea accesible desde cada sitio de autenticación.
- Equipos de PKI y terminales, estableced un tiempo de vida justificable: Reducid el tiempo de vida de 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 terminales, automatizad la renovación: Utilizad MDM o SCEP para registrar y renovar certificados sin la intervención del usuario. Probad el proceso tras la restauración de un dispositivo, un periodo largo sin conexión y un cambio de usuario.
- Servicio de asistencia y equipo de identidad, conectad la baja al bloqueo de acceso: Haced que el estado inactivo de RR. HH. o del servicio de asistencia influya directamente en el control de directorio utilizado por la autenticación WiFi. Verificad que una identidad deshabilitada no pueda establecer una nueva sesión 802.1X.
- Equipo de red, monitorizad las dependencias de revocación: Alertad sobre puntos de distribución no disponibles, CRL caducadas, firmas no válidas y comprobaciones de estado fallidas. Suscribíos a las notificaciones de cambios de la CA para que un cambio en la publicación no degrade la autenticación de forma inadvertida.
Mida dos resultados durante el siguiente periodo de revisión. En primer lugar, registre la latencia entre un evento de desactivación de directorio y la finalización o denegación de una nueva sesión de WiFi. En segundo lugar, mida cuántas autenticaciones RADIUS completaron una comprobación CRL con éxito en lugar de continuar a través de una ruta de fallo leve. 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 manteniendo al mismo tiempo un WiFi empresarial basado en la identidad, Purple puede proporcionar autenticación gestionada de nivel de certificado, decisiones de acceso conectadas al directorio y servicios RADIUS compatibles con la comprobación de revocación. Visite Purple para evaluar cómo encaja su enfoque en su flujo de trabajo de ciclo de vida de certificados y bajas de WiFi.
