CA intermedia comprometida: cuando la confianza se rompe

Aquí va una opinión que suena al revés: los peores incidentes con autoridades de certificación no son los que implican que un atacante logró entrar. El reciente compromiso de la CA intermedia de eMudhra lo demuestra: ocho claves de CA intermedias eran recuperables a partir de los propios certificados, sin ninguna intrusión, porque la ceremonia de generación de claves de la propia CA produjo claves privadas tan débiles que una de ellas era literalmente el número 4. Nadie robó esas claves. Nacieron comprometidas. Y eso es un modo de fallo más aterrador que cualquier brecha, porque no se arregla rotando credenciales y parcheando un agujero. La confianza en sí estaba defectuosa desde el primer día.

Si tienes algo que establece conexiones TLS fuera de un navegador, y lo tienes, este caso merece tu atención. Los navegadores quedaron protegidos en cuestión de días. El resto del ecosistema, las llamadas a curl en tus cron jobs, los servicios en Python que fijan certifi, los binarios de Go con almacenes raíz incrustados, todavía se están poniendo al día. Voy a repasar qué pasó realmente, por qué el compromiso de una intermedia es categóricamente peor que el de un certificado hoja, y qué nos dice la remediación desigual sobre el estado de la revocación en la internet moderna.

Qué salió mal realmente en eMudhra

Según la evaluación preliminar de la propia CA en el rastreador de incidentes de Mozilla, la historia es casi dolorosamente mundana. Un script de la ceremonia de generación de claves, el proceso controlado y auditado mediante el cual una CA crea sus claves más sensibles, fue modificado con una desviación aprobada para probar un procedimiento de envoltura y desenvoltura de claves para exportación. Un fallo en ese código modificado provocó que se generara en el HSM un segundo conjunto de claves ECC, y esas claves eran débiles. No «entropía reducida» débiles. Débiles hasta el punto de poder recuperarse a partir del propio certificado público.

Piensa en lo que eso significa. Una clave privada ECC debería ser un número aleatorio de 256 bits. La seguridad de todo el esquema descansa en el problema del logaritmo discreto: dada la clave pública, encontrar el escalar privado debería ser computacionalmente inviable. Pero si tu «aleatorio» es un único byte, la clave pública es simplemente el punto generador multiplicado por ese byte, y cualquiera puede probar las 256 posibilidades en microsegundos en un portátil. Según se informó, una de las ocho claves era el entero 4. Eso no es un compromiso en el sentido tradicional; es un certificado que nunca fue realmente seguro, emitido bajo una raíz en la que confían Mozilla, Microsoft, Apple y Chrome.

El investigador que lo reportó, identificado como Wayne, demostró la posesión firmando un mensaje con cada una de las ocho claves privadas y enviando las firmas a los programas de raíces. Cualquiera podía verificar la prueba con un par de comandos de OpenSSL: extraer la clave pública de cada certificado intermedio y comprobar que la firma del mensaje verifica contra ella. Eso es lo elegante y lo aterrador de la prueba criptográfica de posesión de clave: no hay ambigüedad, ni niebla de relaciones públicas del tipo «nos tomamos la seguridad muy en serio». Las matemáticas cuadran o no cuadran. Cuadraron.

Por qué el compromiso de una CA intermedia es peor que el de un certificado hoja

Cuando se filtra la clave privada de un certificado hoja, digamos que tu clave de api.example.com acaba en un repositorio público de GitHub, el radio de impacto es un solo nombre de host, quizá unos pocos si es un comodín. Revocas el certificado, emites uno nuevo y sigues adelante. Molesto, pero no existencial.

Una clave de CA intermedia es un animal completamente distinto. La PKI web funciona como una cadena de firmas: una CA raíz (mantenida offline, protegida como material nuclear) firma las intermedias, y las intermedias firman los certificados hoja que los servidores presentan realmente. Quien posea la clave privada de una intermedia es esa CA, a todos los efectos criptográficos. Puede emitir un certificado válido para google.com, para tu banco, para tu dominio de SSO interno, y cada cliente que confíe en la cadena lo aceptará sin quejarse. No hay límite de tasa, no hay una autoridad central a la que llamar, no hay forma de distinguir una firma fraudulenta pero válida de una legítima.

