¿Qué es una lista de revocación de certificados (CRL)?

Por qué es importante la revocación de certificados

Los certificados digitales se utilizan para generar confianza en las transacciones en línea. Una vez que se ha establecido la confianza y se ha confirmado la identidad de la otra parte, solo entonces es posible crear un canal de comunicación autenticado y cifrado. En conjunto, estas propiedades constituyen la base de la Infraestructura de Clave Pública (PKI), que sustenta prácticamente todas las interacciones digitales seguras.

Cada certificado se emite con un periodo de validez limitado, que puede oscilar entre unas horas y varios años, dependiendo de la política de la autoridad de certificación (CA) emisora. Sin embargo, cabe mencionar que, a partir de marzo de 2029, el periodo máximo de validez de un certificado digital de confianza pública será de solo 47 días. Un certificado deja de ser válido en el momento en que se sabe que su clave privada se ha visto comprometida, independientemente del tiempo que le quede de validez. El plazo de validez deja de tener relevancia una vez que la base de confianza deja de ser válida.

Una clave privada puede verse comprometida debido a una brecha de seguridad o a una configuración incorrecta. Un empleado que posea un certificado de cliente puede abandonar la organización. La propia autoridad de certificación (CA) puede verse obligada a retirar la confianza de los certificados que ha emitido. Sin un mecanismo fiable para invalidar los certificados antes de su fecha de caducidad natural, las organizaciones quedan expuestas a ataques que aprovechan credenciales que la PKI ya no considera fiables.

La revocación de certificados es ese mecanismo, y la lista de revocación de certificados (CRL) es su implementación más antigua y más extendida.

¿Qué es la revocación de certificados?

La revocación de un certificado consiste en invalidar un certificado digital antes de su fecha de caducidad prevista. Se trata de una operación fundamental dentro de la PKI, que garantiza que los certificados que ya no se consideran fiables no puedan utilizarse para autenticar identidades ni cifrar comunicaciones.

Durante el período de validez de un certificado, el titular del mismo o la autoridad de certificación (CA) que lo haya emitido pueden determinar que ya no es fiable. Cuando esto ocurre, es necesario revocar el certificado no fiable e informar a las partes que confían en él (navegadores, servidores, aplicaciones, etc.). El mecanismo principal para comunicar este estado de revocación es la lista de revocación de certificados.

En una PKI bien gestionada, la capacidad de revocar la confianza es fundamental. Se trata del control que garantiza la integridad de la cadena de confianza cuando las condiciones del mundo real cambian más rápido de lo que permiten los períodos de validez de los certificados.

¿Qué es una lista de certificados revocados?

Una lista de revocación de certificados puede definirse con distintos niveles de detalle:

En términos sencillos, una CRL es una lista de números de serie de certificados revocados publicada por una autoridad de certificación.

El Consejo de Seguridad de CA lo define como «un archivo firmado digitalmente que contiene una lista de certificados que han sido revocados y aún no han caducado».

La RFC 5280, el estándar de Internet que regula la infraestructura de clave pública (PKI) X.509, ofrece la definición formal: una CRL es «una estructura de datos firmada y provista de marca de tiempo que una autoridad de certificación (CA) o un emisor de CRL publica periódicamente para comunicar el estado de revocación de los certificados digitales afectados».

El formato CRL se define en la norma X.509 y se especifica con detalle en el RFC 5280. Cada entrada de una CRL incluye el número de serie del certificado revocado y la fecha de revocación. Las entradas pueden incluir, de forma opcional, un plazo de validez de la revocación y un código de motivo que explique por qué se revocó el certificado.

Las CA publican las CRL con una periodicidad determinada (cada hora, cada día o cada semana, en función de la política y la tolerancia al riesgo). Un certificado revocado puede tener uno de estos dos estados en una CRL:

• Revocado: La revocación es permanente e irreversible. El certificado nunca volverá a considerarse fiable.
• En espera: La revocación es temporal. La confianza en el certificado queda suspendida, pero podrá restablecerse si cambian las circunstancias.

Cómo funcionan las listas de revocación de certificados

La función de la autoridad de certificación

Las CRL son emitidas y mantenidas por la autoridad de certificación que emitió originalmente los certificados. La CA firma digitalmente cada CRL que publica, y esta firma es fundamental: demuestra la autenticidad del archivo y evita su manipulación.

