La clave era 4: quién decide en qué sitios web confía tu software

Este artículo ha sido traducido automáticamente. La versión original está disponible en inglés.

Última actualización: 25 de octubre de 2026 · 21 min de lectura

Aquí tenemos un problema

El sábado 17 de octubre de 2026, a las 18:05 UTC, el programa de certificados raíz de Chrome recibió un aviso de un investigador de seguridad al que públicamente solo se ha identificado como Wayne. Afirmaba tener las claves privadas de ocho autoridades de certificación gestionadas por eMudhra, una empresa cotizada con sede en Bangalore, en la India. Para demostrarlo, había usado cada una de las ocho claves para firmar el mismo mensaje breve: «Aquí tenemos un problema – Wayne».

No le había hecho falta entrar en ningún sistema. Cuando la noticia salió a la luz, el investigador de seguridad Scott Helme describió cómo eran las claves. Una de ellas era sencillamente el número 4. Otras dos eran 56 y 115. Helme contó que las había recuperado todas a partir de sus certificados públicos en su portátil, y que le había llevado menos de un segundo. Una comprobación independiente de unos periodistas confirmó que la clave privada de «EM OV TLS CA – G3C», de eMudhra, era 4.

Las ocho eran autoridades de certificación intermedias, la capa operativa de una empresa de certificados, la que firma credenciales para terceros. Seis de ellas estaban autorizadas a emitir certificados para sitios web, y esas seis contaban con la confianza de los programas de certificados raíz de Chrome, Mozilla, Microsoft y Apple. Las otras dos servían para la firma de código, los certificados con los que los fabricantes de software firman sus programas, y Microsoft confiaba en ellas. Sus claves se habían generado mal, de modo que cualquiera que supiera dónde mirar podía calcularlas a partir de los propios certificados, que son públicos por diseño. Eso era posible desde que se crearon los certificados, en abril de 2025.

A las 19:45 UTC, una hora y cuarenta minutos después de recibir el aviso, Chrome ya había confirmado los hallazgos y enviado un bloqueo a sus usuarios. Nadie tuvo que instalar una actualización ni reiniciar el navegador.

La rapidez importaba por lo que puede hacer una clave así. Quien tuviera cualquiera de las seis claves para sitios web y pudiera interceptar la conexión de una persona podría presentarle un certificado falsificado de un banco, de un servicio de correo electrónico o de cualquier otro sitio, fuera cual fuera la empresa de certificados que usara el sitio auténtico, y el software que confiara en la cadena de eMudhra lo aceptaría. Se interponían dos protecciones principales: un sistema público de registro llamado Certificate Transparency, que parte del software exige y mucho otro no, y los bloqueos que cada programa recibiera a tiempo.

Que un certificado falsificado hubiera funcionado o no dependía de decisiones que normalmente no se ven: quién avala a un sitio web, quién decide que hay que creer a ese avalista y con qué rapidez puede retirarse esa confianza cuando el avalista resulta estar roto.

Qué avala un certificado

Un certificado web es un pequeño documento firmado que vincula un nombre, como la dirección web de un banco, a una clave pública. Las claves públicas van en pareja con claves privadas. La clave privada se mantiene en secreto y genera firmas digitales; la pública permite a cualquiera comprobar que una firma procede de su pareja. Cuando el navegador se conecta a un sitio, el sitio demuestra que posee la clave privada que corresponde a la clave pública de su certificado. El certificado, por su parte, afirma que esa clave pública pertenece a ese nombre, y una autoridad de certificación, o CA, respalda esa afirmación firmándola.

Antes de firmar un certificado web, la CA debe comprobar que el solicitante controla el dominio. Uno de los métodos aprobados consiste en darle un valor aleatorio y buscarlo después en los registros DNS del dominio, la guía pública de direcciones de internet, donde solo alguien que controle el dominio podría haberlo puesto. La CA también puede confirmar que el solicitante tiene de verdad la clave privada que quiere certificar, mediante una prueba técnica llamada prueba de posesión, aunque la norma de base permite asimismo fiarse de su palabra.

Ningún navegador podría verificar por sí mismo todas las CA del mundo, así que la confianza se delega en cadena. En la cima están los certificados raíz, guardados en una lista llamada almacén de confianza que viene incluida en el sistema operativo o en el navegador. Las raíces autorizan a CA intermedias, y las intermedias emiten los certificados que usan los sitios web. Cuando el software ve el certificado de un sitio, sigue las firmas hacia arriba, del sitio a una intermedia y de ahí a una raíz, y solo acepta el sitio si la cadena termina en una raíz de su almacén, todas las firmas son válidas, el certificado está dentro de su periodo de validez y cubre el nombre que se visita, y ninguna de las demás reglas del software lo prohíbe.

