Los riesgos ocultos de las listas de revocación de certificados (CRL) vencidas

Respuesta rápida: Una Lista de Revocación de Certificados (CRL, por sus siglas en inglés) es una lista firmada y publicada que una Autoridad de Certificación utiliza para indicar a los sistemas que confían en ella qué certificados ya no son de confianza, aunque aún no hayan caducado. Los sistemas que verifican los certificados con una CRL están protegidos contra certificados comprometidos o emitidos incorrectamente. Los sistemas que confían en una CRL caducada, inaccesible o desactualizada no lo están, ya que no tienen una forma fiable de saber si un certificado ya ha sido revocado.

Los certificados digitales son los documentos de identidad de internet. Permiten que un navegador o servidor confirme que el sitio web, la API o la aplicación al otro lado de la conexión es quien dice ser, y cada certificado tiene una fecha de caducidad fija que limita su validez. Sin embargo, los certificados no siempre llegan a su fecha de caducidad sin problemas. Una clave privada puede filtrarse, un dominio puede cambiar de propietario o una Autoridad de Certificación puede descubrir que emitió un certificado por error. Cuando esto sucede, el certificado debe ser revocado anticipadamente, y el mecanismo para ello es la Lista de Revocación de Certificados.

Resumen Ejecutivo

Una lista de revocación de certificados (CRL) caducada o inaccesible invalida el único mecanismo que tienen los sistemas para rechazar un certificado comprometido o emitido incorrectamente antes de su fecha de caducidad prevista. El riesgo se agrava: Let's Encrypt cerró su servicio OCSP el 6 de agosto de 2025, consolidando casi por completo la comprobación de revocación en las CRL, y la encuesta Trust Pulse de DigiCert de julio de 2025 reveló que el 45 % de las organizaciones sufrieron interrupciones del servicio relacionadas con certificados durante el último año, y el 37.5 % de estas se debieron a un certificado caducado (Fuente: Encuesta Trust Pulse de DigiCert, julio de 2025). Las identidades de máquina que requieren certificados ahora superan a las identidades humanas en una proporción de 109 a 1 (Fuente: Informe de Palo Alto Networks sobre el panorama de la seguridad de la identidad de 2026), lo que significa que la carga de trabajo de renovación y monitoreo detrás de cada punto final de CRL y CDP sigue creciendo incluso a medida que el CA/Browser Forum reduce gradualmente la validez máxima de los certificados TLS públicos a 200 días en marzo de 2026, 100 días en marzo de 2027 y certificados TLS de 47 días para marzo de 2029 (Fuente: votación del CA/Browser Forum, vía Sectigo). El seguimiento manual no puede detectar una CRL obsoleta a esa escala. El descubrimiento automatizado de certificados y la automatización de certificados cierran esa brecha, y la misma disciplina de inventario que mantiene saludables las CRL también sustenta la agilidad criptográfica y la preparación de PQC : un CBOM en vivo brinda a los equipos de seguridad y cumplimiento la misma visibilidad continua.

Ir a: Matriz de riesgos | Impacto por equipo | Qué hacer a continuación | Cómo puede ayudar la consultoría en cifrado | Preguntas frecuentes

Puntos Clave

• Una CRL es una lista firmada, publicada por una CA, que enumera todos los certificados que han sido invalidados antes de su fecha de vencimiento prevista.
• Una lista de revocación de certificados (CRL) caducada, sin conexión o mal configurada implica que los sistemas que dependen de ella pueden seguir confiando en un certificado que ya ha sido revocado, o rechazar certificados válidos por error.
• Let's Encrypt desactivó su servicio OCSP el 6 de agosto de 2025 y ahora publica el estado de revocación únicamente a través de las CRL, una dirección hacia la que el CA/Browser Forum ha estado impulsando a toda la industria.
• La propuesta SC-081v3 del Foro CA/Browser reduce la validez máxima de los certificados TLS a 47 días para marzo de 2029, lo que disminuye el período de exposición, pero no elimina la necesidad de comprobar la revocación de los certificados estándar.
• La monitorización continua, como las comprobaciones de estado de la infraestructura de clave pública (PKI) en CertSecure Manager, puede detectar un fallo en un punto final de CRL o CDP/AIA antes de que provoque una interrupción del servicio o un incumplimiento normativo.

Cómo funciona una lista de revocación de certificados

Una CRL existe porque la fecha de caducidad de un certificado solo indica cuándo dejará de ser válido, no si ya debe considerarse inactivo. La infraestructura de clave pública (PKI) necesita un segundo canal para ello, y la CRL es la más antigua y aún la más utilizada. Funciona como una lista negra: la CA la mantiene, la actualiza cada vez que se revoca un certificado y la firma para que cualquiera que la descargue pueda confirmar que no ha sido manipulada.

