Supervisión de la transparencia de los certificados en la era de la tomografía computarizada estática

La Transparencia de Certificados (CT) es un registro público y permanente de los certificados TLS emitidos para sitios web. La monitorización de estos registros públicos, conocida como supervisión de la Transparencia de Certificados, permite a los equipos de seguridad detectar certificados emitidos para sus dominios que nunca solicitaron ni aprobaron. En 2026, se produjeron dos cambios que afectaron a este proceso. Una nueva norma para navegadores restringe la forma y el lugar donde deben registrarse los certificados, y los propios registros se rediseñaron para que su procesamiento fuera más rápido y económico.

En conjunto, estos cambios implican que las herramientas y los hábitos que muchos equipos han desarrollado para la monitorización de tomografías computarizadas necesitan una actualización. Este blog explica qué ha cambiado, por qué es importante y cómo crear un enfoque de monitorización que siga siendo válido en 2026 y más allá. Empezamos desde lo básico, así que no es necesario ser un experto en tomografías computarizadas para seguir el hilo.

Qué es la transparencia de los certificados y por qué es importante

La Transparencia de Certificados es un sistema de registro público para certificados TLS. Cada vez que una Autoridad de Certificación emite un certificado, lo registra en un libro mayor público de solo lectura. Cualquiera puede leer estos registros, y esta transparencia es lo que permite detectar certificados que no deberían existir.

Antes de la existencia de CT, una CA comprometida o con comportamiento fraudulento podía emitir discretamente un certificado para cualquier dominio, sin que nadie fuera de esa CA lo supiera. En 2011, unos atacantes comprometieron la CA holandesa DigiNotar y emitieron cientos de certificados fraudulentos, incluido un certificado comodín para *.google.com. En aquel momento, no existía un registro público auditable de la emisión de certificados, lo que dificultaba que los propietarios de dominios y los proveedores de navegadores detectaran rápidamente los certificados no autorizados o emitidos incorrectamente. CT se diseñó para solucionar este problema.

Para los equipos de seguridad actuales, CT ofrece diversas funcionalidades prácticas. Permite detectar certificados emitidos para sus dominios sin su conocimiento, identificar errores en la emisión de certificados por parte de las CA antes de que causen daños, mapear la huella de certificados externos de su organización, incluidos los subdominios olvidados, y generar evidencia de auditoría para programas de cumplimiento que requieren supervisión en la emisión de certificados.

El protocolo está estandarizado en el RFC 6962 y su sucesor , el RFC 9162 , aunque en la práctica los navegadores siguen implementando el RFC 6962. Los navegadores, incluidos Chrome y Safari, requieren que los certificados incluyan una marca de tiempo de certificado firmado (SCT), que es la prueba criptográfica del registro que acredita que el certificado se registró. Un certificado sin una SCT válida de un registro reconocido es rechazado.

¿Qué cambió con la directiva de Chrome de junio de 2026?

Chrome aplica la transparencia de certificados (CT) a los certificados de validación extendida desde 2015 y a la mayoría de los certificados públicos desde 2018. La actualización del 15 de junio de 2026 de la Política del Programa Raíz de Google Chrome (versión 1.8) refuerza los requisitos de transparencia de certificados y gobernanza de PKI en todos los tipos de certificados de confianza pública.

Los propietarios de CA deben registrar cada precertificado de autenticación de servidor TLS en al menos un registro CT que Chrome reconozca como "Utilizable" o "Calificado" antes de emitir el certificado. El número exacto de SCT requeridos varía según el período de validez del certificado. Chrome requiere dos SCT para certificados con una validez inferior a 180 días y tres para aquellos con una validez de 180 días o más. En cualquier caso, el requisito fundamental se mantiene: la verificación independiente por parte de más de un operador de registro.

Chrome evalúa cada certificado en función de un conjunto definido de estados de registro. Un registro puede estar en uno de cuatro estados que son importantes para el cumplimiento.

• Apto: Chrome lo ha aceptado recientemente y sus SCT ya cuentan para el cumplimiento de la normativa CT.
• Utilizable: Se reconoce plenamente y se aceptan nuevas presentaciones, por lo que las SCT se tienen en cuenta tanto si están integradas como si se entregan mediante el protocolo de enlace TLS.
• Solo lectura: Ya no acepta nuevos certificados (se publica el tamaño final de su árbol), pero sigue siendo de confianza, por lo que los SCT existentes aún se tienen en cuenta.
• Retirado: Ya no se utiliza para nuevos SCT, y solo los SCT integrados emitidos antes de la fecha de retirada siguen siendo válidos.