Los programas de certificados raíz, gestionados por fabricantes de sistemas operativos y navegadores como Apple, Google, Microsoft y Mozilla, examinan a las autoridades de certificación y deciden qué raíces entran en el almacén. Por eso la clave privada de una intermedia es tan valiosa. Salvo que se haya restringido a ciertos nombres, y las de eMudhra no lo estaban, una intermedia puede firmar un certificado para cualquier dominio, y ese certificado se valida hacia arriba hasta una raíz de confianza. La clave de la raíz puede seguir bajo llave; la de la intermedia hace las firmas del día a día, y si se filtra, el aval de la raíz se filtra con ella.

Nada de esto dice si un sitio web es honrado, aunque mucha gente cree que el icono del candado del navegador sí lo dice. Cuando Google estudió la cuestión en 2021, solo el 11 % de los participantes entendía correctamente qué significaba el candado, y casi todos los sitios de phishing usaban HTTPS y, por tanto, también lo mostraban. En 2023 Google anunció que Chrome sustituiría el candado por otro icono. Un certificado básico dice únicamente que la conexión llega a quien tenga la clave de ese nombre. Algunos certificados nombran además a la organización que está detrás del sitio; ninguno responde de sus intenciones.

Hay una capa más. Certificate Transparency, planteada por ingenieros de Google en 2013, coloca los certificados en registros públicos donde cualquiera puede auditar lo que ha emitido cada CA. Sus diseñadores pretendían que los clientes acabaran rechazando cualquier certificado que no se hubiera registrado, de modo que un certificado mantenido fuera de los registros, lo hubiera emitido una CA o un ladrón con la clave de una CA, fuera rechazado. Chrome lo hace por defecto en todas las conexiones que dependen de su almacén de confianza.

La advertencia que nadie atendió

Las reglas para crear claves de CA son estrictas. Para las raíces y ciertas claves intermedias, los Baseline Requirements del sector, el reglamento que los programas de certificados raíz de los navegadores y las CA mantienen en común, establecen que la CA debe seguir un guion escrito de generación de claves y que un auditor cualificado debe presenciar la ceremonia o grabarla íntegramente en vídeo. Toda clave de CA debe generarla un grupo de personas, ninguna de las cuales reúna por sí sola todo el conocimiento necesario para hacerlo.

El 30 de abril de 2025 eMudhra creó un lote de 24 intermedias. Se dividían en tres series, etiquetadas A, B y C, con dos tipos de clave, RSA y la de curva elíptica llamada P-384, y cuatro finalidades. Las ocho claves rotas eran todas las claves P-384 de las series B y C. Las ocho eran números enteros menores que 256. Escrita entera, cada una era una larga hilera de ceros con algo en el último byte.

Por qué se podía adivinar esta clave

Una clave privada en la curva P-384 es simplemente un número, elegido al azar entre 1 y un límite fijo que tiene a su vez 384 bits de longitud. La clave pública se obtiene de la privada mediante un cálculo fácil de hacer hacia delante y, con un número verdaderamente aleatorio, imposible de deshacer. Va impresa en el certificado. El número 4 es una clave privada perfectamente legal; también es uno de los primeros números que probaría cualquiera. Mozilla señaló que claves tan pequeñas pueden recuperarse casi al instante: se calculan las claves públicas de 1, 2, 3 y así sucesivamente hasta 256, y se compara cada una con la del certificado. Cuando dos coinciden, la clave privada es el número del que se partió. Una clave verdaderamente aleatoria no ofrece una lista corta así. Como dijo Scott Helme, el intervalo contiene aproximadamente 10 elevado a 115 posibilidades, «así que nadie va a buscar ahí jamás». Dennis Jackson, de Mozilla, también encargó la tarea a agentes de IA que se ejecutaban en local. Recuperaron la clave al primer intento a partir de una instrucción sencilla.

¿Cómo pudo una ceremonia de claves producir números tan pequeños? La explicación preliminar de eMudhra, publicada el 19 de octubre, es que el guion que usó ese día tenía un fallo. Según la empresa, había aprobado un cambio puntual en el procedimiento habitual para probar la exportación de las claves; un error de programación hizo que el hardware creara un segundo par de claves, más débil, junto a las correctas, y las claves débiles se usaron después por error para solicitar los certificados porque sus etiquetas se parecían. Añade que las claves se generaron en módulos de seguridad de hardware fabricados por Utimaco, los dispositivos resistentes a la manipulación destinados a producir y custodiar las claves de las CA.