Pasos necesarios para crear y publicar una CRL

• Solicitud de revocación:

  El titular del certificado, o alguien que actúe en su nombre, notifica a la autoridad de certificación emisora ​​que es necesario revocarlo. Entre los motivos más comunes se incluyen la filtración de claves, el uso indebido o que el titular del certificado ya no controle el dominio. La solicitud suele incluir el número de serie del certificado y el motivo de la revocación.

• Verificación:

  La CA comprueba que la solicitud de revocación sea legítima. Una vez confirmada, marca el certificado como revocado en sus registros internos.

• Actualización de la lista y firmas:

  La CA agrega el número de serie del certificado a su CRL y firma la lista actualizada con su clave privada, de modo que las partes que confían en ella puedan verificar que la propia CRL no ha sido alterada.

• Publicación:

  La CRL firmada se publica en una ubicación a la que pueden acceder las partes que confían en ella, generalmente un servidor web al que se hace referencia en el Punto de Distribución de CRL (CDP) del certificado, y a veces a través de LDAP.

• Distribución:

  Los navegadores, servidores y otros programas que dependen de este certificado descargan periódicamente la lista de revocación de certificados (CRL) actual desde la ubicación a la que apunta el certificado.

• Uso:

  Cuando un sistema receptor encuentra un certificado, compara el número de serie del certificado con la lista de revocación de certificados (CRL) descargada. Si coincide, el certificado se considera revocado, independientemente de su fecha de caducidad.

Cómo comprobar el estado de revocación de un certificado

Cada certificado de confianza pública apunta a la CRL que lo cubre, a través de un campo llamado Punto de Distribución de CRL. Puede encontrar este campo usted mismo, ya sea abriendo directamente un certificado descargado o inspeccionando uno presentado por un sitio web.

Para comprobar el certificado de un sitio web, haga clic en el icono del candado que aparece junto a la barra de direcciones y, a continuación, siga estos pasos:

1. Haz clic en "La conexión es segura" y, a continuación, abre los detalles del certificado.
2. Desplácese hasta la sección Puntos de distribución de CRL (CDP) .
3. Tenga en cuenta la URL o las URL que aparecen allí, que indican dónde publica la CA su CRL.
4. Copia una URL y pégala en la barra de direcciones de tu navegador.
5. Su navegador descargará el archivo CRL, que podrá consultar para ver la lista de revocación actual.

Riesgos de una CRL caducada o inaccesible

Riesgo de seguridad: Aceptar un certificado revocado

Si una CRL está desactualizada o ha caducado, los sistemas que dependen de ella no tienen forma de saber que un certificado fue revocado después de la última actualización de la CRL. Un certificado comprometido o no válido puede entonces aceptarse como confiable, lo cual es precisamente la vulnerabilidad que la verificación de revocación busca evitar.

Riesgo operacional: Problemas de servicio y cumplimiento normativo

Muchos servidores y aplicaciones están configurados para verificar siempre la validez de una CRL antes de aceptar un certificado. Si la CRL ha caducado, estos sistemas pueden rechazar los certificados automáticamente, lo que provoca interrupciones del servicio en lugar de fallos de seguridad. En cuanto al cumplimiento normativo, varios marcos regulatorios exigen que las CA y las organizaciones que confían en los certificados mantengan actualizada la verificación de revocación; el incumplimiento de esta obligación puede acarrear observaciones en auditorías y sanciones económicas.

Riesgo de confianza e ingresos

Cuando un sistema no puede confirmar de forma fiable el estado de un certificado, se socava la confianza en todas las conexiones que dicho certificado protege. Para un servicio de atención al cliente, esto se traduce directamente en la pérdida de transacciones y de confianza, ya que los usuarios y los sistemas posteriores ya no pueden estar seguros de que el certificado en el que confían sea realmente válido.

La tabla que aparece a continuación resume estos riesgos como una única referencia: qué causa cada fallo, cuál es su coste para la empresa, cómo suelen detectarlo los equipos, cómo mitigarlo, quién debe ser el responsable de la solución y de dónde proceden las pruebas que respaldan la reclamación.