Los SCT de registros que no se encuentran en un estado reconocido como bueno no cuentan para el cumplimiento. Por lo tanto, los certificados enviados a registros que posteriormente dejan de estar en buen estado pueden perder su estado de cumplimiento de CT incluso después de su emisión. Chrome 148, lanzado el 5 de mayo de 2026, también eliminó la compatibilidad con los SCT entregados mediante respuestas OCSP adjuntas , lo que significa que ahora los SCT deben estar integrados en el propio certificado o entregados mediante la extensión de protocolo de enlace TLS. Cualquier implementación que dependa de SCT adjuntas a OCSP debe volver a emitirse.

Los certificados que anteriormente dependían de excepciones heredadas de Transparencia de Certificados o de mecanismos de entrega SCT obsoletos deben revisarse para garantizar que sigan cumpliendo con la política CT actual de Chrome. Esta medida también refuerza la necesidad de una monitorización CT continua, ya que cada certificado emitido incorrectamente debe aparecer ahora en un registro público, lo que convierte a dichos registros en una fuente de información sobre amenazas más fiable que nunca.

¿Por qué el diseño de registro RFC 6962 anterior tuvo dificultades a gran escala?

El diseño original del registro CT en RFC 6962 funciona como un servicio API clásico basado en una base de datos. Cuando una CA envía un certificado, el registro lo almacena en una base de datos, actualiza un árbol hash Merkle para confirmar criptográficamente la nueva entrada y devuelve un SCT. Posteriormente, los monitores y auditores consultan el registro a través de puntos finales de la API REST para recuperar entradas y verificar la consistencia.

Este diseño funcionaba bien cuando el volumen de certificados era manejable. La infraestructura de clave pública web (Web PKI) ha crecido mucho más allá de ese punto. Los registros individuales de CT ahora contienen miles de millones de entradas por cada fragmento temporal (un segmento de un registro dividido en el tiempo que solo contiene certificados que caducan dentro de un período fijo), y la base de datos detrás de cada registro se convirtió en un cuello de botella. Cuando los monitores intentaban leer grandes volúmenes de entradas rápidamente, con frecuencia sobrecargaban la ruta de lectura. Los operadores de registros respondieron con límites de velocidad, lo que ralentizó la monitorización y mermó el valor de CT como mecanismo de detección casi en tiempo real.

La garantía de retardo máximo de fusión de 24 horas también estuvo en riesgo repetidamente. Según la RFC 6962, un registro puede devolver un SCT inmediatamente y luego tiene hasta 24 horas para incluir el certificado en su árbol Merkle. Durante los períodos de alta carga, los registros estuvieron a punto de perder ese plazo, lo que generó situaciones en las que la promesa del SCT no se podía cumplir de manera confiable. Estos desafíos dejaron claro que la arquitectura necesitaba cambiar.

Cómo funcionan la API de tomografía computarizada estática y la luz solar.

La API de Static CT adopta un enfoque fundamentalmente diferente. En lugar de responder a consultas desde una base de datos en tiempo real, un registro de Static CT publica todos sus datos como una jerarquía de archivos estáticos llamados mosaicos. Estos mosaicos se sirven desde almacenamiento de objetos como S3 o desde una CDN. No se requiere ningún cálculo del lado del servidor para la ruta de lectura, lo que explica sus ventajas en eficiencia.

La implementación de Sunlight, desarrollada por Filippo Valsorda en colaboración con Let's Encrypt, es la más extendida de esta especificación. Dado que la ruta de lectura se compone únicamente de archivos estáticos, puede servirse completamente desde una CDN, lo que permite a los monitores obtener mosaicos almacenables en caché en lugar de consultar repetidamente una base de datos en tiempo real. Esto elimina el cuello de botella de la ruta de lectura que limitaba la monitorización según la RFC 6962 y reduce drásticamente el ancho de banda y la capacidad de procesamiento que debe proporcionar un operador de registro.

El proceso de escritura también mejoró. Sunlight agrupa las solicitudes y las integra en el árbol Merkle antes de devolver un SCT. Esto elimina por completo el retraso máximo de fusión. El SCT no se emite hasta que el certificado se confirma en el árbol, por lo que la promesa que hace el SCT siempre se cumple.

El registro está estructurado en bloques de 256 entradas cada uno. Cada bloque es un archivo estático que se guarda en el almacenamiento de objetos o en un sistema de archivos local. El registro se divide temporalmente, de modo que cada bloque solo acepta certificados cuya fecha de caducidad se encuentre dentro de un período específico, generalmente de seis meses. Esto limita el tamaño de los bloques y facilita la gestión del almacenamiento.

Let's Encrypt cambió sus registros RFC 6962 a modo de solo lectura el 30 de noviembre de 2025 y los desactivó por completo el 28 de febrero de 2026. Sus registros CT de producción ahora se ejecutan en Sunlight, con Sycamore y Willow como principales plataformas de producción. El equipo de TrustFabric de Google lanzó TesseraCT, una implementación de API CT estática que ofrece una alternativa a CTFE basada en Trillian, que impulsa muchos registros antiguos. El ecosistema ha adoptado decisivamente esta arquitectura.