El incidente de eMudhra multiplicó esto por ocho intermedias, algunas firmadas cruzadamente a través de raíces de Sectigo, encadenadas a almacenes de confianza distribuidos en miles de millones de dispositivos. Durante aproximadamente un año y medio, desde que se crearon los certificados defectuosos hasta su divulgación, cualquier cliente que confiara en esas intermedias y no aplicara Certificate Transparency podía ser suplantado por cualquiera que se molestara en recuperar las claves. Esa es la ventana. No sabemos si alguien la explotó y, sin una detección afortunada en un log de CT o un ataque observado, quizá nunca lo sabremos.

Por eso los programas de raíces tratan los incidentes en intermedias con una gravedad que los incidentes en certificados hoja nunca reciben. Desconfiar de una intermedia significa que cada certificado que alguna vez emitió se vuelve inválido: miles de sitios web rompiéndose a la vez. La saga de la desconfianza hacia Symantec, que se desarrolló durante años, es el ejemplo canónico de lo dolorosa que resulta una remediación completa cuando las operaciones de una CA se consideran no confiables. El sistema funciona, pero funciona como una amputación, no como una cirugía.

Certificate Transparency fue el héroe accidental

La parte de la historia que merece más atención: Chrome, Safari, Firefox y Edge estaban, discutiblemente, protegidos antes de que nadie supiera que había un problema. No gracias a la revocación, sino gracias a Certificate Transparency.

Los navegadores que aplican CT exigen que cada certificado de confianza pública que aceptan esté registrado en logs de CT públicos y de solo adición. Las intermedias de eMudhra comprometidas no tienen entradas en logs de CT para el periodo en cuestión, lo que significa que cualquier certificado hoja que un atacante hubiera emitido con esas claves habría sido rechazado por clientes que aplican CT, porque habría llegado sin los certificate timestamps firmados válidos (SCT). El fraude tendría que haberse publicado para ser creído, y publicarlo lo habría expuesto de inmediato.

CT se diseñó para detectar emisiones incorrectas a posteriori, para que los certificados falsos fueran detectables. En este incidente funcionó como un control preventivo: hizo que las claves comprometidas fueran casi inútiles contra la población de navegadores, que es el conjunto de objetivos de mayor valor para la interceptación masiva. Es una buena noticia genuina para una pieza de infraestructura en la que la mayoría de los ingenieros nunca piensan.

Pero, y aquí es donde reconozco los límites de mi optimismo, la aplicación de CT es esencialmente un lujo de los navegadores. La gran mayoría de los clientes TLS de internet no comprueban los SCT. Tu invocación de curl no lo hace. Tu llamada de Python requests tampoco. La flota de IoT que se conecta a la nube de un proveedor tampoco. Para todos ellos, la única protección era que los datos de revocación llegaran al almacén de confianza a tiempo, y ahí es donde la historia se pone fea.

La brecha de revocación: navegadores frente a todo lo demás

Los proveedores de navegadores gestionaron esto bien, y merecen crédito por una infraestructura construida hace una década. Mozilla lleva más de diez años desplegando OneCRL, un mecanismo push para desconfiar de certificados intermedios y raíz, y remedió este incidente para los usuarios de Firefox en cuestión de horas, sin necesidad de actualizar el navegador. CRLSets de Chrome y los mecanismos equivalentes de Apple hicieron lo mismo en sus plataformas en pocos días. La CA revocó las intermedias. Desde la perspectiva de un usuario de navegador, este incidente terminó casi antes de empezar.

Ahora mira el mundo que no es navegador. La lista de remediación parece un inventario de la cadena de suministro de software: paquetes ca-certificates actualizados para Ubuntu, Debian, Fedora, Alpine, Arch, Gentoo; una nueva versión de NSS; un nuevo bundle de CA para curl; certifi para Python; rustls-webpki y webpki-roots para Rust; versiones menores de Go; versiones de parche de Electron en tres líneas de lanzamiento; ca-bundle de Composer; castore de Elixir. Cada uno de ellos es un artefacto separado, con un calendario de lanzamientos separado, consumido por un mecanismo de actualización separado. Algunos seguían pendientes días después de la divulgación.

Y luego está la categoría que me quita el sueño: software que incluye su propio almacén de CA dentro del binario. Un servicio de Go enlazado estáticamente y compilado el año pasado lleva sus raíces en el artefacto compilado. Reconstruirlo y redesplegarlo es la única solución: no hay ningún paquete del sistema que parchear. Multiplícalo por cada imagen de contenedor de tu registro con una capa /etc/ssl/certs incrustada, cada aplicación de Electron en cada escritorio y cada imagen de firmware en cada dispositivo conectado, y verás la forma del problema. El almacén de confianza del sistema es la parte fácil. Ya hemos escrito antes sobre cómo los dispositivos embebidos y OT convierten los incidentes de seguridad en sagas de varios años; una CA comprometida es exactamente el tipo de evento en el que esos dispositivos simplemente nunca se arreglan.

