Ocho certificados de eMudhra comprometidos disparan la alerta máxima en internet

La cadena de confianza de internet vivió esta semana uno de sus sobresaltos más serios en años. Ocho certificados intermedios de la autoridad certificadora india eMudhra, que opera su negocio público bajo la marca emSign, quedaron con sus claves privadas comprometidas. Con una de esas claves en la mano, cualquier actor podría haber emitido credenciales válidas para cualquier dominio del planeta, aceptadas sin objeción por navegadores, sistemas operativos y aplicaciones. Los grandes programas de raíces y los equipos de Go reaccionaron en cuestión de horas, pero la alerta está lejos de cerrarse en el resto del ecosistema.

• Ocho claves en riesgo: seis certificados intermedios TLS (DV, OV y EV) y dos de firma de código pertenecientes a eMudhra BV y eMudhra Inc.
• Reacción exprés: Chrome bloqueó los seis intermedios TLS en menos de dos horas tras recibir el reporte; Mozilla completó su propio bloqueo esa misma noche.
• Go en la trinchera: las versiones 1.27.3 y 1.26.10 incorporan un filtro que rechaza cualquier cadena con una de las ocho claves, bajo el identificador CVE-2026-111943.
• El flanco abierto: servidores backend, distribuciones Linux y dispositivos IoT no consultan listas de revocación y seguirán confiando hasta que su software se actualice.

Qué se comprometió exactamente

Los ocho certificados intermedios se crearon el 30 de abril de 2025 con validez hasta 2040 y se repartieron por región: la serie G3B quedó en manos de la neerlandesa eMudhra BV y la G3C en la estadounidense eMudhra Inc. Seis son emisores TLS —con validación de dominio, de organización y extendida— y encadenan a emSign Root TLS CA – G3; los otros dos son emisores de firma de código y cuelgan de emSign Root CS CA – G3. Dos semanas después de su creación, Sectigo los certificó de forma cruzada desde su raíz AAA Certificate Services, el mecanismo habitual para que una autoridad joven sea aceptada por dispositivos antiguos que nunca oyeron hablar de ella.

El agravante es estructural: un certificado intermedio no tiene fronteras geográficas ni de dominio. Salvo que imponga restricciones de nombre en X.509, algo que las autoridades públicas casi nunca hacen, puede firmar certificados válidos para google.com, para la API de una gran plataforma o para los endpoints internos de autenticación de cualquier empresa.

Una respuesta coordinada en menos de 72 horas

El investigador identificado solo como Wayne reportó la situación el 17 de octubre y demostró el control de las claves firmando digitalmente un mensaje con cada una de las ocho. Chrome recibió el aviso a las 18:05 UTC y a las 19:45 UTC ya había publicado una actualización de su CRLSet; Mozilla distribuyó el bloqueo OneCRL a las 22:59 UTC. Apple bloqueó los certificados el 19 de octubre, Microsoft el 20 y el resto de almacenes de confianza fue notificado el 19. El propio Dennis Jackson, ingeniero de criptografía de Mozilla, publicó las firmas y los certificados en un sitio de una sola página.

«We have a problem here – Wayne» — el mensaje que el investigador Wayne firmó con cada una de las ocho claves privadas comprometidas para demostrar el control de las mismas.

eMudhra revocó los ocho certificados y el registro compartido CCADB recogió el motivo como cACompromise (código de razón 2 de RFC 5280), la declaración formal de que la clave privada dejó de estar bajo control exclusivo de la entidad. Sectigo revocó sus certificados cruzados el 19 de octubre. Go liberó sus parches el 20 por la vía URGENT, que el proyecto reserva para amenazas a la integridad del ecosistema.

El punto ciego: servidores, contenedores y dispositivos conectados

Los navegadores reciben estas revocaciones por canal propio, sin reinstalar nada. El resto del mundo no. El verificador de Go no consulta datos de revocación ni lee listas de bloqueo de navegadores, de modo que necesitaba una modificación de código: el filtro compara el hash de la clave pública —no del certificado—, lo que también atrapa las copias cruzadas por Sectigo. Programas como Electron 44.9.1, 43.8.1 y 42.11.16, el paquete certifi de Python, webpki-roots de Rust y NSS 3.131.1 ya incorporan el bloqueo, mientras Node.js y el ca-bundle de Composer seguían pendientes. Go advirtió además que las ramas 1.25 y anteriores están fuera de soporte.

La recomendación de Mozilla para operadores de almacenes de confianza es escalonada: nada que hacer donde el cliente comprueba la revocación de forma fiable; bloquear los ocho intermedios donde el software lo permita; y, en el resto de casos, evaluar la retirada de confianza en las raíces que los firmaron. Según el programa de raíces de Chrome, ningún certificado encadenado a los seis intermedios TLS constaba en los registros de Certificate Transparency antes del bloqueo, por lo que ninguna credencial fraudulenta habría sido aceptada por defecto. Mozilla sostiene que no se emitieron certificados TLS públicos bajo esas raíces, salvo pruebas internas.

Lo que nadie ha explicado todavía es cómo salieron las claves. Las ocho fueron revocadas con el mismo motivo, lo que apunta a un sistema compartido más que a una clave aislada, pero se trata de una inferencia: no hay informe de incidente público, ni comunicación de la compañía, ni detalles sobre cuándo ocurrió. Tampoco se sabe si alguien además del investigador conserva copias. A ello se suma una señal inquietante: dos implementaciones de registros de Certificate Transparency empezaron a rechazar la inclusión de certificados emitidos por estas autoridades, una decisión que evita el spam de credenciales falsas pero también deja sin lugar donde documentar certificados forjados detectados en circulación. La comparación con el colapso de DigiNotar en 2011 ya circula entre especialistas. La lección práctica es que la confianza en la web sigue siendo binaria y que la velocidad de los navegadores no basta: el inventario de binarios Go, contenedores y firmware embebido sin actualizar es, hoy, la verdadera superficie de exposición.