Cualquier parte que confíe en la lista y descargue una CRL puede verificar la firma de la CA para confirmar que la lista no ha sido alterada durante la transmisión. En la mayoría de las implementaciones, la CRL está firmada por la misma entidad que emitió los certificados. Sin embargo, en algunos casos, una CA designará a otro firmante autorizado para que emita CRL en su nombre, una configuración admitida por el estándar X.509 pero que, en la práctica, se utiliza con poca frecuencia.

Estructura y contenido del CRL

Según el RFC 5280, una CRL contiene los siguientes campos clave:

• Nombre del emisor: el nombre distintivo de la CA que emitió la CRL
• En esta actualización: la fecha y la hora de publicación de la CRL
• Próxima actualización: la fecha y la hora en las que se publicará la próxima CRL (es decir, la fecha de caducidad de la CRL).
• Lista de certificados revocados: una secuencia de entradas, cada una de las cuales contiene:
  • El número de serie del certificado revocado
  • La fecha de revocación
  • Extensiones opcionales, incluidos los códigos de motivo de revocación
• Firma digital de la CA: autentica la CRL en su totalidad

Según el RFC 5280, los certificados caducados suelen eliminarse de la CRL una vez transcurrido su periodo de validez original, ya que dejarían de ser aceptados independientemente de su estado de revocación. No obstante, la autoridad de certificación (CA) puede configurar este comportamiento.

Entradas de la LCR y códigos de motivo de revocación

La norma X.509 define varios códigos de motivo que una autoridad de certificación (CA) puede adjuntar a una entrada de la lista de certificados revocados (CRL). Estos códigos proporcionan información sobre el motivo por el que se revocó un certificado, lo cual puede resultar importante para el análisis forense y para determinar si se debe seguir considerando fiable el contenido firmado antes de la fecha de revocación.

Los códigos de motivo estándar incluyen:

• Compromiso de la clave: La clave privada del certificado se ha visto comprometida. No se debe confiar en el contenido firmado anteriormente con esta clave.
• Compromiso de la CA: La clave privada de la propia CA emisora se ha visto comprometida, lo que pone en duda la validez de todos los certificados que ha emitido.
• Cambio de afiliación: La afiliación organizativa del titular del certificado ha cambiado (por ejemplo, se ha vendido una filial).
• Derogado: El certificado ha sido sustituido por otro más reciente.
• Cese de la actividad: La entidad ha cesado su actividad, o el dominio o el servidor asociado al certificado ya no es propiedad del titular del certificado.
• Privilegio retirado: La autorización del titular del certificado ha cambiado (por ejemplo, un empleado ha dejado la organización). Las firmas realizadas antes de la revocación pueden seguir considerándose válidas, ya que el titular estaba autorizado en el momento de la firma.
• Suspensión del certificado: El certificado está suspendido temporalmente. Se puede restablecer mediante una entrada «removeFromCRL» en una LCR delta posterior.

Los certificados también pueden ser revocados por haber sido emitidos indebidamente, obtenidos mediante fraude o emitidos infringiendo la declaración de prácticas de certificación de la CA.

Cómo comprueban las listas de certificados revocados (CRL) los navegadores y las aplicaciones

Cuando un usuario se conecta a un sitio web o servicio protegido con un certificado digital, la parte que confía en él (navegador, aplicación o sistema operativo) lleva a cabo una serie de pasos de validación. La comprobación de la lista CRL es una parte fundamental de este proceso:

1. Puntos de distribución de CRL: En el momento de su creación, los certificados contienen una extensión denominada «Puntos de distribución de CRL» (CDP) que enumera una o varias URL en las que se puede obtener la CRL de la CA emisora siempre que sea necesario validarla.
2. TLS : Al iniciar una TLS , el navegador establece la conexión y recibe el certificado del servidor.
3. Recuperación y comprobación de la CRL: El navegador obtiene la CRL de la URL especificada en la extensión CDP del certificado y comprueba si el número de serie del certificado figura en la lista.
4. Decisión: Si el certificado no figura en la CRL, la conexión sigue adelante. Si aparece en la lista, el navegador avisa al usuario de que el certificado ha sido revocado y de que no se debe confiar en la conexión.

Esta validación es un paso esencial en toda transacción basada en una PKI. Sin embargo, plantea un problema práctico: si el navegador no tiene almacenada en caché una copia reciente de la CRL, deberá descargar la CRL completa durante la conexión inicial, lo que aumenta la latencia. Para mitigar este problema, los navegadores almacenan las CRL en caché; no obstante, este almacenamiento crea un intervalo de tiempo durante el cual un certificado revocado recientemente seguirá siendo aceptado.

