Registros de Certificate Transparency: lo que revelan sobre sus dominios

Certificate Transparency (CT, transparencia de certificados) es un sistema de registros en los que solo se puede añadir, que anotan los certificados TLS a medida que las autoridades de certificación los emiten. Cualquiera puede leer estos registros. Para su empresa eso significa 2 cosas: los registros muestran a todo el mundo para qué nombres de host tiene usted certificados, y le permiten detectar un certificado para su dominio que nadie de su lado ha solicitado.

El protocolo se describió por primera vez en el RFC 6962 (junio de 2013) y se actualizó como versión 2.0 en el RFC 9162 (diciembre de 2021). Ambos son RFC experimentales, pero en la práctica los navegadores dependen de CT: Chrome exige que los certificados TLS de confianza pública cumplan CT, y Apple tiene su propia política de CT para sus plataformas.

Por tanto, si un navegador confía en un certificado para yourcompany.com, casi con total seguridad existe una entrada en el registro.

Lo que los registros revelan sobre su empresa

Una entrada de CT contiene los nombres que cubre el certificado, la autoridad emisora y las fechas de validez. En conjunto, las entradas de su dominio muestran:

• Sus subdominios. vpn.yourcompany.com, jira.yourcompany.com, staging-api.yourcompany.com: cada nombre que alguna vez tuvo su propio certificado.
• Sus proveedores. Los emisores y los patrones de nombres suelen dar pistas sobre qué plataformas de alojamiento, correo o SaaS utiliza.
• Su historial. Las entradas antiguas permanecen en el registro, así que siguen visibles nombres de proyectos cerrados hace años.
• Los certificados nuevos en cuanto aparecen. Una entrada nueva para un nombre que no reconoce, o de una autoridad que no utiliza, merece una pregunta.

Nada de esto es un fallo de CT. El objetivo del sistema es que los certificados mal emitidos no puedan permanecer ocultos. La consecuencia es que su lista de nombres de host no es privada, así que más vale que la lea usted antes que nadie.

Cómo consultar los registros usted mismo

La forma más sencilla es crt.sh, una interfaz de búsqueda para los registros de CT. Escriba su dominio, o use % como comodín para incluir todos los subdominios:

https://crt.sh/?q=%25.yourcompany.com

Para obtener una lista que pueda procesar, añada &output=json:

curl -s 'https://crt.sh/?q=%25.yourcompany.com&output=json' \
  | jq -r '.[].name_value' | sort -u

Al leer los resultados, fíjese en:

• Nombres que nadie reconoce. Cada uno debería corresponder a un sistema con un responsable conocido.
• Nombres de pruebas y staging como dev, test, old, beta. Suelen apuntar a servidores de staging olvidados.
• Nombres que ya no resuelven o que apuntan a una plataforma que abandonó. Revíselos por si hay DNS colgantes y toma de subdominios.
• Emisores inesperados. Un certificado de una autoridad que nunca ha utilizado merece una comprobación con el equipo que gestiona su DNS y su alojamiento.
• Fechas recientes que no sabe explicar. Un certificado nuevo para el nombre de host de su página principal de inicio de sesión que nadie ha solicitado es el caso más urgente.

Tenga en cuenta que los certificados comodín (*.yourcompany.com) no enumeran subdominios concretos, así que los registros le muestran mucho, pero no todo.

Limite quién puede emitir: el registro CAA

Con un registro CAA, definido en el RFC 8659, puede indicar qué autoridades de certificación pueden emitir para su dominio. Las autoridades lo consultan antes de emitir. Una configuración típica:

yourcompany.com.  CAA 0 issue "letsencrypt.org"
yourcompany.com.  CAA 0 issuewild ";"
yourcompany.com.  CAA 0 iodef "mailto:security@yourcompany.com"

Esto permite una sola autoridad, prohíbe los certificados comodín y facilita una dirección para los avisos. CAA no sustituye a CT: reduce lo que se puede emitir, mientras que CT le muestra lo que realmente se ha emitido.

Los certificados se acortan, así que los registros se llenan más

Según la votación SC-081 del CA/Browser Forum, ya incorporada a los Baseline Requirements, la validez máxima de los certificados TLS públicos es de 200 días para los emitidos a partir del 15 de marzo de 2026, de 100 días a partir del 15 de marzo de 2027 y, desde el 15 de marzo de 2029, de solo 47. Las renovaciones serán más frecuentes y casi siempre automáticas, así que sus dominios generarán más entradas de CT. Eso hace menos práctica la lectura manual y más útil una referencia clara de los certificados "esperados". Sobre la parte de renovación de este cambio, consulte por qué la caducidad de certificados sigue tumbando sitios web.

Qué hacer cuando encuentra algo inesperado

1. Identifique al responsable. Pregunte a TI, a marketing y a sus agencias si solicitaron el certificado.
2. Si nadie lo hizo, contacte con la autoridad emisora. Cada una publica un procedimiento para notificar certificados mal emitidos y solicitar su revocación.
3. Revise su DNS y su registrador. Un certificado inesperado puede seguir a un cambio de DNS, así que repase los puntos de nuestro artículo sobre cambios de servidores de nombres y de registrador.
4. Añada o endurezca el registro CAA para que la misma autoridad no pueda volver a emitir sin su consentimiento.

Una lista de comprobación breve

• Busque %.yourcompany.com en crt.sh y guarde la lista de nombres.
• Asigne cada nombre a un sistema y a un responsable.
• Elimine o corrija los nombres que no apuntan a nada.
• Publique un registro CAA con las autoridades que utiliza.
• Revise las entradas nuevas con regularidad, no una vez al año.

Dónde encaja Datahorses

Datahorses vigila su empresa desde fuera cada día, y Certificate Transparency es una de las cosas que lee por usted: certificados nuevos emitidos para sus dominios, subdominios nuevos y los registros CAA que deberían limitarlos. No entramos en sus sistemas y no necesitamos accesos. Cuando algo no cuadra, recibe el hallazgo con pasos claros, como se describe en qué ocurre cuando encontramos algo. La lista completa de lo que vigilamos está en la página de inicio.