eMudhra califica el relato de preliminar, y deja abierto el enigma central. Un comentarista en la incidencia pública de Mozilla señaló que, o bien las claves se crearon fuera del hardware seguro y se cargaron en él, en contra de la normativa, o bien el hardware podía configurarse de algún modo para generar él mismo claves defectuosas. Otro participante, en la lista de correo pública de Mozilla, apuntó sin confirmarlo que un programa había confundido con la propia clave un pequeño archivo que apuntaba a la clave real dentro del hardware. Mozilla, esforzándose mucho más, no logró recuperar las claves P-384 de la serie A del mismo lote. El 20 de octubre envió preguntas a eMudhra con un plazo de 24 horas; a 23 de octubre no había recibido respuesta, y nadie había explicado cómo llegaron a existir las claves débiles.

Lo que sí está documentado es que el problema se había dejado ver más de un año antes. En junio de 2025 un servicio público de monitorización mostró que eMudhra servía seis listas de revocación de certificados con firmas no válidas para esas mismas intermedias. Una lista de revocación, o CRL, es un registro firmado de los certificados que una CA ha anulado, y su firma debe poder verificarse con la clave pública del certificado de la CA. El informe de eMudhra de entonces decía que Sectigo, otra empresa de certificados, la había avisado primero por correo electrónico el 3 de junio de 2025, y que el mensaje había quedado en cuarentena en los filtros internos y nadie lo había visto. Las listas defectuosas se sustituyeron el 6 de junio.

En octubre de 2026 eMudhra explicó en qué había consistido aquel arreglo. Las listas se habían firmado primero con las claves originales, debidamente aleatorias; como los certificados contenían las mitades públicas de las claves débiles, esas firmas fallaban, y la empresa volvió a firmar las listas con las claves defectuosas. En junio de 2025, por tanto, eMudhra tenía pruebas de que sus certificados no se correspondían con las claves que creía estar usando, y arregló las listas.

El programa de certificados raíz de Chrome preguntó por qué eMudhra se había limitado a volver a firmar las listas en lugar de detener sus operaciones, investigar por qué existían dos pares de claves para estas CA y revocar los certificados. eMudhra afirma que sus raíces y sus CA emisoras pasaron auditorías independientes dos años seguidos. El 14 de octubre de 2026, tres días antes del aviso de Wayne, publicó una lista de revocación para otra raíz, emSign Root TLS CA – G1, cuya firma tampoco era válida.

Dos tipos de interruptor

La primera respuesta de Chrome fue rápida porque apuntaba a las claves. Chrome mantiene una lista de bloqueo llamada CRLSet, que Google envía a los navegadores en segundo plano. La actualización que publicó a las 19:45 UTC bloqueaba las huellas digitales de las claves públicas de las seis intermedias. Como el bloqueo designaba claves, abarcaba todos los certificados que usaran esas claves, incluidos los que un falsificador pudiera crear más adelante. Mozilla bloqueó los certificados en Firefox mediante su propia lista, OneCRL, y terminó a las 22:59 UTC. OneCRL funciona sin que los usuarios tengan que actualizar Firefox, ni siquiera reiniciarlo.

Una lista enviada en segundo plano solo protege al software que la recibe. El 20 de octubre Mozilla publicó una actualización de Firefox para los usuarios cuya configuración había impedido que les llegara la lista de bloqueo, y más tarde una corrección para algunos perfiles de Firefox para Android que no la estaban aplicando. Google empezó a enviar un bloqueo equivalente a los dispositivos Android a través de los servicios de Google Play hacia las 22:00 UTC del lunes 19 de octubre, y al día siguiente dijo que la mayoría ya lo había recibido. Microsoft y Apple los siguieron en cuestión de días, aunque los relatos publicados no coinciden en la fecha exacta de la actuación de Apple.

Las autoridades de certificación también se movieron. eMudhra marcó los ocho certificados como revocados a las 09:38 UTC del 18 de octubre, con el motivo de CA comprometida. Sectigo, que había firmado de forma cruzada las intermedias, terminó de revocar sus certificados cruzados el 19 de octubre. Chrome hizo además que los registros de Certificate Transparency rechazaran cualquier certificado encadenado a las CA comprometidas, de modo que un certificado falsificado ya no pudiera reunir las entradas de registro que exige el software que comprueba la CT.

La herramienta más contundente es retirar la raíz que autorizó a las intermedias. El 20 de octubre, tras constatar que para entonces varias personas habían recuperado las claves por su cuenta, Mozilla decidió la retirada de urgencia de emSign ECC Root CA – G3, la raíz de eMudhra situada por encima de las intermedias rotas, de su almacén de confianza. Firefox no la necesitaba; OneCRL ya lo cubría. Era para todos los demás que usan la lista de raíces de Mozilla o una derivada de ella sin OneCRL. Mozilla advirtió que el cambio dejaría algunos servidores inaccesibles para esos usuarios hasta que los servidores pasaran a nuevas cadenas de certificados.

