Certificados TLS y Certificate Transparency, explicados.

El icono del candado en la barra de direcciones del navegador es uno de los símbolos peor interpretados de internet. La mayoría lo lee como «este sitio es seguro». Lo que en realidad significa es mucho más limitado: la conexión con este dominio está cifrada, y una autoridad de certificación confirmó que quien solicitó este certificado controlaba el dominio en el momento en que lo pidió. Eso es todo. Un dominio de phishing registrado hace noventa segundos puede tener un certificado perfectamente válido y con su candado –gratuito, automático y emitido en menos de un minuto por Let's Encrypt. Entender qué certifica realmente un certificado TLS, y cómo Certificate Transparency mantiene honesto a todo el sistema, es la diferencia entre confiar en un símbolo y confiar en un sistema que de verdad comprendes.

Qué es en realidad un certificado

Un certificado TLS es un pequeño archivo firmado criptográficamente que vincula una clave pública a un nombre de dominio. Cuando te conectas a un sitio por HTTPS, el servidor presenta su certificado; tu navegador comprueba que la firma se remonta a una autoridad de certificación raíz (CA) en la que ya confía, y que el nombre de dominio del certificado coincide con el que estás visitando. Si ambas comprobaciones se superan, tu navegador puede usar la clave pública del certificado para establecer un canal cifrado –cuya mecánica cubrimos en cómo funcionan las redes, donde se recorre paso a paso un handshake TLS completo.

Lo que el certificado no es es una verificación de antecedentes sobre el propietario del sitio, sus intenciones o su fiabilidad. Prueba el control del dominio en el momento de la emisión, y punto. Esa distinción importa más que casi cualquier otro dato de este artículo.

La cadena de confianza

Ningún navegador confía directamente en el certificado de un sitio web. En vez de eso, la confianza fluye por una cadena, donde cada eslabón firma al que tiene debajo:

Tu navegador verifica esta cadena eslabón por eslabón, hasta llegar a una raíz en la que ya confía. Rompe cualquier eslabón –una intermedia caducada, una firma que no verifica, un dominio que no coincide– y obtienes el aviso de «la conexión no es privada» en vez de un candado.

DV, OV y EV: tres niveles de verificación, un candado idéntico

No todos los certificados implican la misma cantidad de comprobación, aunque el candado resultante se vea igual para casi todo el mundo:

Durante años, los certificados EV obtenían una recompensa visible: una barra de direcciones verde que mostraba el nombre legal de la empresa. A partir de 2019, Chrome y la mayoría de los grandes navegadores retiraron discretamente ese trato especial, después de que estudios de usabilidad descubrieran que casi nadie se fijaba en ello ni lo entendía. Hoy los tres tipos de certificado se muestran como el mismo candado neutro –lo que significa que el candado por sí solo nunca te ha dicho tan poco sobre con quién estás hablando en realidad como te dice ahora mismo. Esta es también la razón exacta por la que el dominio y el historial de DNS importan más que el propio certificado a la hora de juzgar un sitio: consulta investigar un dominio sospechoso para el flujo de trabajo completo.

Por qué existe Certificate Transparency

El modelo de cadena de confianza tiene una debilidad incómoda: depende por completo de que las autoridades de certificación se comporten correctamente, y durante la mayor parte de la historia de TLS no había forma fiable de comprobar que lo hicieran. Si una CA –por un compromiso, coacción o simple error– emitía un certificado de un dominio a alguien que en realidad no lo poseía, el propietario real del dominio no tenía forma de enterarse. El caso de estudio más claro es DigiNotar, una CA holandesa vulnerada en 2011. El atacante emitió un certificado fraudulento y totalmente válido para *.google.com, que después se observó siendo usado para interceptar tráfico HTTPS hacia Gmail en Irán. DigiNotar no tenía ni idea de que ese certificado existiera hasta que investigadores lo encontraron siendo usado activamente contra usuarios reales.

Certificate Transparency (CT), propuesto poco después y hoy obligatorio para cualquier certificado que un navegador mayoritario vaya a confiar, cierra ese punto ciego. Todo certificado de confianza pública debe registrarse ahora en uno o más registros independientes, públicos y de solo adición (append-only) antes de que un navegador lo acepte –lo que significa que todo certificado jamás emitido para tu dominio es ahora un registro público y consultable, lo hayas solicitado tú o no.

