Cadena de confianza SSL: cómo funcionan las CA intermedias

⏱️ Lectura: 16 min

En 2026 el NVD catalogó CVE-2026-111943, un caso que vuelve a poner el foco en la autoridad certificadora intermedia, la pieza que sostiene la cadena de confianza SSL de miles de sitios. Cuando ese eslabón se compromete, el problema escala a todos los certificados que esa intermedia firmó, de golpe.

📑 En este artículo

1. TL;DR
2. ¿Qué es la cadena de confianza SSL?
3. Por qué importa que una CA intermedia se vea comprometida
4. Cómo se construye la jerarquía de autoridades certificadoras
5. Ejemplos prácticos: inspeccionar una cadena de certificados con OpenSSL
6. Cómo empezar: verificar una cadena de certificados desde tu terminal
7. Casos de uso reales de la jerarquía de autoridades certificadoras
8. Errores comunes al configurar una cadena de certificados
9. Comparativa: cómo se revoca o verifica un certificado
10. Profundizando: validación de rutas y el límite de la confianza en la jerarquía de autoridades certificadoras
11. Preguntas frecuentes
    1. ¿Qué diferencia hay entre una CA raíz y una CA intermedia?
    2. ¿Cómo se verifica la cadena de confianza SSL en un navegador?
    3. ¿Qué pasa si se revoca una CA intermedia?
    4. ¿Un certificado autofirmado tiene cadena de certificados?
    5. ¿Por qué los navegadores no confían directo en Let’s Encrypt?
    6. ¿Certificate Transparency reemplaza a la revocación con OCSP?
12. Referencias
    1. 📚 Artículos relacionados

Para entender qué significa en la práctica que una CA esté comprometida, hay que desarmar esa cadena: quién firma a quién, qué valida el navegador en cada conexión y qué pasa cuando hay que revocar un certificado en el medio de la jerarquía.

TL;DR

• Una CA intermedia firma en nombre de una raíz que el navegador ya trae instalada de fábrica.
• OCSP y CRL avisan que un certificado se revocó antes de que expire por sí solo.
• openssl s_client -showcerts muestra la cadena completa que envía un servidor, de la hoja a la raíz.
• Certificate Transparency registra en logs públicos cada certificado, así una intermedia maliciosa no pasa inadvertida.
• Comprometer una sola intermedia invalida de golpe todos los certificados que esa autoridad firmó.

¿Qué es la cadena de confianza SSL?

La cadena de confianza SSL es la secuencia de firmas digitales que conecta el certificado de un sitio web con una autoridad raíz que el sistema operativo o el navegador ya trae instalada, pasando por una o más autoridades certificadoras intermedias que delegan esa confianza sin exponer la clave raíz.

La raíz casi nunca firma certificados de sitios directamente: su clave privada se guarda offline, a menudo bajo múltiples custodios, porque si se filtra hay que reemplazarla en cada sistema operativo del planeta. Por eso existen las intermedias, que firman en nombre de la raíz; si una se compromete, basta revocarla a ella sin tocar la raíz.

Cada certificado de la cadena incluye el campo Issuer (quién lo firmó) y Subject (a quién pertenece). El navegador sigue esa cadena de Issuer en Issuer hasta topar con un Subject que ya figura en su almacén de confianza. Todo este mecanismo de raíces, intermedias y hojas es lo que se conoce como infraestructura de clave pública, o PKI por sus siglas en inglés.

Por qué importa que una CA intermedia se vea comprometida

Una intermedia comprometida afecta, de una sola vez, a todos los sitios que esa autoridad firmó, que pueden ser miles o millones según el tamaño de la CA. Un atacante con la clave privada de una intermedia puede emitir certificados válidos para cualquier dominio, incluyendo bancos, correo o infraestructura crítica, sin que el navegador note nada raro, porque la firma es matemáticamente correcta.

Con un certificado fraudulento válido, un atacante en una red wifi pública o con control de infraestructura de red puede interponerse entre el usuario y el sitio real, un ataque conocido como machine-in-the-middle, sin que aparezca ninguna advertencia. El candado se ve verde igual, porque la cadena de certificados que recibe el navegador es, técnicamente, válida.

El caso histórico que mejor ilustra el riesgo es DigiNotar, una CA holandesa comprometida en 2011: el atacante emitió certificados fraudulentos para dominios de Google, y los navegadores terminaron retirando por completo la confianza en esa autoridad. La empresa quebró meses después.