Tipos de listas de revocación de certificados

CRL completas (combinadas)

Una CRL completa, a veces denominada «CRL combinada», contiene todos los certificados revocados por la CA emisora que aún no han caducado. Cada vez que la CA publica una CRL actualizada, elabora la lista completa desde cero.

Las CRL completas son fáciles de implementar y cuentan con una amplia compatibilidad en todos los clientes de PKI. Su formato es fácil de auditar. Cada parte que confía en ellas y que descarga la CRL obtiene una visión completa del estado de revocación. Sin embargo, en el caso de las CA que han revocado un gran número de certificados, las CRL completas pueden alcanzar un tamaño extremadamente grande, lo que consume un ancho de banda considerable y aumenta los tiempos de descarga. Por ello, resultan más adecuadas para implementaciones de PKI más pequeñas, en las que el número total de certificados revocados sigue siendo manejable.

Listas de certificados revocados (CRL) particionadas

Las CRL particionadas distribuyen la información de revocación en varios archivos CRL independientes. Esta opción permite distribuir los números de serie de los certificados revocados entre un número predeterminado de particiones. A los certificados se les asigna, en el momento de su emisión, un número de partición de la CRL generado aleatoriamente. De este modo, las partes que confían en los certificados pueden identificar la partición correcta a través de la extensión CDP y solicitar la partición correspondiente.

La ventaja es la escalabilidad. En lugar de descargar una única CRL de gran tamaño, la entidad que confía descarga únicamente la partición relevante para el certificado que está validando. Este enfoque reduce el consumo de ancho de banda, agiliza la generación de la CRL por parte de la CA y permite el almacenamiento en caché independiente de cada partición. Sin embargo, requiere que tanto la entidad que confía como las CRL particionadas sean el enfoque estándar para las PKI de grandes empresas que gestionan decenas de miles de certificados o más.

CRL de Delta

Una CRL delta contiene únicamente los cambios (añadidos y eliminaciones) que se han producido desde la publicación de la última CRL completa (base). En lugar de volver a descargar la lista completa, una parte que confía en la lista y que ya dispone de la CRL base solo tiene que descargar la CRL delta para actualizar sus datos de revocación.

Las CRL delta reducen considerablemente los requisitos de ancho de banda, especialmente en entornos con CRL base de gran tamaño y un número relativamente reducido de revocaciones entre ciclos de publicación. Sin embargo, dependen en gran medida de la CRL base, y la verificación puede fallar incluso si la CRL delta está disponible.

Ciclo de vida de los certificados CRL: actualizaciones, caducidad y frecuencia

Frecuencia de actualización y el campo «próxima actualización»

Cada CRL incluye una marca de tiempo de «próxima actualización» que indica a las partes que confían en ella cuándo pueden esperar la próxima versión. Las autoridades de certificación publican nuevas CRL según un calendario definido en su declaración de prácticas de certificación:

• Listas CRL de las CA raíz: Se publican cada pocos meses o años. Las claves privadas de las CA raíz se almacenan fuera de línea, por lo que la generación de las listas CRL requiere acceso físico a la clave de firma.
• Emisión de listas CRL de CA (subordinadas): Se publican cada pocas horas o cada pocos días. Estas CA están en línea y pueden automatizar la generación de listas CRL con mayor facilidad.

La frecuencia depende en gran medida de la política de la CA. Una CA raíz fuera de línea (una autoridad de certificación que se mantiene fuera de línea por motivos de seguridad) puede generar una nueva CRL cada año, o incluso con menos frecuencia. Por el contrario, una CA emisora en un entorno de alta seguridad puede generar una nueva CRL cada hora, o incluso con mayor frecuencia.

Los administradores también pueden activar la publicación manual de la CRL inmediatamente después de un evento de revocación de alta prioridad, lo que garantiza que la revocación se propague sin tener que esperar a la siguiente actualización programada.

¿Qué ocurre cuando caduca una CRL?

Si una CRL alcanza la fecha de su «próxima actualización» y no se ha publicado ninguna nueva, o si ya no es posible acceder al punto final de la CRL, las consecuencias son graves: todos los certificados emitidos por esa CA dejan de ser válidos de forma inmediata. Las partes que confían en dichos certificados y que no pueden obtener una CRL válida y actualizada no tienen forma de confirmar si un certificado ha sido revocado, por lo que muchas de ellas rechazarán el certificado sin más.