Causa	Impacto en el negocio	Método de detección	Mitigación	Propietario	Fuente de evidencia
CRL superó su marca de tiempo de “próxima actualización”, pero aún se mantiene.	Un certificado revocado se considera válido sin generar confianza, lo que expone a los sistemas a credenciales comprometidas o emitidas incorrectamente.	Comprobaciones automatizadas de vigencia de CRL contra el punto final de CDP	Alerta antes de que pase la marca de tiempo de la próxima actualización; automatiza la republicación con una cadencia fija.	Equipo PKI	Cuerpo de la publicación: Cómo funciona una CRL
Punto final de CDP o AIA inaccesible	El software que confía en él no puede obtener la CRL en absoluto, y la mayoría de los navegadores fallan parcialmente, otorgando confianza sin una verificación de revocación real.	Monitorización del tiempo de actividad de los puntos finales en cada URL de CDP/AIA	Aloje CDP/AIA en una infraestructura redundante y monitorizada con alertas en caso de fallo.	Equipo de Plataforma e Infraestructura	Cuerpo de la publicación: Sección de Riesgos de Seguridad
Los sistemas de fallo estricto rechazan los certificados una vez que expira su CRL.	Los servicios legítimos se desconectan aunque en realidad no se haya producido ninguna vulneración.	Correlacionar los tickets de interrupción con los registros de vencimiento de CRL.	Realice un seguimiento centralizado de la vigencia restante de la CRL y actualícela con suficiente antelación a su vencimiento.	Seguridad	Cuerpo de la publicación: Sección de Riesgo Operacional
Consolidación de la industria en torno a la revocación exclusiva de CRL (retiro de OCSP)	Un fallo de CRL es ahora el único canal de revocación, no uno de dos	Seguimiento de los anuncios de CA y de las políticas de los navegadores.	Trate la monitorización de CRL como un control de referencia, no como una verificación secundaria.	Equipo de cumplimiento	Let's Encrypt y el servicio OCSP dejarán de funcionar el 6 de agosto de 2025.
Reducción de la validez de los certificados sin un seguimiento de revocación adecuado.	Los equipos asumen que una menor esperanza de vida hace que la salud de CRL sea menos urgente, dejando la misma ventana de exposición proporcional.	Cobertura de seguimiento de la revocación de auditorías en relación con la vigencia del certificado.	Mantener el seguimiento de revocación para cada certificado con una duración superior a siete días, independientemente del período de validez.	Equipo PKI	Boleta de votación del foro CA/Browser SC-081v3

Por qué la salud de CRL importa más ahora, no menos

En los últimos dos años, la verificación de revocación se ha ido consolidando discretamente en torno a las CRL, lo que aumenta la importancia de mantenerlas en buen estado. Let's Encrypt desactivó sus respondedores OCSP el 6 de agosto de 2025 , tras eliminar las URL OCSP de los certificados recién emitidos en mayo de ese año, y ahora publica la información de revocación exclusivamente a través de las CRL. El CA/Browser Forum ha seguido la misma línea, reduciendo la compatibilidad con OCSP a opcional para las CA, aunque mantiene la publicación de CRL como requisito básico. Para las organizaciones que gestionan su propia infraestructura de CRL o dependen de la CRL de una CA, este cambio implica que un fallo en la CRL ya no es uno de los dos canales de revocación que se caen, sino, cada vez más, el único.

La reducción de la duración de los certificados forma parte de la misma historia, pero no sustituye la comprobación de revocación. Según la propuesta SC-081v3 del Foro CA/Browser , la validez máxima de los certificados TLS se reduce a 200 días en marzo de 2026, a 100 días en marzo de 2027 y a 47 días en marzo de 2029. Los certificados emitidos con una duración de siete días o menos están exentos por completo de los requisitos de CRL y OCSP, ya que simplemente caducan antes de que la revocación sea relevante. Todo certificado emitido según un calendario estándar necesita un canal de revocación operativo durante toda su vida útil, y un certificado de 47 días con una CRL caducada está expuesto durante el mismo tiempo, proporcionalmente, que un certificado de 398 días según las normas anteriores. En nuestra experiencia asesorando a equipos sobre programas de ciclo de vida de certificados, las organizaciones que se ven afectadas rara vez son las que ignoran la revocación a propósito. Son las que asumieron que una menor duración de los certificados hacía que la supervisión de las CRL fuera menos urgente y dejaron de hacerlo.

