Recursos

Certificate Transparency no es un inventario de certificados

Los registros CT son un buen punto de partida para descubrir certificados públicos. No equivalen a un inventario operativo: no muestran todos los endpoints desplegados, todos los certificados internos ni el equipo responsable de renovarlos.

Para qué sirve CT

Certificate Transparency hace visible la emisión de certificados públicos. La RFC 6962 define el protocolo utilizado por los registros públicos; los más recientes emplean el formato compatible de static-ct-api, organizado en bloques. Así, las autoridades de certificación, los operadores de sitios, los navegadores y las herramientas de supervisión pueden examinar los certificados emitidos y detectar emisiones sospechosas.

Chrome exige compatibilidad con CT para reconocer como válidos los certificados TLS de confianza pública emitidos después del 30 de abril de 2018. Por eso, CT es una fuente útil para descubrir nombres públicos que controla tu organización.

Qué puede mostrar CT

  • Certificados públicos emitidos para los nombres que supervisas.
  • Emisiones públicas inesperadas o no autorizadas para tus dominios.
  • Evidencias históricas de que un nombre apareció en un certificado público.

Qué no demuestra CT

  • Certificados de PKI privada, autofirmados, de laboratorio, de dispositivos o de uso exclusivamente interno.
  • Si un certificado registrado está realmente desplegado en un endpoint en servicio.
  • El equipo responsable del servicio, el método de renovación y el circuito de alertas.
  • Todos los nombres de host servidos mediante certificados comodín, enrutamiento SNI o puertos no estándar.

Lo que falta para tener un inventario

Ejemplo ilustrativo
  1. Nombre de host encontrado en CTapi.example.comUn nombre de host que comprobar
  2. Comprobación TLS directaapi.example.com:443
  3. Certificado que presenta el servicio*.example.comQuedan 68 días

Una entrada CT acredita la emisión. Una comprobación TLS correcta muestra qué certificado presenta el servicio accesible en ese momento.

Los Baseline Requirements del CA/Browser Forum se aplican a certificados de servidor de confianza pública y excluyen expresamente las PKI empresariales de uso exclusivamente interno. Esos certificados internos suelen ser relevantes en incidentes y auditorías, pero no aparecerán por el mero hecho de supervisar los registros CT públicos.

Cuatro campos que conviene añadir al inventario

Fuente

¿El certificado se encontró en CT, DNS, un análisis directo, un análisis de agente o una importación manual?

Endpoint

¿Qué host, puerto, protocolo y nombre SNI lo presentan actualmente?

Responsable

¿Qué equipo puede renovarlo, sustituirlo o retirarlo de forma deliberada?

Método de renovación

¿La emisión está automatizada, la gestiona un proveedor o sigue dependiendo de una solicitud y un cambio manual?

Lista de comprobación

  • Utiliza los registros CT como punto de partida para descubrir certificados públicos de dominios que controlas.
  • Confirma el despliegue mediante análisis de endpoints que tengan en cuenta SNI y los puertos no estándar.
  • Importa zonas DNS o listas de hosts conocidos para que el inventario no se limite a lo que han emitido las autoridades de certificación.
  • Analiza los rangos internos autorizados desde dentro de la red para encontrar certificados privados que no aparecerán en CT.
  • Asigna responsables y registra el método de renovación, el entorno y el destinatario de las alertas antes del primer aviso de renovación.
  • Mantén la supervisión de CT para detectar emisiones públicas inesperadas y trátala como una de las fuentes de detección.

Cómo encaja Nocert

Nocert utiliza datos públicos de CT para obtener nombres de host que comprobar, pero no considera que una entrada del registro sea un inventario. Analiza los endpoints TLS accesibles para confirmar qué certificado presentan y añade detección interna mediante agentes Sentinel. CT sigue siendo un control independiente útil para detectar emisiones públicas inesperadas; Nocert se centra en el inventario público y privado observado.

Fuentes primarias

Esta nota se basa en la RFC 6962, la política de Certificate Transparency de Chrome, los Baseline Requirements del CA/Browser Forum y la documentación de Certificate Transparency de Let’s Encrypt.