Chrome retiró la misma raíz de su almacén. Google preveía que el cambio llegara a todos los dispositivos que dependen del Chrome Root Store la mañana del martes 27 de octubre de 2026, hora del Pacífico, y antes a las versiones de prueba Canary y Beta. Google dijo sin rodeos que, como consecuencia, algunos certificados legítimos encadenados a esa raíz dejarían de funcionar en Chrome.

Los dos interruptores difieren en lo que atrapan y en a quién perjudican. Retirar una raíz corta todos los caminos que pasan por ella, incluidos los de los sitios web honrados, pero no alcanza los que pasan por otras raíces, y las intermedias de eMudhra tenían otro. Sectigo las había certificado de forma cruzada, vinculando las mismas claves a una raíz llamada AAA Certificate Services, emitida con el nombre de Comodo. Chrome había eliminado esa raíz en abril de 2025, pero algunos sistemas seguían confiando en ella: Ubuntu retiró emSign ECC Root CA – G3 de todas sus versiones con soporte y, de las versiones antiguas que aún la incluían, también la raíz de Comodo. Un bloqueo dirigido a la propia intermedia atrapa todas las rutas a la vez. El lenguaje de programación Go optó por esa vía: desde las versiones publicadas el 19 de octubre, el verificador de certificados de Go descarta cualquier cadena que contenga una de las intermedias comprometidas, termine en la raíz que termine.

La actualización de todos los demás

El 18 de octubre Mozilla escribió en su incidencia pública que le preocupaba el ecosistema en general, porque muchos dispositivos finales no tienen una forma eficaz de recibir información de revocación. Los navegadores tenían sus listas en segundo plano. Gran parte del resto del software que establece conexiones seguras no tiene nada parecido.

El sitio de seguimiento del incidente, una página pública creada por Dennis Jackson, de Mozilla, detallaba quién estaba expuesto. Las aplicaciones y bibliotecas que incluyen su propio paquete de raíces de confianza necesitaban actualizaciones de software. También las aplicaciones creadas con Electron, el entorno en el que se basan programas de escritorio como Slack y Discord, que solo incorporan la corrección de Electron cuando se recompilan sobre una versión parcheada.

Algunos huecos estaban en los propios archivos de confianza de los sistemas operativos. A 22 de octubre, el sitio del incidente indicaba que macOS bloqueaba las intermedias comprometidas, pero que sus herramientas de línea de comandos integradas, entre ellas curl, git y python3, verificaban los certificados con un archivo distinto sin consultar la revocación, y ese archivo no se había actualizado. En Ubuntu, el almacén de confianza de Java requería una acción manual después de la actualización del sistema por un problema de sincronización que Canonical no había resuelto a 22 de octubre, y los navegadores instalados como paquetes snap no usaban en absoluto el almacén del sistema.

Otros huecos estaban en bibliotecas que llevan sus propias listas. Go publicó su corrección en las versiones de seguridad 1.27.3 y 1.26.10, con el identificador CVE-2026-111943. El paquete certifi de Python, de uso muy extendido, eliminó las cuatro raíces emSign el 18 de octubre y después restauró las tres que no estaban afectadas en una versión etiquetada como 2026.10.19; una versión automática del 23 de octubre volvió a quitar dos de esas tres. Y algunos productos solo podían corregirlos sus fabricantes: el equipo de seguridad Talos, de Cisco, señaló las redes privadas virtuales como candidatas probables a necesitar actualizaciones.

Por debajo de todo esto estaba Certificate Transparency. La mayoría de los navegadores la exigen, pero muchos clientes que no son navegadores, curl entre ellos, no lo hacen. Un certificado falsificado con una de las claves de eMudhra y nunca registrado sería rechazado por Chrome, pero esos clientes podrían aceptarlo, siempre que siguieran confiando en la cadena de eMudhra y nada más lo impidiera, como una aplicación que solo acepta los certificados conocidos de sus propios servidores.

Hay argumentos sólidos para decir que el sistema funcionó. Ningún certificado web encadenado a las seis intermedias se registró en Certificate Transparency antes del bloqueo de Chrome del 17 de octubre, así que entre la creación de las claves en abril de 2025 y ese bloqueo ningún certificado falsificado con ellas podría haberse usado contra clientes que exigen la CT. Talos dijo que no había detectado ningún uso malicioso real hasta el 21 de octubre a las 14:00 UTC. eMudhra afirma que solo una de las intermedias afectadas llegó a ponerse en producción, y que ninguna emitió nunca un certificado a un sitio web ni a un fabricante de software.