El coste de cometer este error no es hipotético. Cuando la raíz de CA externa AddTrust de Sectigo caducó el 30 de mayo de 2020, se interrumpió la validación de certificados para una amplia gama de sistemas de producción, incluidos los firewalls de Sophos y varios servicios empresariales y de consumo no relacionados, porque la caducidad de un componente antiguo de la cadena de confianza no se estaba supervisando activamente (Fuente: base de conocimientos de Sectigo, Caducidad de la raíz de CA externa AddTrust el 30 de mayo de 2020). Se trataba de la caducidad de un certificado raíz, no específicamente de una CRL, pero el patrón de fallo es idéntico al de una CRL obsoleta: un componente de la infraestructura PKI del que dependen los sistemas que la utilizan caduca silenciosamente, y nadie lo detecta hasta que el tráfico de producción empieza a fallar.

¿Quién es el responsable?: Impacto y acciones del equipo

La gestión de la seguridad de los certificados (CRL) no depende de un solo equipo. Cada función que se describe a continuación contribuye de manera distinta a mantener la fiabilidad de la comprobación de revocación.

Equipo	¿Qué cambia para ellos?	Acción inmediata
Equipo PKI	Gestiona la publicación, firma y actualización de CRL para cada CA en el entorno.	Inventariar cada CA y confirmar que la marca de tiempo de la próxima actualización de cada CRL se registre de forma centralizada.
Seguridad	Depende de la monitorización de CRL y CDP/AIA para detectar un certificado revocado antes de que se confíe erróneamente en él.	Confirmar que la transparencia de los certificados y el monitoreo de la revocación cubren a todas las CA incluidas en el alcance.
Equipo de Plataforma e Infraestructura	Gestiona los servidores y las rutas de red que alojan y acceden a los puntos finales de CDP/AIA.	Verifique que los puntos finales de CDP/AIA se encuentren en una infraestructura redundante y supervisada con alertas de disponibilidad.
Equipo de cumplimiento	Utiliza evidencia de salud de CRL para demostrar la verificación de revocación actual durante las auditorías.	Confirmar que la evidencia de auditoría puede demostrar la vigencia de la CRL bajo demanda, no solo después de una extracción manual.

Qué hacer a continuación

• Equipos PKI: Confirme que la marca de tiempo de la próxima actualización de la CRL de cada CA se monitoriza y actualiza con suficiente antelación a su vencimiento, y que no se descubre después de un fallo de validación.
• Equipos de seguridad: Verifique que los puntos finales de CDP y AIA se supervisen para comprobar su accesibilidad, y no solo la caducidad de los certificados.
• Equipos de plataforma e infraestructura: Trasladar el alojamiento de CDP/AIA a una infraestructura redundante para que una sola interrupción no deje fuera de servicio la comprobación de revocación.
• Equipos de cumplimiento: Confirme que los informes de estado de CRL se pueden generar bajo demanda como evidencia de auditoría, adaptándose a la frecuencia que requiera su marco de trabajo.

Cómo puede ayudar la consultoría de cifrado

CertSecure Manager ofrece a los equipos una visión del estado de la infraestructura de clave pública (PKI) diseñada para detectar precisamente este tipo de fallos antes de que lleguen a producción. Así es como se ve en la práctica:

CertSecure Manager realiza una comprobación detallada de todos los componentes de la Autoridad de Certificación, mostrando los puntos finales de CDP y AIA, así como la cantidad de días que faltan para que caduque cada CRL. Cuando detecta un problema, alerta automáticamente a los administradores en lugar de esperar a que alguien detecte un fallo de validación en un nivel inferior.

• Revisión médica completa de California: CertSecure Manager verifica cada componente de la autoridad de certificación y le proporciona una visión centralizada del estado general de la infraestructura de clave pública (PKI).
• Visibilidad de CDP y AIA: Identifica el punto de distribución de la CRL y los puntos finales de acceso a la información de la autoridad, para que siempre sepa dónde se encuentran los datos de revocación de un certificado.
• Duración restante de la CRL: Muestra cuánto tiempo queda antes de que caduque una CRL, lo que da a los administradores un margen de tiempo para actualizarla antes de que se convierta en un problema.
• Alertas automatizadas: CertSecure Manager notifica a los administradores sobre las próximas expiraciones de las CRL y señala los incidentes cuando falla una comprobación de revocación, reduciendo así el tiempo que transcurre entre que ocurre un problema y alguien se entera de él.

Cuando la preparación para la certificación se cruza con un riesgo criptográfico más amplio, nuestro Centro de Excelencia PQC utiliza el mismo inventario de certificados y CA para ayudar a secuenciar una migración post-cuántica, y nuestra guía sobre cómo convertir un CBOM en una capacidad operativa mantiene ese inventario actualizado mucho después del despliegue inicial de la salud de PKI.

Conclusión