Cómo funciona ahora la monitorización mediante tomografía computarizada

La forma de recopilar las entradas depende del tipo de registro. Las dos subsecciones siguientes tratan sobre la monitorización con respecto a los registros RFC 6962 heredados y a los registros Static CT más recientes.

Supervisión conforme a los registros RFC 6962

Con un registro RFC 6962, un monitor llama al punto final get-entries con un índice de inicio y fin, recupera lotes de certificados y actualiza su posición a medida que llegan nuevas entradas. El registro sirve las entradas desde una base de datos y devuelve la cadena completa de certificados con cada entrada, lo que simplifica la atribución de la CA.

Monitoreo contra registros CT estáticos

Con un registro CT estático, un monitor descarga directamente los mosaicos de datos. Cada mosaico contiene 256 entradas. El monitor obtiene cada mosaico que aún no ha visto, procesa las entradas y utiliza el archivo de punto de control firmado del registro para realizar un seguimiento del tamaño actual del árbol. Los mosaicos son estáticos y se sirven desde el almacenamiento de objetos, por lo que los monitores pueden obtenerlos en paralelo sin alcanzar los límites de velocidad.

Una diferencia práctica radica en el manejo de las cadenas. Los registros RFC 6962 devolvían una cadena de certificados completa por entrada. Los registros CT estáticos no adjuntan una cadena a cada entrada. En su lugar, el registro publica un paquete del emisor que contiene los certificados intermedios que ha aceptado. Los monitores que necesitan reconstruir una cadena completa para la atribución de CA deben construirla a partir de este paquete. Esto añade complejidad al monitor, pero es una compensación deliberada que mantiene los datos por entrada compactos y reduce significativamente el ancho de banda.

Desde la perspectiva de la estrategia de monitorización, las categorías que merece la pena rastrear se mantienen constantes independientemente del tipo de registro.

• Se han emitido nuevos certificados para los dominios de su propiedad, incluyendo coincidencias con comodines.
• Certificados de autoridades de certificación que su organización no ha autorizado.
• Certificados con periodos de validez fuera de su póliza.
• Certificados que revelan subdominios que no reconoces.

Estas cuatro categorías generan la mayoría de los eventos que requieren mayor acción.

Herramientas disponibles para la monitorización mediante tomografía computarizada

La monitorización de los registros CT es solo la mitad del trabajo; la clave está en actuar en función de los resultados. Aquí es donde entra en juego CertSecure Manager de Encryption Consulting . Se trata de una plataforma que combina la monitorización de registros CT con la gestión integral del ciclo de vida de los certificados (CLM). Escanea continuamente los registros CT en busca de certificados emitidos para sus dominios y los compara con su inventario de certificados aprobados. De este modo, su equipo puede investigar y solucionar los problemas desde una única consola, en lugar de utilizar herramientas de búsqueda y alerta independientes.

Certstream proporciona una transmisión WebSocket en tiempo real de las entradas de registro de Transparencia de Certificados (CT) en todos los registros activos. Los equipos de seguridad lo utilizan para crear sistemas de filtrado y alerta que les notifican poco después de que aparezca un certificado coincidente en los registros de Transparencia de Certificados.

Google mantiene una lista actualizada de servicios de monitorización de CT reconocidos en certificate.transparency.dev. Para los equipos que desarrollan monitores personalizados, la especificación C2SP static-ct-api es la referencia técnica completa para el formato de mosaico y la estructura de puntos de control.

Independientemente de la herramienta que utilice su equipo, el resultado es un flujo de eventos de certificados que deben clasificarse y revisarse. El diseño de las alertas y su integración con el proceso de respuesta a incidentes son tan importantes como el propio proceso de ingesta. Estas herramientas gestionan la ingesta; la plataforma CLM se encarga de correlacionar los eventos con su inventario de certificados autorizados y actuar en consecuencia.

Patrones de amenazas que merecen ser monitoreados

Los datos brutos de la tomografía computarizada no son útiles por sí solos. Un monitoreo efectivo implica saber qué patrones indican un problema real.

Emisión de certificado no autorizada : Una autoridad de certificación (CA) con la que usted no tiene ninguna relación emite un certificado para su dominio. Esto puede indicar una omisión de la validación del dominio, una CA comprometida o un atacante con suficiente control DNS para superar la validación automatizada del dominio. Detectar esto rápidamente fue el propósito original del diseño de CT.

Certificados en la sombra : Certificados emitidos para infraestructura que su organización opera pero no administra centralmente. Los ejemplos más comunes son los equipos de desarrollo que utilizan cuentas de CA personales y los certificados emitidos para subdominios públicos no administrados o infraestructura fuera de los procesos PKI aprobados . Los certificados en la sombra crean una brecha de seguridad y un riesgo de incumplimiento normativo.