Para el software que exigió la CT durante todo ese tiempo, el argumento es correcto, y la protección vino de una regla permanente, no de la emergencia de aquel fin de semana. Su alcance es más estrecho de lo que sugiere la frase «el sistema funcionó». Firefox para Android empezó a exigir Certificate Transparency solo con la versión 145, ofrecida por primera vez a los usuarios el 11 de noviembre de 2025. Las aplicaciones de Android solo pueden usar las comprobaciones de CT integradas a partir de Android 16, y solo las tienen por defecto cuando se compilan para Android 17.

La emergencia también importó por lo que vino después. El primer aviso de Mozilla a los responsables de los almacenes de confianza derivados omitió deliberadamente que cualquiera podía recuperar las claves. Para el 20 de octubre eso apenas importaba: varias personas las habían recuperado por su cuenta, y Helme había publicado los ocho valores. Una vez que las claves eran públicas a todos los efectos, los bloqueos y los rechazos de los registros de CT eran lo que se interponía entre ellas y cualquier nueva falsificación. A 24 de octubre, nada de lo publicado mostraba si algún atacante había usado las claves defectuosas contra clientes sin CT entre abril de 2025 y octubre de 2026.

Quién tiene el interruptor

Las decisiones sobre en qué raíces confían los navegadores y los sistemas operativos corresponden a los programas de certificados raíz, y sus reglas dan a sus dueños un amplio margen. La política de Chrome dice que Google incluye o retira certificados «a su entera discreción», y que cada certificado incluido debe aportar a los usuarios un valor superior al riesgo de mantenerlo. La política de Mozilla dice que puede desactivar o retirar un certificado a su entera discreción, en cualquier momento y por cualquier motivo. Mozilla dice también que no cobra nada por la inclusión.

Esa discrecionalidad se ha ejercido de maneras distintas. En 2014, después de que el National Informatics Centre de la India emitiera certificados no autorizados para varios dominios de Google, Chrome no expulsó la raíz India CCA que estaba por encima. Limitó esa raíz a una lista de dominios indios. Tres años antes, la respuesta a una autoridad neerlandesa había sido total: el 3 de septiembre de 2011 Google decidió rechazar todas las autoridades de certificación que operaba DigiNotar, y diecisiete días después un tribunal neerlandés declaró la quiebra de la empresa.

DigiNotar, 2011

La brecha de DigiNotar salió a la luz gracias a un usuario corriente. El 28 de agosto de 2011, un cliente de ParsOnline, un proveedor de internet iraní, escribió en un foro de soporte de Google sobre una advertencia de certificado que le había mostrado Chrome. El certificado decía ser de Google y procedía de DigiNotar, cuyos sistemas habían sido asaltados. Los investigadores de la empresa de seguridad Fox-IT, que trabajaban para el Gobierno neerlandés, descubrieron más tarde que un certificado fraudulento que cubría direcciones de google.com se había usado en un ataque a gran escala contra aproximadamente 300.000 usuarios, casi todos en Irán, cuyo tráfico de Google probablemente fue interceptado o redirigido. Obtuvieron esa estimación a partir de 298.140 direcciones de internet distintas que habían consultado el estado del certificado falsificado, y la calificaron de aproximación muy burda. El 3 de septiembre el Gobierno neerlandés retiró públicamente su confianza en DigiNotar. A finales de octubre de 2026 no se había informado de ningún ataque con las claves de eMudhra. DigiNotar mostró lo que hace el poder de firma de una CA en manos de alguien dispuesto a usarlo.

Para formar parte del almacén de confianza de Chrome, escribió Google, el propietario de una CA debe demostrar de forma continuada la competencia técnica y el rigor operativo necesarios para proteger a los usuarios de Chrome, y añadió que estaba «investigando de cerca» si los demás certificados de CA de eMudhra debían seguir en él. El 23 de octubre eMudhra dijo en la incidencia pública que el intenso escrutinio en las redes sociales y el análisis de inversores y clientes habían hecho «prácticamente imposible» un análisis serio de lo ocurrido. Chrome respondió ese mismo día que eso no era excusa, y que eMudhra seguía teniendo obligaciones con los «miles de millones» de personas que dependen del sistema y a las que su error había dejado expuestas.

El consejo de administración de eMudhra ya había decidido, el 22 de octubre, abandonar el negocio mundial de certificados SSL/TLS. La empresa afirma que ese negocio es una parte muy pequeña de su actividad.