Este comportamiento (fail-closed) es la configuración predeterminada más segura. Algunas implementaciones ofrecen una opción «fail-open» que acepta certificados incluso cuando no se puede recuperar una CRL actual, pero esto sacrifica la seguridad en aras de la disponibilidad y no se recomienda para entornos de producción.

La caducidad de las listas CRL es una de las causas más habituales de interrupciones inesperadas en la PKI, por lo que la supervisión de las listas CRL constituye un requisito operativo fundamental.

Cómo consultar una lista de certificados revocados

Los certificados incluyen una extensión de puntos de distribución de listas de certificados revocados (CDP) que contiene las URL desde las que se puede descargar la lista de certificados revocados correspondiente. Existen varios métodos habituales para comprobar una lista de certificados revocados:

• Windows: La herramienta command «certutil» permite descargar, analizar y mostrar el contenido de las listas CRL.
• macOS y Linux: OpenSSL ofrece comandos para recuperar y descodificar listas CRL a partir de direcciones URL de CDP.
• Navegadores: Los navegadores modernos realizan automáticamente la validación CRL (u OCSP) durante TLS , y avisan a los usuarios si se ha revocado un certificado.

En el Centro Keyfactor se puede consultar una guía específica sobre cómo comprobar las listas CRL mediante herramientas y comandos concretos.

Por qué son importantes los CRL

Sin un sistema de revocación de certificados que funcione correctamente, la PKI pierde su capacidad para adaptarse a los cambios en las condiciones de confianza. Los riesgos de operar sin una gestión eficaz de las CRL son considerables:

• Validación de la confianza: las listas CRL son el mecanismo que confirma que un certificado sigue gozando de la confianza de la CA que lo emitió. Sin ellas, las partes que confían en el certificado no tienen forma de distinguir un certificado válido de uno que haya sido comprometido.
• Revocación con efecto retroactivo: las entradas de la CRL incluyen la fecha de revocación, lo que permite a las organizaciones determinar cuándo se retiró la confianza. Esto es esencial para las investigaciones forenses, en las que conocer el momento exacto en que un certificado dejó de ser de confianza afecta a la validez de todo lo firmado con él.
• Fugas de datos: un certificado comprometido que sigue siendo considerado de confianza permite que se produzcan ataques de tipo «hombre en el medio» (MITM). Los atacantes pueden interceptar tráfico cifrado que contenga números de la Seguridad Social, credenciales de cuentas bancarias, datos de tarjetas de crédito e información sanitaria protegida.
• Robo de identidad y suplantación de identidad: los certificados comprometidos que no se hayan revocado pueden utilizarse para el robo de credenciales y en campañas de suplantación de correo electrónico empresarial (BEC), lo que permite a los atacantes suplantar la identidad de entidades de confianza.
• Pérdidas económicas: Las credenciales bancarias, los datos de las tarjetas de pago y los tokens de autenticación corporativos robados pueden obtenerse a través de conexiones que utilizan certificados que deberían haber sido revocados.
• Distribución de malware: TLS de firma de código o TLS comprometidos pueden utilizarse para instalar keyloggers, desplegar ransomware o incorporar dispositivos a botnets de DDoS, todo ello sin que los sistemas de la víctima lo detecten como algo sospechoso.

Solicitar una demostración

Distribución y alojamiento de CRL

Puntos de distribución de CRL (CDP)

Un punto de distribución de CRL (CRL Distribution Point) es la ubicación (normalmente una URL en un servidor de directorio LDAP o en un servidor web) en la que una CA publica sus CRL. La URL del CDP se incluye en todos los certificados que emite la CA, a través de la extensión CDP, para que las partes que confían en ellos sepan dónde obtener la CRL.

Los CDP deben estar accesibles en todo momento. Si una parte que confía en ellos no puede ponerse en contacto con el CDP para obtener una CRL actualizada, la validación del certificado fallará. Por este motivo, no se recomienda el uso de CDP basados en LDAP para las PKI de acceso público. Los CDP en servidores web (HTTP/HTTPS) son el estándar para la mayoría de las implementaciones.

Estrategias de alojamiento web

Las organizaciones disponen de varias opciones para alojar los puntos finales de CRL, cada una de ellas con diferentes características de disponibilidad y escalabilidad:

• Servidores web: el método más sencillo. Un servidor HTTP estándar aloja los archivos CRL, y los certificados hacen referencia a su URL como CDP. Adecuado para PKI de tamaño pequeño a mediano.
• Redes de distribución de contenidos (CDN): distribuyen archivos CRL a través de nodos periféricos repartidos geográficamente, lo que garantiza una alta disponibilidad y una baja latencia en las implementaciones globales.
• Grupos de servidores web: varios servidores web conectados a un equilibrador de carga proporcionan redundancia y tolerancia a fallos.
• Directorios LDAP: Se han utilizado tradicionalmente en entornos empresariales de Active Directory. Su uso ha quedado prácticamente obsoleto para nuevas implementaciones, en favor de la distribución basada en HTTP.

Aspectos a tener en cuenta sobre el almacenamiento en caché

Las partes que confían en las CRL las almacenan en caché de forma local hasta que caduque la marca de tiempo de la «próxima actualización». Aunque el almacenamiento en caché reduce la carga en los puntos finales del CDP y mejora la latencia de la conexión, introduce un intervalo de tiempo durante el cual un certificado revocado recientemente aún puede ser aceptado por un cliente que utilice una CRL almacenada en caché (y que ya está desactualizada). Esta disyuntiva entre la actualidad y el rendimiento es inherente a la revocación basada en CRL y debe tenerse en cuenta a la hora de decidir la frecuencia de publicación de las CRL.

Las descargas de CRL de gran tamaño también aumentan la latencia durante la conexión inicial, cuando no existe ninguna copia en caché, lo que puede afectar a la experiencia del usuario y al rendimiento de la aplicación.

Seguimiento y gestión de la CRL

Por qué es fundamental la monitorización de la CRL

Una gestión inadecuada puede acarrear graves consecuencias. Si tu CRL ha caducado o no es accesible, todos tus certificados quedarán inmediatamente inutilizables. Una sola omisión en la publicación de la CRL o un CDP inaccesible puede provocar una interrupción generalizada que afecte a todos los servicios que dependan de los certificados de esa CA.

Qué hay que supervisar

Un seguimiento eficaz de la CRL debería abarcar:

• Capacidad de respuesta de los puntos finales: Comprueba que se pueda acceder a todas las URL de CDP y que devuelvan datos CRL válidos.
• Próximas fechas de caducidad: avisar cuando se acerque la fecha de «próxima actualización» de una CRL y aún no se haya publicado ninguna sustitución.
• Listas de certificados revocados (CRL) caducadas: Marca inmediatamente cualquier CRL que haya superado la fecha de su «próxima actualización» sin haber sido sustituida.

Generación y automatización de CRL

La generación de CRL puede ser manual (activada a petición por un administrador) o automática mediante varios mecanismos:

• Procesos de fondo del servicio de actualización de CRL: procesos en segundo plano que generan y publican listas CRL según una programación configurada.
• Generación activada por eventos: publicación automática de la CRL inmediatamente después de la revocación de un certificado.
• Tareas cron de Unix: tareas programadas que activan la generación de CRL a intervalos fijos.

Como buena práctica, las CA de nueva creación deberían publicar una CRL vacía inmediatamente después de su creación. De este modo se garantiza que las partes que confían en ellas puedan validar los certificados de la CA desde el primer día, incluso antes de que se haya producido ninguna revocación.

Retos y limitaciones habituales de las CRL

Aunque las CRL siguen siendo un mecanismo fundamental de revocación en la PKI, plantean una serie de dificultades operativas bien conocidas:

• Escalabilidad: Los archivos CRL aumentan de tamaño con cada revocación. En el caso de las autoridades de certificación (CA) de gran tamaño, es posible que las CRL contengan millones de entradas, por lo que la descarga y el análisis de estos archivos consumen una gran cantidad de recursos. Esto resulta especialmente problemático para dispositivos con recursos limitados, como los smartphones y IoT , que cuentan con memoria y potencia de procesamiento limitadas.
• Latencia: Para comprobar el estado de un único certificado, es necesario descargar y analizar toda la CRL. A diferencia del protocolo OCSP, que devuelve una respuesta específica para un certificado, las CRL no permiten consultar entradas individuales.
• Sobrecarga de conexión: si no hay ninguna copia reciente de la CRL almacenada en caché, la parte que confía debe recuperar la CRL durante el TLS inicial, lo que añade una latencia apreciable al establecimiento de la conexión.
• Ventanas de almacenamiento en caché: El intervalo entre las publicaciones de las CRL crea una ventana durante la cual un certificado revocado puede seguir siendo aceptado por las partes que confían en él al utilizar una copia almacenada en caché. Unos intervalos de publicación más cortos reducen esta ventana, pero aumentan la carga de la CA y de la red.

