> ## Content Index
> Fetch the complete content index at: https://blog.ifirestone.dev/llms.txt
> Use this file to discover other available public pages before exploring further.

# Ocho claves de CA, una de ellas el número 4: lo que enseña el incidente de eMudhra sobre los trust stores
- URL: https://blog.ifirestone.dev/ocho-claves-de-ca-una-de-ellas-el-numero-4-lo-que-ensena-el-incidente-de-emudhra-sobre-los-trust-stores/
- Published: 2026-10-25T02:57:49.000Z
- Updated: 2026-10-25T02:57:49.000Z
- Description: Ocho claves de autoridades certificadoras se podían adivinar en menos de un segundo, y una era el número 4. Qué pasó, cómo respondieron los navegadores y Cloudflare, y qué revisar en tus propios trust stores.
- Author: Ivan Firestone
- Tags: security, devops, software-engineering, #spanish

La clave privada de una autoridad certificadora debería ser un número tan grande que adivinarlo llevaría más tiempo que la vida del sol. El 17 de octubre de 2026, un investigador demostró que una de las de eMudhra era el número 4.

No un 4 seguido de unos cientos de dígitos. Solo un 4.

Este artículo trata de lo que eso significa para el código que ejecutas, no para la pestaña del navegador en la que lees esto. Dejo fuera la discusión sobre si eMudhra merece un lugar en los programas de certificados raíz, porque eso les corresponde a quienes gestionan esos programas. Lo que quiero cubrir es la distancia entre "Chrome lo bloqueó" y "mi servicio lo bloquea", porque en esa distancia vivimos casi todos.

## Ocho claves que se cuentan con los dedos