Esas mismas empresas redactan además reglas comunes con las CA en un organismo llamado CA/Browser Forum. En una votación que se cerró el 11 de abril de 2025, diecinueve días antes de que eMudhra generara las claves defectuosas, Apple, Google, Microsoft y Mozilla votaron a favor de acortar la vida de los certificados web, y 25 emisores de certificados, eMudhra entre ellos, también votaron sí. El argumento de la propuesta era que la revocación no protege adecuadamente a las personas a escala de internet, mientras que la caducidad sí. «Los periodos de validez de los certificados, y su aplicación por parte de quienes confían en ellos, son increíblemente fiables», decía. Según las reglas vigentes en octubre de 2026, los certificados web emitidos a partir del 15 de marzo de 2026 pueden durar como máximo 200 días; a partir del 15 de marzo de 2027, 100 días; y a partir del 15 de marzo de 2029, 47 días.

Esos topes se aplican a los certificados que usan los sitios web, según su fecha de emisión. El texto de la norma no limita los certificados de CA que están en el centro de este incidente, así que unas vidas más cortas no habrían hecho caducar las intermedias de eMudhra. Tampoco ha desaparecido la revocación. Let’s Encrypt, la autoridad de certificación gratuita, cerró en agosto de 2025 su servicio OCSP, que permitía a los navegadores preguntar por los certificados de uno en uno, porque cada consulta le revelaba a la CA qué sitio se estaba visitando y desde qué dirección de internet. Los bloqueos de urgencia del 17 de octubre fueron, en la práctica, listas de revocación que los fabricantes de navegadores seleccionaron y enviaron ellos mismos.

Este sistema pone mucho poder en unas pocas manos privadas, la mayoría estadounidenses. Lo que muestra el caso de eMudhra es cómo se ejerce ese poder: en una incidencia abierta donde cualquiera puede leer las preguntas, los plazos y las respuestas, y con los motivos publicados por las empresas que retiran la confianza.

Los certificados que tienen que mudarse

Retirar una raíz es rápido de anunciar y lento de digerir. A 21 de octubre, Chrome contaba unos 30.800 precertificados no caducados encadenados a emSign ECC Root CA – G3. Un precertificado es la copia de un certificado que se envía a los registros de transparencia antes de emitirlo, así que la cifra cuenta certificados registrados, no sitios web que aún los usen. De ellos, 30.791, el 99,9 %, procedían de dos intermedias pertenecientes a InCommon, un servicio de certificados gestionado por Internet2, una organización estadounidense de redes. Esas dos no estaban entre las ocho intermedias rotas; simplemente colgaban de la raíz que se iba a retirar. eMudhra calculó que unos 30.000 certificados tenían que mudarse, casi todos emitidos mediante ACME, el protocolo que permite a los servidores solicitar y renovar certificados de forma automática. eMudhra dejó de emitir bajo la raíz G3 el 20 de octubre.

La automatización no lo resuelve por sí sola. Los clientes ACME estándar solo sustituyen un certificado cuando llega su fecha de renovación, salvo que admitan una extensión más reciente que permite a la CA pedir una renovación anticipada o que alguien intervenga a mano. Chrome señaló el 21 de octubre que pasar de la jerarquía de curva elíptica de eMudhra a la RSA puede exigir también cambiar la configuración del cliente.

Los certificados de InCommon llegan a través de CertiNext, un proveedor cuya empresa matriz es eMudhra. El 22 de octubre InCommon dijo a sus suscriptores que muchos de ellos habían pasado la semana respondiendo a errores de certificados y haciendo planes en torno a cambios que escapaban a su control, después de una migración exitosa pero agotadora durante la primavera y el verano. Su consejo de aquella mañana era volver a emitir los certificados afectados como RSA hasta que se restableciera la emisión de curva elíptica.

eMudhra había dicho el 20 de octubre que la única alternativa para sus clientes de G3 eran intermedias encadenadas a su raíz RSA, emSign Root CA – G1. Mozilla dijo ese mismo día que, por el momento, no iba a retirar la confianza en G1. G1 figuraba entre los demás certificados de eMudhra que Chrome dijo el 20 de octubre estar investigando de cerca; a 24 de octubre Chrome no había anunciado ninguna decisión. El 21 de octubre Chrome pidió a eMudhra que confirmara si estaba trasladando a los clientes a G1, a la jerarquía de otra empresa o a ambas.

La actualización de InCommon de la tarde del 22 de octubre resolvió el problema inmediato. Volvían a emitirse certificados de curva elíptica, ahora encadenados a la raíz G1, y los clientes existentes podían renovar sin cambiar nada de su configuración. La misma actualización indicaba que eMudhra dejaría de emitir desde cualquier intermedia encadenada a sus raíces públicas en 30 días, en una fecha que CertiNext confirmaría, y que InCommon trabajaba en una vía de sustitución. Para unos suscriptores que habían completado una agotadora migración en primavera y verano, la retirada de una sola raíz había desencadenado otra.