Quién decide qué raíces merecen ese nivel de confianza son los llamados root programs: Mozilla, el programa de raíces de Chrome y el de Apple publican sus propios criterios y auditan a cada CA con reportes anuales de WebTrust o ETSI. Una intermedia comprometida que no se gestiona con transparencia, sin reportar el incidente ni revocar a tiempo, puede costarle a toda la CA la expulsión de esos almacenes, no solo a la intermedia afectada.

Por eso la respuesta a una intermedia comprometida no es parchear el certificado: es revocarlo y, en los casos más graves, remover la raíz completa de los almacenes de confianza de Chrome, Firefox y los sistemas operativos. Eso vuelve inválidos de golpe todos los certificados emitidos bajo esa jerarquía, incluso los que no tenían nada que ver con el ataque.

Cómo se construye la jerarquía de autoridades certificadoras

La jerarquía tiene siempre tres niveles mínimos: la raíz (root CA), una o más intermedias, y el certificado hoja que recibe tu navegador cuando visitás un sitio. Algunas CAs grandes, como Let’s Encrypt, tienen varias intermedias activas en paralelo para repartir el riesgo y facilitar la rotación.

Cuando tu navegador se conecta a un servidor por HTTPS, el servidor le envía su certificado hoja junto con la cadena de intermedias necesaria para completar el camino hasta una raíz confiada. El navegador no se limita a confiar en lo que declara el servidor. Reconstruye el camino completo verificando cada firma con la clave pública del eslabón anterior, hasta llegar a una raíz que ya tenía guardada.

La clave privada de la raíz vive casi siempre dentro de un hardware security module (HSM) guardado en una caja fuerte, y firmar algo con ella es un evento ceremonial que requiere varias personas presentes, cámaras grabando y un guion escrito paso a paso. Por eso las raíces casi no firman nada directamente salvo, cada tanto, una nueva intermedia. Todo el trabajo diario de emitir certificados queda en manos de las intermedias, que corren en infraestructura online y por eso son, también, el objetivo más probable de un atacante.

Ese proceso de construir y validar la ruta se llama path building y está formalizado en el RFC 5280, que define cómo validar certificados X.509: fechas de validez, extensiones críticas, longitud máxima de la cadena (basicConstraints) y qué hacer si hay varias rutas posibles hasta una raíz confiada.

flowchart TD
    A["Autoridad raíz (en el almacén del SO)"] --> B["CA intermedia firma con su clave privada"]
    B --> C["Certificado hoja del sitio web"]
    C --> D["Navegador reconstruye y valida la cadena"]

Ejemplos prácticos: inspeccionar una cadena de certificados con OpenSSL

La forma más directa de ver esto en acción es con la terminal. El siguiente comando se conecta a un sitio real por TLS y muestra el subject y el issuer de cada certificado que el servidor envía:

echo | openssl s_client -connect www.google.com:443 -showcerts 2>/dev/null | openssl x509 -noout -subject -issuer

La salida sigue siempre este patrón, aunque los nombres concretos de la CA vigente cambian con el tiempo:

subject=CN = www.google.com
issuer=C = US, O = Google Trust Services, CN = WR2

El campo issuer de ese certificado hoja es, justamente, el subject de la CA intermedia que lo firmó. Si encadenás esa búsqueda, pedís el certificado cuyo subject coincide con ese issuer, y vas subiendo eslabón por eslabón hasta la raíz, exactamente como lo hace el navegador por dentro.

Para ver también las fechas de validez y dónde consultar la revocación:

echo | openssl s_client -connect www.google.com:443 -showcerts 2>/dev/null | openssl x509 -noout -dates -ext authorityInfoAccess

Eso muestra el rango de validez (notBefore y notAfter) y la URL del respondedor OCSP que el certificado declara, la misma que consulta tu navegador para saber si sigue vigente (los valores concretos cambian según la CA emisora):

notBefore=Jan 10 08:00:00 2026 GMT
notAfter=Apr 10 08:00:00 2026 GMT
Authority Information Access:
    OCSP - URI:http://ocsp.pki.goog/gts1c3

Para validar la cadena completa contra el almacén de confianza del sistema, sin mirar campo por campo, se usa:

openssl s_client -connect www.google.com:443 -verify_return_error </dev/null

Si todo está en orden, entre las últimas líneas aparece:

Verify return code: 0 (ok)