Cómo funciona en realidad un registro de CT

Un registro de CT se construye como un árbol de Merkle: cada certificado nuevo enviado al registro se convierte en una hoja, y cada hoja se combina mediante hash con sus vecinas, capa tras capa, hasta un único hash raíz que representa todas las entradas que el registro ha contenido jamás. Cambia o elimina una sola entrada pasada y el hash raíz también cambia –un desajuste que cualquiera puede detectar comparando hashes. Esto es lo que «de solo adición» y «a prueba de manipulación» significan en la práctica: no es una promesa que hace el operador del registro, es una propiedad que impone la matemática.

Cuando una CA envía un certificado a un registro, el registro devuelve un Signed Certificate Timestamp (SCT): un recibo criptográfico que demuestra que el certificado se registró en un momento concreto. Los navegadores comprueban que exista un SCT válido (o varios, de registros independientes) antes de confiar en un certificado siquiera. Sin SCT, no hay confianza, sin importar lo legítimo que parezca el certificado por lo demás. Varios registros gestionados por organizaciones distintas y sin relación entre sí (Google, Cloudflare, DigiCert, Sectigo y otras) se supervisan mutuamente precisamente para que ningún operador pueda falsificar la historia en silencio sin que los demás se den cuenta.

Leer registros de CT tú mismo, con crt.sh

No necesitas ningún acceso especial para consultar estos datos: son públicos por diseño. crt.sh es la interfaz más fácil, consultable desde el navegador o la línea de comandos:

# Todos los certificados jamás registrados para un dominio, incluidos subdominios
$ curl -s "https://crt.sh/?q=%25.example.com&output=json" \
    | jq -r '.[] | "\(.not_before)  \(.name_value)"' \
    | sort -u
2024-02-11T00:00:00  api.example.com
2023-08-03T00:00:00  mail.example.com
2026-01-14T00:00:00  vpn.example.com

Esa misma consulta es exactamente lo que impulsa la técnica de enumeración pasiva de subdominios descrita en dominios vs subdominios: los registros de CT filtran infraestructura que nadie pretendía publicar, porque cada certificado nombra todos los nombres de host que cubre. Para un solo dominio, una búsqueda en el navegador en crt.sh/?q=example.com funciona igual de bien y no necesita ninguna herramienta.

Vigilar tu propio dominio

La utilidad práctica de CT no es solo la investigación histórica: es un sistema de alerta temprana. Como todo certificado nuevo de tu dominio se registra públicamente a los pocos minutos de su emisión, puedes vigilar la aparición de certificados que nunca solicitaste, una de las señales más claras posibles de una zona DNS comprometida, un subdominio secuestrado o una CA a la que engañaron para que emitiera algo que no debía.

• Comprobación manual periódica: busca crt.sh/?q=tudominio.com de vez en cuando y revisa si hay nombres que no reconoces.
• Vigilancia automatizada: servicios gratuitos de monitorización de CT (la herramienta de monitorización de CT de Facebook, watchers al estilo cert-manager, o un script programado que consulte la API JSON de crt.sh) pueden avisarte en cuanto aparezca un certificado nuevo, convirtiendo un descubrimiento que antes tardaba meses en uno que tarda minutos.

Esto cierra el círculo que DigiNotar dejó al descubierto: un certificado mal emitido todavía puede ocurrir, pero ya no puede ocurrir en silencio.

La conclusión

Un certificado TLS demuestra el control de un dominio en un momento dado –nada sobre intención, reputación o seguridad. La cadena de confianza que hay detrás depende de que las autoridades de certificación actúen con honestidad, que es precisamente la suposición que Certificate Transparency se construyó para dejar de dar por hecho: todo certificado, de toda CA, es ahora público, a prueba de manipulación y consultable a los pocos minutos de su emisión. Lee el candado por lo que realmente dice, no por lo que a menudo se asume que significa, y trata los registros de CT como una señal real más –junto con la antigüedad del dominio, el historial de WHOIS y los registros DNS– a la hora de decidir si un sitio es lo que dice ser.

Preguntas frecuentes