Artículos relacionados

• Hasta dónde alcanza a un tribunal de La Haya una lista de sanciones de Estados Unidos
• ¿Qué le espera a Bitcóin?
• Cómo funciona de verdad la IA: lo que saben los desarrolladores y los titulares no

Lecturas recomendadas

Como Afiliado de Amazon, Eikleaf obtiene ingresos por las compras adscritas que cumplen los requisitos aplicables. Los enlaces a libros que aparecen a continuación son enlaces de afiliado: si compras a través de ellos, podemos recibir una pequeña comisión sin coste adicional para ti.

• Los códigos secretos — Simon Singh (2000). Historia accesible de la criptografía que explica el cifrado de clave pública, las matemáticas detrás de los certificados y las claves privadas del artículo.
• Security Engineering: A Guide to Building Dependable Distributed Systems (3rd ed.) — Ross Anderson (2001). La referencia de cabecera sobre cómo fallan los sistemas de seguridad reales, con capítulos sobre la infraestructura de clave pública, las autoridades de certificación y la confianza.
• Secrets and Lies: Digital Security in a Networked World — Bruce Schneier (2000). Un destacado autor sobre seguridad explica, sin matemáticas, por qué los certificados digitales y las cadenas de confianza solo son tan sólidos como las organizaciones que los respaldan.

Vídeos recomendados

Aviso sobre IA generativa

Algunos contenidos de esta página se generaron y/o editaron con la ayuda de una IA generativa.

Multimedia

HTTPS y candado en la barra de direcciones de un sitio web – Wikimedia Commons (Foto: Santeri Viinamäki, CC BY-SA 4.0)

Módulo de seguridad de hardware nCipher nShield F3 – Wikimedia Commons (Foto: Alexander Klink, CC BY 3.0)

Sede del Googleplex – Wikimedia Commons (Foto: Asoundd, CC BY-SA 4.0)

Principales fuentes y referencias

Mozilla Bugzilla. «Bug 2083449: eMudhra: Private key compromise of Intermediate Certificates.» Opened 18 October 2026, comments to 23 October 2026. https://bugzilla.mozilla.org/show_bug.cgi?id=2083449

Chrome and Android Security Teams. «Protecting Chrome and Android Users from Compromised eMudhra Intermediate CA Certificates.» Google, The Keyword, 20 October 2026. https://blog.google/security/protecting-chrome-and-android-users-from-compromised-emudhra-intermediate-ca-certificates/

Mozilla dev-security-policy mailing list. «Compromised eMudhra Intermediate Certificates» thread, posts by Dennis Jackson (Mozilla) and the Chrome Root Program, 20 October 2026, and by Wayne and Corey Bonnell, 21 October 2026. https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/0R3XLJL6FuE

Jackson, Dennis. «eMudhra Intermediate CA Compromise.» Incident tracking site, 20 October 2026, updated 22 October 2026. https://emudhra.we-have-a-problem.com/

InCommon (Internet2). «Moving Forward Together: InCommon Certificate Service Update.» Updates of 22 October 2026. https://incommon.org/about/news/incommon-certificate-service-update

InCommon (Internet2). «InCommon Certificate Service FAQ.» Last updated 22 October 2026, 18:30 ET. https://incommon.org/certificates

Stanescu, Luci. «eMudhra CA compromise fixes available.» Ubuntu blog, Canonical, 20 October 2026, updated 22 October 2026. https://ubuntu.com/blog/emudhra-ca-compromise-fixes-available

Canonical. «USN-8944-1: ca-certificates update» and «USN-8944-2: ca-certificates update.» Ubuntu security notices, 20 October 2026. https://ubuntu.com/security/notices/USN-8944-1 and https://ubuntu.com/security/notices/USN-8944-2

Go team. «[security] Go 1.27.3 and Go 1.26.10 are released.» golang-announce, posted 20 October 2026 (releases dated 19 October 2026). https://groups.google.com/g/golang-announce/c/66pojueaQek

Go project. «Release History.» Accessed 24 October 2026. https://go.dev/doc/devel/release