Las claves afectadas pertenecían a ocho certificados intermedios, generados en una ceremonia de claves (key ceremony, el acto formal en que se genera y custodia la clave de una CA) en abril de 2025\. Seis eran para TLS y dos para firma de código. Las claves privadas resultaron ser enteros pequeños: 4, 56, 66, 115, 155, 156, 230 y 237, según [The Register](https://www.theregister.com/security/2026/10/22/disgraced-indian-cert-issuer-leaves-the-cert-issuing-business/5304848?ref=blog.ifirestone.dev) (en inglés). Cualquiera podía recuperarlas a partir de los certificados públicos en menos de un segundo.

Un repaso rápido de por qué importa. Una CA intermedia es la que firma los certificados que tus servidores presentan en la práctica. Quien tenga su clave privada puede emitir un certificado para cualquier dominio, y todo cliente que confíe en esa cadena lo aceptará. Piensa en un sello de lacre cuyo dibujo cualquiera puede redibujar a partir de una foto del sello.

Aquí no se robó nada. [iTnews](https://www.itnews.com.au/news/cloudflare-warns-fixing-botched-emudhra-certs-goes-beyond-browsers-629804?ref=blog.ifirestone.dev) (en inglés) lo dijo bien: no hizo falta robar nada para crear el fallo. eMudhra afirma que un error en su ceremonia de generación de claves hizo que un paso de wrap/unwrap produjera un segundo juego de claves débiles junto a las fuertes que pretendía, y que las débiles fueron las que se enviaron a los programas de certificados raíz de los navegadores. También dice que las CA afectadas no emitieron certificados de entidad final, que las revocó en 14 horas desde que descubrió el problema y que su infraestructura y sus datos no se vieron comprometidos. ***No puedo verificar esas afirmaciones por mi cuenta.*** Lo público son los certificados, y si alguien usó las claves en los aproximadamente 18 meses previos al reporte es, hasta donde sé, algo que se desconoce.

Así que esto no fue un hackeo. Fue un mal número a la vista de todos durante año y medio. Lo que lleva a la siguiente pregunta: quién se enteró y con qué rapidez reaccionó el mundo.

## Cinco días, cuatro fabricantes

El reporte llegó a los programas de certificados raíz de los navegadores el 17 de octubre. Chrome bloqueó los certificados ese mismo día mediante su mecanismo CRLSet, y Firefox hizo lo mismo con OneCRL. Microsoft siguió el 20 de octubre. iTnews afirma que los dispositivos Apple estaban protegidos desde el 19 de octubre, mientras que el aviso que cito más abajo indica el 22\. No pude conciliar ambas fechas.

El reloj de Cloudflare empezó más tarde. Su [post del incidente](https://blog.cloudflare.com/emudhra-certificate-compromise/?ref=blog.ifirestone.dev) (en inglés) dice que se enteró hacia las 17:00 UTC del 19 de octubre. A partir de ahí el trabajo siguió un orden claro:

- Primero, los servicios que usan certificados públicos para autenticar endpoints remotos: proxies que se conectan a orígenes y aplicaciones que llaman a APIs externas.
- Después, los trust stores compartidos y las imágenes base, para que todo lo que hereda confianza de ellos recibiera la corrección, seguido de los reinicios y despliegues de imágenes necesarios para activarla.
- Las aplicaciones con trust stores propios o personalizados se evaluaron aparte.

La cronología publicada: actualizaciones del cliente WARP a las 02:00 UTC del 20 de octubre, la actualización de cloudflared a las 09:15, y las mitigaciones de CDN y de Zero Trust del lado del servidor desplegadas por completo a las 19:20\. Cloudflare reportó que no hubo explotación activa en sus servicios. También subrayó que es un problema de autenticación de certificados, no una debilidad en los algoritmos de cifrado TLS.

Luego vino la frase que más importa para el resto de nosotros: algunos clientes tienen que actuar sobre software o configuraciones de confianza que operan ellos mismos, sobre todo en los servidores de origen. ¿Por qué un borde ya parcheado dejaría algo por hacer?

## El navegador tiene un interruptor. Tu servicio no.

Los fabricantes de navegadores lo resolvieron "con solo accionar un interruptor", como lo expresó Cloudflare (leyendo entre lineas), porque los navegadores tienen canales de revocación rápidos como los CRLSets, que empujan un bloqueo a todos los usuarios sin ciclo de actualización. Además, tienen una aplicación que arreglar, no cientos.

Todo lo demás (tu cliente HTTP, tu runtime, tu imagen de contenedor, el bundle de CA que trae una herramienta) tiene su propia idea de en quién confiar. iTnews lo probó en macOS: ***curl*** siguió aceptando certificados de la cadena comprometida después del bloqueo de Apple, porque curl comprueba contra su propio archivo en `/etc/ssl/cert.pem` sin consultar información de revocación. El aviso de Jackson dice que ese mismo archivo alimenta a git, python3, perl, ruby y openssl, los que vienen incluidos en macOS. Dennis Jackson, de Mozilla, quien publica el aviso enlazado más abajo, sugirió quitar dos raíces de ese archivo como solución provisional: la emSign ECC Root CA - G3 de eMudhra y la raíz AAA Certificate Services. Sectigo había hecho la firma cruzada de algunos de los intermedios débiles. Mozilla está retirando ahora la confianza en la raíz emSign por completo, y Chrome se ha comprometido a un camino similar.

Una advertencia sobre esa solución provisional, y esta parte es mi criterio, no el de Jackson. Quitar una raíz muy usada de un bundle compartido no sale gratis. Pruébalo contra los servicios que llamas antes de desplegarlo. El propio aviso trata estos pasos como provisionales y los da por plataforma: macOS, Linux, Windows, Android y los BSD. Califica el enfoque de Linux, dejar de confiar en las raíces mediante la lista de bloqueo de la distribución, como solo para expertos, y advierte que desactivar la raíz AAA Certificate Services en Android puede romper sitios que aún encadenan a ella.

Hay otra razón por la que los navegadores lo tuvieron más fácil, y está en el mismo aviso. Ninguno de los intermedios débiles tiene una entrada correspondiente en los logs de Certificate Transparency (CT), así que los navegadores que exigen CT no podrían haber sido atacados con certificados de estas claves. Los clientes que no exigen CT, entre ellos muchos clientes HTTP de backend, no tuvieron ese colchón. El 22 de octubre Jackson añadió a su verificador dos hosts de prueba "No CT", para ver si un cliente acepta certificados que nunca se registraron.

Imagina un job de backend que llama a la API de un socio desde una imagen de contenedor construida hace seis meses. Abres el sitio del socio en tu navegador, ves el candado y concluyes que todo está bien. El contenedor nunca se enteró del 17 de octubre. Esa es la distancia.

## Qué revisar el lunes

Empieza por averiguar quién verifica certificados en tu stack. El consejo de Cloudflare para desarrolladores es mirar por debajo del SDK: un cliente de API puede delegar la verificación en una librería HTTP, en el runtime del lenguaje, en el sistema operativo o en una configuración de confianza propia, así que actualizar solo el SDK puede no cambiar nada.

Luego ve lugar por lugar:

1. **Imágenes base de contenedores.** Reconstruye desde una base nueva y vuelve a desplegar. Una imagen nueva en disco no hace nada por un contenedor que sigue ejecutando la anterior.
2. **Trust stores del sistema.** En imágenes basadas en Debian puedes al menos ver si las raíces emSign siguen instaladas. Tómalo como punto de partida, no como veredicto, porque la corrección puede estar en un store o verificador actualizado y no en la ausencia de la raíz.
3. **Archivos de CA propios de cada herramienta.** Herramientas como curl que traen su propio bundle necesitan su propia actualización.
4. **Configuración de mTLS.** Revisa en qué CA confías para verificar certificados de cliente. Confía en las que de verdad usas para emitir, no en un bundle público completo, si tus integraciones lo permiten. Te cuesta flexibilidad cuando un socio cambia de CA.
5. **Certificados de origen.** Si usas los modos Full (strict) o Strict de Cloudflare, revisa tus certificados de origen personalizados. Cloudflare dice que Automatic SSL/TLS te avisará si sigues usando los que ya no son de confianza.

```bash
# Imagen basada en Debian/Ubuntu: ¿siguen instaladas las raíces emSign?
ls /etc/ssl/certs | grep -i emsign

# Reconstruye desde una imagen base nueva y vuelve a desplegar
docker build --pull --no-cache -t myapp:fixed .

```

Cuando apliques el parche, puede que empieces a ver errores de certificado en tus paneles. La advertencia de Cloudflare aquí es directa y la comparto: no los resuelvas desactivando la verificación.

```python
# Tentador a las 2 a. m. cuando una llamada empieza a fallar. No lo hagas.
requests.get(url, verify=False)

```

Esa línea elimina justo la autenticación que la actualización debía restaurar. Averigua qué cadena presenta en realidad la llamada que falla y corrige el trust store.

Por último, prueba por el camino que tu aplicación usa de verdad. El [sitio de pruebas](https://emudhra.we-have-a-problem.com/?ref=blog.ifirestone.dev) de Jackson cubre navegadores y clientes que no son navegadores. Lee con cuidado un fallo, porque la página advierte que un error de red se ve igual que un rechazo de certificado. El aviso que hay detrás también sigue las versiones corregidas en distribuciones de Linux, bundles de CA como certifi, runtimes de lenguajes (entre ellos Node.js, Python y Go) y herramientas como Docker. Algunas son dependencias indirectas, así que revisa tu árbol de dependencias. Trátala como tu tabla de consulta, y trata sus entradas pendientes como abiertas: cuando la leí el 24 de octubre, algunas seguían marcadas como pendientes, por ejemplo RHEL 7 y Bottlerocket. Cloudflare es explícito en que una prueba exitosa en el navegador no demuestra que un servicio en segundo plano esté a salvo, y una prueba con curl tampoco, si la aplicación usa otro verificador.

Si usas Tunnel y WARP como describí en [Exponer entornos de desarrollo con Cloudflare Tunnel y WARP sin abrir puertos](https://blog.ifirestone.dev/exponer-entornos-de-desarrollo-con-cloudflare-tunnel-y-warp-sin-abrir-puertos/), actualiza cloudflared a 2026.10.2 y aplica las actualizaciones correspondientes del cliente WARP. El post de Cloudflare lista las versiones corregidas por plataforma.

## Lo que costó y lo que deja

El 22 de octubre, eMudhra anunció que sale del negocio global de certificados SSL/TLS. Su [comunicado](https://emudhra.com/en/press-release/emudhra-to-exit-global-ssl-tls-certificate-business?ref=blog.ifirestone.dev), citado por The Register, dice que ese negocio es cerca del 1 por ciento de sus ingresos globales y que el escrutinio fue desproporcionado respecto a su peso en la empresa. Estima que unos 30.000 certificados necesitan migrarse y dice que los servicios de revocación y de estado seguirán funcionando hasta que todos los certificados emitidos hayan expirado o se hayan reemplazado.

También dice que la infraestructura afectada pasó dos años de auditorías independientes y estaba en las listas de confianza de los navegadores desde mediados de 2025\. Si eso es exacto, es la parte incómoda. Las auditorías no detectaron una clave privada que era el número 4.

No creo que la lección sea que una autoridad fue descuidada. La lección es que la mayor parte de nuestro software trata un trust store como una lista estática de raíces, cuando el modelo de amenazas exige que se comporte como un feed de revocación. Cloudflare señala proyectos como [upki](https://discourse.ubuntu.com/t/an-update-on-upki/77063?ref=blog.ifirestone.dev), de Canonical, que tratan el trust store como algo que debe actualizarse rápido con información de revocación y de certificate transparency. Es una dirección, no algo que puedas instalar el lunes.

Lo que sí puedes hacer el lunes es abrir el archivo. En algún punto de tu stack hay una lista de en quién confías, y nadie la ha mirado desde el día en que se construyó la imagen. El número 4 estuvo a la vista de todos unos 18 meses. La lista probablemente es más vieja.

La misma semana tuvo un fallo muy distinto en el otro extremo de la escala: un parche que se saltó versiones que la gente seguía ejecutando. Escribí sobre su costo en [Cuando el parche se salta tu versión: lo que costó PHP2Shell a los gobiernos y lo que añade el EOL](https://blog.ifirestone.dev/cuando-el-parche-se-salta-tu-version-lo-que-costo-php2shell-a-los-gobiernos-y-lo-que-anade-el-eol/).

## Fuentes

- [8 eMudhra certificates are compromised. Here's what you need to know](https://blog.cloudflare.com/emudhra-certificate-compromise/?ref=blog.ifirestone.dev) (Cloudflare Blog, en inglés)
- [Disgraced Indian cert issuer leaves the cert issuing business](https://www.theregister.com/security/2026/10/22/disgraced-indian-cert-issuer-leaves-the-cert-issuing-business/5304848?ref=blog.ifirestone.dev) (The Register, en inglés)
- [Cloudflare warns fixing botched eMudhra certs goes beyond browsers](https://www.itnews.com.au/news/cloudflare-warns-fixing-botched-emudhra-certs-goes-beyond-browsers-629804?ref=blog.ifirestone.dev) (iTnews, en inglés)
- [Advisory and checker for the compromised eMudhra intermediate CAs](https://emudhra.we-have-a-problem.com/?ref=blog.ifirestone.dev) (Dennis Jackson, [we-have-a-problem.com](http://we-have-a-problem.com/?ref=blog.ifirestone.dev), en inglés)