Un código distinto de 0 (por ejemplo 21 o 2) indica un problema puntual en la cadena: certificado expirado, emisor desconocido o intermedia faltante. Esa es, en la práctica, la forma de confirmar que una cadena de certificados es válida sin depender solo del ícono del candado del navegador.

Cómo empezar: verificar una cadena de certificados desde tu terminal

Dependencia única: tener OpenSSL instalado. Viene preinstalado en macOS y en casi todas las distribuciones de Linux; en Windows, la forma más simple es usar Git Bash o WSL, que lo incluyen de fábrica.

Primero confirmá la versión instalada:

openssl version

Salida esperada (el número exacto depende de tu sistema):

OpenSSL 3.0.13 30 Jan 2024

Después, descargá la cadena completa de un sitio a un archivo para inspeccionarla con calma:

echo | openssl s_client -connect www.google.com:443 -showcerts 2>/dev/null > cadena.txt

Abrí cadena.txt y vas a ver varios bloques -----BEGIN CERTIFICATE-----: el primero es la hoja, los siguientes son las intermedias que el servidor decidió enviar. Contalos: si el servidor es el tuyo y aparece un solo bloque, falta la intermedia, y ese es el error de cadena incompleta más común en producción.

Casos de uso reales de la jerarquía de autoridades certificadoras

Let’s Encrypt emite certificados gratuitos desde 2015 y lo hace exclusivamente a través de intermedias, con ISRG Root X1 como raíz y varias intermedias rotando debajo. Nunca firma un certificado de sitio directo con la raíz, el mismo patrón de aislamiento que separa el riesgo del día a día de la clave que, si se pierde, obliga a reconstruir la confianza de internet entero.

Automatizar la renovación es parte del diseño: el protocolo ACME que usa Let’s Encrypt, y que adoptaron otras CAs, permite renovar un certificado con un comando como certbot renew, sin intervención humana, porque sus certificados valen apenas 90 días. Una validez corta reduce la ventana de daño de un certificado mal emitido, porque expira en semanas en lugar de los uno o dos años que eran comunes antes.

Los bancos y la infraestructura crítica suelen pedir, además de la cadena estándar, Certificate Transparency: un registro público e inmutable de cada certificado emitido por cualquier CA reconocida. Si una intermedia comprometida emite un certificado falso para un dominio, ese certificado queda anotado en los logs de CT, y herramientas de monitoreo, incluidas las que ofrecen gratis Google y Cloudflare, pueden avisar en minutos aunque el ataque nunca haya tocado esa infraestructura.

Errores comunes al configurar una cadena de certificados

• Cadena incompleta: el servidor manda solo el certificado hoja y olvida las intermedias; funciona en navegadores que cachean intermedias conocidas y falla en apps móviles o en curl.
• Orden incorrecto: algunos servidores viejos esperan la cadena en un orden específico y, si se invierte, rompe la validación en clientes TLS estrictos.
• OCSP soft-fail: si el respondedor de revocación no contesta a tiempo, la mayoría de los navegadores deja pasar la conexión en lugar de bloquearla, por diseño, para no tumbar internet cada vez que un respondedor se cae.
• Reloj desincronizado: un certificado marcado como no válido todavía o expirado casi siempre es la hora del sistema, no el certificado.
• Confundir expiración con revocación: un certificado expirado simplemente venció su fecha; uno revocado fue invalidado antes de tiempo por la CA, y los navegadores tratan ambos casos distinto sin siempre aclararlo en el mensaje de error.

⚠️ Ojo: el soft-fail de OCSP significa que, en la práctica, revocar un certificado no garantiza bloquear al atacante de inmediato, porque muchos clientes seguirán aceptándolo si no pueden consultar el estado de revocación a tiempo.

Comparativa: cómo se revoca o verifica un certificado

Ninguno de estos mecanismos compite con los demás: en la práctica se combinan, y entender cuándo entra cada uno ayuda a diagnosticar por qué un navegador bloquea, o no bloquea, una conexión sospechosa.

Profundizando: validación de rutas y el límite de la confianza en la jerarquía de autoridades certificadoras

El algoritmo que corre el navegador en cada conexión se llama certification path validation y está descripto en detalle en el RFC 5280. No se limita a verificar firmas: también chequea que cada CA intermedia tenga el bit basicConstraints: CA=TRUE, que no se haya excedido la profundidad máxima de la cadena (pathLenConstraint) y que ningún certificado de la ruta esté marcado como revocado.