Exposición de subdominios : Cada subdominio en un certificado es accesible públicamente desde el momento en que se registra. Los entornos de prueba, las herramientas internas y los productos en fase de prelanzamiento se vuelven detectables tan pronto como reciben un certificado. Monitorear sus propios dominios en CT le brinda visibilidad sobre esta exposición antes de que un atacante la obtenga.

Indicadores de emisión errónea : Los certificados con nombres alternativos de sujeto (SAN) inesperados, emisores inesperados, valores de uso de clave extendida (EKU) inusuales o campos de certificado anómalos pueden indicar un error en la política de la CA o una manipulación deliberada. El análisis automatizado de campos a gran escala permite detectarlos de forma fiable.

Infraestructura de phishing y typo squatting : Los atacantes obtienen regularmente certificados para dominios que se parecen visualmente al nombre de la organización objetivo. Monitorear CT para detectar coincidencias cercanas y patrones de sustitución comunes proporciona una alerta temprana sobre la creación de infraestructura de phishing.

Detectar estos patrones en los datos brutos de CT es una cosa; actuar con rapidez en todos los ámbitos que gestionas es otra muy distinta. Cerrar esa brecha es la función de una plataforma CLM , que transforma un flujo constante de alertas de CT en tareas priorizadas que tu equipo puede rastrear y resolver.

Cómo puede ayudar la consultoría de cifrado

La monitorización de la transparencia de certificados es más valiosa cuando se conecta a una plataforma CLM que puede actuar en función de la información que muestran los registros. Ver un certificado no autorizado en un registro de CT solo es útil si su equipo sabe qué CA lo emitió, si se solicitó mediante un proceso aprobado y con qué rapidez se puede revocar y reemplazar. Sin una plataforma CLM que proporcione ese contexto, las alertas de CT generan ruido en lugar de acciones.

CertSecure Manager de Encryption Consulting es una plataforma CLM independiente del proveedor, diseñada para brindar a los equipos de seguridad y PKI visibilidad y control total sobre su entorno de certificados. Descubre e inventaría automáticamente los certificados en entornos en la nube, locales e híbridos, para que su equipo siempre sepa qué certificados existen y dónde. Cuando se activa una alerta CT para un certificado que ya se encuentra en el inventario, se puede correlacionar y confirmar automáticamente. Si se activa para un certificado desconocido, CertSecure Manager lo presenta como un elemento de investigación inmediata con todo el contexto del emisor y la implementación.

Más allá del descubrimiento, CertSecure Manager automatiza todo el ciclo de vida de los certificados, desde la inscripción y emisión hasta la renovación y revocación. Aplica la emisión basada en políticas en autoridades de certificación públicas y privadas, se integra con flujos de trabajo y protocolos DevOps como ACME y SCEP, y proporciona el registro de auditoría que exigen los marcos de cumplimiento, incluidos PCI DSS , ISO 27001 y las directrices del NIST. Para las organizaciones que responden al mandato de Chrome de junio de 2026, esto significa que pueden identificar con precisión qué certificados deben reemitirse, dirigirlos a través de la autoridad de certificación correcta y confirmar el cumplimiento de CT sin necesidad de seguimiento manual.

Encryption Consulting también ofrece PKI-as-a-Service para organizaciones que necesitan una CA privada totalmente gestionada, así como servicios de asesoramiento PQC . La misma criptoagilidad que exigen ahora la reducción de la duración de los certificados y la automatización de CT es la que las organizaciones necesitarán para la transición a los estándares post-cuánticos del NIST ( FIPS 203 , 204 y 205 , finalizados en agosto de 2024). A medida que la duración de los certificados se acorta y la automatización se convierte en la norma, contar con las herramientas y la experiencia necesarias es lo que distingue a los equipos que mantienen el control de aquellos que se ven obligados a reaccionar a contrarreloj.

Conclusión

La transparencia de certificados convierte cada certificado de confianza pública en un registro público, y consultar dicho registro es una de las maneras más sencillas de detectar certificados emitidos para tus dominios sin tu aprobación. Sin embargo, esto solo funciona si alguien supervisa los registros y actúa en consecuencia.

En 2026, se produjeron dos cambios. Chrome ahora exige el registro de casi todos los certificados, y estos registros se trasladaron al diseño de API de CT estática, más rápido y económico. En conjunto, estos cambios hacen que los datos de CT sean más completos y fáciles de manejar, pero también implican que la monitorización basada en el modelo anterior necesita actualizarse. Los equipos que más se benefician de esta nueva versión no consideran la monitorización de CT como una fuente de alertas independiente, sino como parte de una plataforma CLM más amplia capaz de investigar y actuar en función de los hallazgos.