La larga cola de almacenes de confianza que nadie posee

Hay un caso especial en este incidente que merece su propio párrafo porque es tan perfectamente ilustrativo: macOS. La plataforma de Apple bloqueó rápidamente las intermedias comprometidas a nivel del sistema operativo. Pero el /usr/bin/curl incluido verifica contra /etc/ssl/cert.pem, un archivo que no se actualizó, y no comprueba la revocación. Así que podías tener un Mac totalmente parcheado donde Safari rechaza un certificado falsificado y el curl de esa misma máquina lo acepta sin problemas. Dos decisiones de confianza, una máquina, respuestas opuestas.

Esta fragmentación es la verdadera lección. Solemos hablar de «la PKI web» como si fuera un solo sistema. Son decenas de sistemas con propiedades muy distintas:

• Navegadores: revocación push (OneCRL, CRLSets), aplicación de CT, actualizaciones automáticas. Remediación medida en horas o días.
• Almacenes de confianza del SO: actualizaciones gestionadas por el gestor de paquetes (ca-certificates, ca_root_nss). La remediación depende del ritmo de lanzamientos de la distribución y de si la máquina llega a parchearse alguna vez.
• Ecosistemas de lenguajes: certifi, webpki-roots, las raíces embebidas de Go, el almacén de Mozilla incluido en Node. La remediación implica publicar una versión y esperar a que se actualicen las dependencias en miles de proyectos.
• Artefactos compilados e imágenes: binarios, contenedores, firmware. La remediación implica reconstruir y redesplegar, lo que en la práctica significa una larga cola vulnerable que se extiende durante años.
• IoT y embebidos: a menudo no tienen ninguna vía de actualización. Exposición efectivamente permanente.

Los navegadores llevan una década invirtiendo exactamente en este escenario. Casi nadie más lo ha hecho. Un comentario de un miembro del lado de Mozilla lo resumió sin rodeos: fuera del ecosistema de navegadores ha habido poca o ninguna inversión en revocación, y para esos clientes este tipo de incidente es un problema enorme. Eso coincide con todo lo que he visto ejecutando infraestructura. Si has lidiado con los puntos ciegos en cómo se registran los eventos de autenticación en la nube, reconocerás el patrón: la ruta crítica está bien instrumentada y la larga cola es una habitación a oscuras.

Cómo comprobar si tus clientes siguen siendo vulnerables

Dejando la teoría de lado, deberías probar realmente tu parque de sistemas, y lo bueno de TLS es que puedes probarlo empíricamente. Miembros de la comunidad levantaron hosts que sirven certificados firmados por las intermedias comprometidas; si tu cliente se conecta sin error de certificado, sigue confiando en ellas. El patrón general para probar curl o cualquier herramienta de línea de comandos es el siguiente:

# A certificate error here means you're protected.
# A successful response means this client still trusts a compromised intermediate.
curl -v https://dv-g3b-emudhra.we-have-a-problem.com/
# You can also test whether a client will accept a forged cert for an
# arbitrary hostname by pointing it at a test server:
curl -v https://example.org --connect-to example.org::2.29.126.86:

Ejecútalo desde todos los contextos que importan: tus portátiles de desarrollo, tus runners de CI, las imágenes base de tus contenedores, tus flotas de servidores. La respuesta variará entre ellos, y esas diferencias son justamente el punto. Para un inventario rápido de lo que hay que actualizar:

• Servicios en Go: recompila con Go 1.27.3 o 1.26.10 o posterior, porque las raíces están compiladas dentro.
• Python: certifi 2026.10.19 o posterior (revisa también las versiones de pip y uv, que incluyen su propio bundle).
• Rust: rustls-webpki 0.103.16 y webpki-roots / webpki-root-certs 1.0.10.
• Node.js y Electron: versiones pendientes o de parche por línea de lanzamiento; revisa cada artefacto distribuido.
• Almacenes del sistema: los paquetes ca-certificates actualizados ya están disponibles para Ubuntu, Debian, Fedora, Alpine, Arch y Gentoo; el ca_root_nss de FreeBSD seguía pendiente en el momento de escribir esto.