Una lista de revocación de certificados (CRL) mantiene la confiabilidad de las comunicaciones digitales al brindar a los sistemas que dependen de ellas una forma de rechazar certificados comprometidos o invalidados antes de su vencimiento. Esta protección solo se mantiene vigente si la CRL permanece actualizada. Una CRL vencida, fuera de línea o mal configurada puede socavar la confianza que se creó para proteger, lo que puede resultar en la aceptación de certificados revocados por un lado y en interrupciones innecesarias por otro.

Una plataforma de gestión del ciclo de vida de los certificados como CertSecure Manager proporciona a los equipos una visibilidad centralizada de sus certificados y CRL en toda la organización, lo que realmente previene interrupciones, reduce el tiempo de inactividad y evita el coste de la corrección reactiva después de que algo ya se haya estropeado.

Preguntas frecuentes

¿Cuál es la principal conclusión del informe "Los riesgos ocultos de las listas de revocación de certificados (CRL) caducadas"?

Una CRL caducada, sin conexión o mal configurada elimina el único mecanismo que tienen los sistemas que dependen de ella para rechazar un certificado revocado. Desde que Let's Encrypt dejó de usar OCSP el 6 de agosto de 2025, las CRL se están convirtiendo cada vez más en el único canal de revocación disponible, por lo que un fallo en la CRL ya no es un riesgo secundario detrás de OCSP; a menudo constituye toda la red de seguridad.

¿Por qué es importante esto para la gestión del ciclo de vida de los certificados empresariales?

La gestión del ciclo de vida de los certificados es fundamental para evitar que la fecha de la próxima actualización de una CRL pase desapercibida. A medida que el Foro CA/Browser reduce gradualmente la validez máxima de los certificados TLS públicos a 47 días para 2029, el volumen de certificados y CRL que se deben controlar aumenta, y el seguimiento manual no puede seguir el ritmo de esta magnitud.

¿Qué equipos son responsables de poner en práctica estas directrices?

Los equipos de PKI son responsables de la publicación y actualización de la CRL. Los equipos de seguridad son responsables de la monitorización de los puntos finales de CDP y AIA. Los equipos de plataforma e infraestructura alojan y mantienen los sistemas en los que se ejecutan esos puntos finales. Los equipos de cumplimiento se basan en la evidencia del estado de la CRL para demostrar la comprobación de revocación actual durante las auditorías.

¿Qué riesgos aumentan si este tema se aborda manualmente?

El seguimiento manual aumenta el riesgo de que la marca de tiempo de la próxima actualización de una CRL pase desapercibida, que un punto final de CDP inaccesible no se detecte porque la mayoría de los navegadores fallan silenciosamente y que se produzcan auditorías cuando no se puede generar evidencia de revocación a petición. La encuesta Trust Pulse de DigiCert de julio de 2025 reveló que el 45 % de las organizaciones experimentaron tiempo de inactividad relacionado con certificados en el último año, y el 37.5 % se debió a un certificado caducado.

¿Cómo reduce la automatización el riesgo de interrupción de los certificados?

La monitorización automatizada del estado de la infraestructura de clave pública (PKI), como las comprobaciones de CertSecure Manager, realiza un seguimiento continuo de los puntos finales CDP y AIA de cada CA y de la vida útil restante de la lista de revocación de certificados (CRL), alertando a los administradores antes de que caduque una CRL en lugar de después de que ya se haya producido un fallo de validación.

¿Qué métricas deberían monitorizar los equipos tras la implementación?

Realizar un seguimiento del número de días que faltan para la próxima actualización de cada CRL, el tiempo de actividad de los puntos finales de CDP y AIA, el número de interrupciones o cuasi accidentes relacionados con la revocación por trimestre y el tiempo necesario para generar evidencia del estado de la CRL para una auditoría a demanda.

¿Cómo se relaciona esto con el plazo de 47 días para la obtención del certificado TLS?

Un certificado de 47 días con una CRL vencida queda expuesto durante el mismo tiempo, proporcionalmente, que un certificado de 398 días bajo las antiguas normas de validez. Las organizaciones que ya automatizan la supervisión del estado de las CRL no tendrán que volver a implementar esa práctica cuando los períodos de validez más cortos entren en vigor en 2029.

¿Cómo debería gestionarse esto en entornos PKI híbridos o multinube?

Los entornos PKI híbridos y multinube deben supervisar los puntos finales de CDP y AIA de cada CA, ya sea una CA interna de Microsoft o una CA pública, desde una única vista centralizada en lugar de comprobarlos individualmente. Un fallo en la CRL en un entorno puede dejar a los sistemas que dependen de él sin un canal de revocación operativo, mientras que todos los demás entornos parecen funcionar correctamente.