Dos campos clave amarran un eslabón con el siguiente: el Subject Key Identifier (SKI) de la CA que firma, y el Authority Key Identifier (AKI) del certificado firmado, que debe apuntar exactamente a ese SKI. Cuando una raíz se renueva con una clave nueva, las intermedias viejas dejan de encadenar hasta que alguien las vuelve a firmar bajo esa clave, un proceso llamado cross-signing que usan las CAs grandes para no romper la compatibilidad de golpe.

Un caso real de cross-signing: durante años, Let’s Encrypt firmó su raíz ISRG Root X1 también bajo una raíz más vieja, DST Root CA X3, para que los Android desactualizados, que no tenían la raíz nueva instalada, igual pudieran validar la cadena. Cuando esa raíz vieja expiró, algunos dispositivos sin soporte quedaron sin forma de confiar en esos certificados. Simplificar la cadena tiene ese costo: a veces deja atrás a quien no actualiza.

Las versiones recientes de Chrome y Safari ya exigen, además de la cadena válida, que cada certificado tenga su Signed Certificate Timestamp (SCT) de al menos dos logs de Certificate Transparency distintos. Sin eso, el navegador trata la conexión como no confiable aunque la firma sea técnicamente correcta: es la capa que cierra el hueco que dejaba una intermedia comprometida emitiendo en silencio.

sequenceDiagram
    participant N as Navegador
    participant S as Servidor
    participant O as Responder OCSP
    N->>S: inicia el handshake TLS
    S-->>N: envía certificado hoja e intermedia
    N->>N: construye la cadena hasta la raíz confiada
    N->>O: consulta estado de revocación
    O-->>N: responde válido o revocado
    Note over N,S: si la cadena o el OCSP fallan, el navegador aborta la conexión

📖 Resumen en Telegram: Ver resumen

Tu próximo paso: corré openssl s_client -connect tu-dominio.com:443 -showcerts contra un sitio propio y contá cuántos certificados devuelve antes de asumir que la cadena está completa.

Preguntas frecuentes

¿Qué diferencia hay entre una CA raíz y una CA intermedia?

La raíz es la autoridad que los navegadores y sistemas operativos confían de fábrica, con su clave privada guardada offline. La intermedia es una autoridad que la raíz firmó para que emita certificados del día a día, delegando la confianza sin exponer la clave raíz.

¿Cómo se verifica la cadena de confianza SSL en un navegador?

El navegador reconstruye la ruta desde el certificado del sitio, verificando cada firma con la clave pública del eslabón anterior, hasta llegar a una raíz que ya tiene en su almacén. Si no completa la ruta, muestra una advertencia de certificado no confiable.

¿Qué pasa si se revoca una CA intermedia?

Todos los certificados que esa intermedia firmó dejan de ser válidos de inmediato, aunque individualmente no tuvieran ningún problema. Por eso las CAs grandes reparten la emisión entre varias intermedias: si una cae, el daño se limita a su porción del tráfico.

¿Un certificado autofirmado tiene cadena de certificados?

No: un certificado autofirmado es su propio issuer y su propio subject, sin ningún eslabón intermedio ni raíz externa que lo respalde. Por eso el navegador lo marca como no confiable salvo que lo hayas agregado manualmente al almacén local.

¿Por qué los navegadores no confían directo en Let’s Encrypt?

Sí confían, pero a través de su jerarquía: la raíz ISRG Root X1 está en los almacenes de confianza desde hace años, y Let’s Encrypt firma cada certificado con una intermedia que cuelga de esa raíz, nunca con la raíz misma.

¿Certificate Transparency reemplaza a la revocación con OCSP?

No, son complementarios: CT expone públicamente que un certificado existe, pero no dice si está revocado. OCSP y OCSP stapling son los que comunican el estado de revocación en tiempo real.

Referencias

• NVD, CVE-2026-111943: registro oficial de la vulnerabilidad que motiva este artículo.
• RFC 5280 (IETF): especificación de certificados X.509 y validación de rutas de confianza.
• Let’s Encrypt, How It Works: cómo una CA gratuita emite certificados a través de intermedias.
• Wikipedia, DigiNotar: el caso histórico de una CA intermedia comprometida en 2011.
• MDN, Transport Layer Security: documentación de referencia sobre TLS y certificados.

📱 ¿Te gusta este contenido? Únete a nuestro canal de Telegram @programacion donde publicamos a diario lo más relevante de tecnología, IA y desarrollo. Resúmenes rápidos, contenido fresco todos los días.

Imagen destacada: Foto de FlyD en Unsplash