Buenas prácticas de CRL

Para gestionar eficazmente las CRL es necesario contar con una planificación minuciosa y disciplina operativa. Las siguientes prácticas abordan los modos de fallo más habituales:

1. Establezca las frecuencias de actualización en función del riesgo. Las listas CRL de las CA emisoras deben publicarse cada 24 a 72 horas. Las listas CRL de las CA raíz, en las que las claves de firma se conservan fuera de línea, pueden publicarse cada 3 a 12 meses. Adapte la frecuencia al nivel de sensibilidad de los certificados que se emitan.
2. Supervisa de forma proactiva los puntos finales de las CRL. No esperes a que se produzca una interrupción del servicio para descubrir que no se puede acceder a un CDP o que una CRL ha caducado. Implementa un sistema de supervisión automatizado que compruebe la disponibilidad de los puntos finales y avise cuando se acerque la fecha de caducidad.
3. Automatiza la generación de CRL. La publicación manual de CRL es propensa a errores y no resulta escalable. Utiliza tareas programadas, «service workers» o automatización activada por eventos para garantizar que las CRL se publiquen de forma fiable y puntual.
4. Planifica la alta disponibilidad. Los puntos finales de la CRL son parte de la infraestructura crítica. Utiliza redes de distribución de contenido (CDN), granjas de servidores web o servidores web con equilibrio de carga para garantizar que se pueda acceder a las URL del CDP incluso en caso de fallos en los servidores o picos de tráfico.
5. Utiliza listas CRL particionadas a gran escala. Si tu PKI emite grandes volúmenes de certificados, utiliza listas CRL particionadas para que los archivos CRL individuales mantengan un tamaño manejable.
6. Ajustar la política de CRL a los requisitos de seguridad. El equilibrio entre la actualidad de las CRL y la carga operativa debe ser una decisión política explícita, basada en la tolerancia al riesgo de la organización y en la sensibilidad de los sistemas protegidos por la PKI.
7. Tenga en cuenta el comportamiento del almacenamiento en caché. Tenga en cuenta que las partes que confían en las listas de revocación (CRL) las almacenarán en caché hasta la marca de tiempo de la «próxima actualización». Tenga en cuenta este periodo de almacenamiento en caché a la hora de elaborar los planes de respuesta ante incidentes y de tomar decisiones sobre la urgencia de la revocación.

Cómo Keyfactor ayudarte Keyfactor

La gestión de las listas de certificados revocados (CRL) y la revocación de certificados a gran escala requiere tanto una infraestructura PKI eficaz como una visión centralizada del estado de las revocaciones en todo el entorno.

EJBCA Keyfactor es una plataforma de CA de nivel empresarial con todas las funciones que ofrece un control total sobre la generación y distribución de CRL. EJBCA la publicación manual y automatizada de listas CRL, listas CRL particionadas y la generación de listas CRL delta, así como ajustes configurables del punto de distribución de listas CRL (CDP) y frecuencias de publicación flexibles. Como plataforma de CA responsable de la emisión y revocación de certificados, EJBCA los equipos de PKI un control directo sobre el ciclo de vida de la revocación, desde la emisión hasta la publicación de las listas CRL.

Keyfactor Command proporciona una capa centralizada de visibilidad y automatización que abarca todas las autoridades de certificación (CA) del entorno. Command los puntos finales de las listas de revocación de certificados (CRL) y del protocolo OCSP, envía alertas configurables por correo electrónico cuando las CRL están a punto de caducar y ofrece supervisión en tiempo real del estado de revocación en todo el inventario de certificados. Para las organizaciones que gestionan certificados de varias CA, Command los datos de revocación de todas las CA en un panel de control unificado, lo que elimina el riesgo de que pase desapercibida una CRL caducada o inaccesible.

Juntas, EJBCA Keyfactor Command una gestión integral del ciclo de vida de los certificados: detección, supervisión, emisión, renovación y revocación, todo ello a través de una plataforma unificada.