certifi. «Remove emsign (#437),» «Restore unaffected emSign roots (#439) (#440)» and «2026.10.23 (#445).» python-certifi repository, 18, 20 and 23 October 2026. https://github.com/certifi/python-certifi/commit/5cb238caeeb6c30ec1a7309ad3e16a5aa7b10ce8 and https://github.com/certifi/python-certifi/commit/662df63d7906df66f1f07c0751a3dfe9da14d914 and https://github.com/certifi/python-certifi/commit/b60466c9f2882d9cf088943c650b0faac06c080c

Cisco Talos. «Compromised eMudhra intermediate certificates.» Talos Intelligence blog, 21 October 2026. https://blog.talosintelligence.com/compromised-intermediate-certificates/

eMudhra Limited. «eMudhra Statement on distrust of select Global TLS Intermediate and one Root CA.» 21 October 2026. https://emudhra.com/en/press-release/emudhra-statement-distrust-global-tls-intermediate-root-ca

eMudhra Limited. «eMudhra to exit global SSL/TLS certificate business.» 22 October 2026. https://emudhra.com/en/press-release/emudhra-to-exit-global-ssl-tls-certificate-business

Abrams, Lawrence. «Mozilla, Google, Apple block compromised eMudhra CA certificates.» BleepingComputer, 20 October 2026. https://www.bleepingcomputer.com/news/security/mozilla-google-apple-block-compromised-emudhra-ca-certificates/

Helme, Scott. «Eight Bits of Trust; eMudhra’s CA keys cracked in milliseconds.» 20 October 2026. https://scotthelme.co.uk/eight-bits-of-trust-emudhras-ca-keys-cracked-in-milliseconds/

Sharwood, Simon. «Indian certification authority eMudhra’s private keys compromised – one of them was the number ‘4’.» The Register, 20 October 2026. https://www.theregister.com/a/5304312

Mozilla Bugzilla. «Bug 1970728: eMudhra: Invalid CRL signatures.» June 2025. https://bugzilla.mozilla.org/show_bug.cgi?id=1970728

Mozilla. «Firefox for Android 145.0 release notes.» 11 November 2025. https://www.firefox.com/en-US/firefox/android/145.0/releasenotes/

Cooper, D., et al. «RFC 5280: Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile.» IETF, May 2008. https://www.rfc-editor.org/rfc/rfc5280

Laurie, B., Langley, A., and Kasper, E. «RFC 6962: Certificate Transparency.» IETF, June 2013. https://www.rfc-editor.org/rfc/rfc6962

CA/Browser Forum. «Baseline Requirements for the Issuance and Management of Publicly-Trusted TLS Server Certificates, Version 2.3.1.» 4 October 2026, sections 3.2.2.4.7, 6.1.1.1 and 6.3.2. https://github.com/cabforum/servercert/blob/3574ae809e5f909b58ee4c26b7bac4a3b9e78421/docs/BR.md

CA/Browser Forum. «Ballot SC081v3: Introduce Schedule of Reducing Validity and Data Reuse Periods.» 11 April 2025. https://cabforum.org/2025/04/11/ballot-sc081v3-introduce-schedule-of-reducing-validity-and-data-reuse-periods/

Google. «Chrome Root Program Policy, Version 1.8.» Last updated 5 February 2026. https://googlechrome.github.io/chromerootprogram/crp/policy/

Mozilla. «Mozilla Root Store Policy, Version 3.1.» Effective 1 July 2026. https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/

Aas, Josh. «OCSP Service Has Reached End of Life.» Let’s Encrypt, 6 August 2025. https://letsencrypt.org/2025/08/06/ocsp-service-has-reached-end-of-life/

Adrian, David, Serena Chen, Joe DeBlasio, Emily Stark and Emanuel von Zezschwitz. «An update on the lock icon.» Chromium Blog, May 2023. https://blog.chromium.org/2023/05/an-update-on-lock-icon.html

von Zezschwitz, Emanuel, Emily Margarete Stark and Serena Chen. «‘It builds trust with the customers’ – Exploring User Perceptions of the Padlock Icon in Browser UI.» SecWeb 2022, IEEE. https://research.google/pubs/it-builds-trust-with-the-customers-exploring-user-perceptions-of-the-padlock-icon-in-browser-ui/

Android Developers. «Network security configuration: Certificate transparency.» Accessed 24 October 2026. https://developer.android.com/privacy-and-security/security-config

Langley, Adam. «Maintaining digital certificate security.» Google Online Security Blog, July 2014. https://security.googleblog.com/2014/07/maintaining-digital-certificate-security.html

Adkins, Heather. «An update on attempted man-in-the-middle attacks.» Google Online Security Blog, 29 August 2011, updated 3 September 2011. https://security.googleblog.com/2011/08/update-on-attempted-man-in-middle.html

Fox-IT. «Black Tulip: Report of the investigation into the DigiNotar Certificate Authority breach.» 13 August 2012. https://zoek.officielebekendmakingen.nl/blg-191225.pdf