Si no puedes esperar a un paquete, la mayoría de las distros de Linux te permiten desconfiar manualmente de las raíces afectadas. En Debian/Ubuntu basta con marcar los certificados con un prefijo ! en /etc/ca-certificates.conf y ejecutar update-ca-certificates; en la familia Fedora/RHEL extraes las raíces a /etc/pki/ca-trust/source/blocklist/ y ejecutas update-ca-trust. NixOS tiene una opción declarativa limpia:

security.pki.caCertificateBlacklist = [
"Comodo AAA Services root"
"emSign ECC Root CA - G3"
];

Fíjate en lo que realmente estás desconfiando con estas soluciones alternativas: las raíces a las que se encadenan esas intermedias. Esa es la realidad de herramienta contundente de la remediación de PKI. En la mayoría de herramientas de almacenes de confianza no existe una primitiva del tipo «desconfiar solo de esta intermedia», así que pones en la lista de bloqueo una raíz y aceptas el daño colateral sobre certificados no relacionados. Es la decisión correcta en una emergencia, pero sigue siendo una decisión de compromiso.

Dónde se rompe mi afirmación contraria

Empecé argumentando que los fallos de generación de claves autoinfligidos son peores que las brechas. Permíteme ser honesto sobre dónde eso se rompe. Una brecha tradicional, piensa en DigiNotar, al menos implica que la CA operaba con competencia hasta que un atacante la superó, y las CA competentes son lo que todo el sistema da por supuesto. Una ceremonia de claves que emite la clave privada «4» implica que los controles auditados, los procedimientos del HSM y las casillas de cumplimiento normativo no detectaron un defecto catastrófico en la operación más sensible que realiza una CA. Eso no es un problema de adversario; es un problema de aseguramiento, y el aseguramiento es todo el producto que vende una CA.

Donde la afirmación realmente falla: las brechas son más difíciles de defender y pueden permanecer silenciosas durante más tiempo. Un atacante que robe con cuidado la clave de una intermedia podría usarla con moderación para interceptaciones dirigidas y nunca tocar un cliente que aplique CT. Las claves débiles, en cambio, son descubribles por cualquiera que escanee certificados públicos, que es precisamente como salió a la luz este caso. Hay un argumento de que lo catastrófico pero obvio supera a lo sutil pero dirigido. No lo compro del todo, pero tampoco puedo descartarlo. La verdad es que ambos modos de fallo acaban en el mismo sitio: una intermedia que debe ser desconfiada, y una larga cola de clientes que no se enterarán durante meses.

Qué deberías hacer realmente al respecto

No puedes arreglar la PKI web. Sí puedes reducir tu exposición a su próximo fallo:

• Prueba, no supongas. Sondea tus clientes contra hosts que sirven las cadenas comprometidas. Esto lleva una tarde y te sorprenderá.
• Reconstruye los artefactos compilados. Los binarios de Go y las imágenes de contenedor llevan consigo sus almacenes de confianza. «Parcheamos la imagen base» no significa nada hasta que redespliegas.
• Inventaría tus almacenes de confianza. No puedes remediar lo que no has enumerado. Cuenta las copias de certifi, los bundles incrustados y las aplicaciones Electron como si importaran, porque sí importan.
• Prefiere los almacenes de confianza del sistema siempre que puedas. Cada bundle incrustado es un parche que olvidarás distribuir. Centralizar en el almacén del SO no elimina el problema, pero te da un único punto de control.
• Vigila el ecosistema de CT y revocación. Existen proyectos que buscan llevar una revocación de calidad de navegador a los clientes que no son navegadores, y merecen apoyo; este incidente es el mejor argumento que tendrán para conseguir financiación.
• Trata los incidentes de CA como incidentes de seguridad. Deberían avisar a alguien, activar un inventario y generar un registro escrito, igual que una credencial filtrada. Porque eso es lo que son.

El resumen incómodo: el freno de emergencia de la PKI web funciona de maravilla justo en los clientes que menos lo necesitaban, porque CT ya los tenía cubiertos. Los clientes que necesitaban el freno, headless, embebidos, incrustados o olvidados, en su mayoría no tienen ninguno. La próxima vez que una CA intermedia se vea comprometida es cuestión de cuándo, no de si. La única variable bajo tu control es si tu propio parque de sistemas se da cuenta.