eMudhra abandona el negocio global de TLS tras el fallo de sus claves
eMudhra, la autoridad certificadora india, anunció que se retira del negocio global de certificados SSL/TLS después de que se descubrieran ocho certificados intermedios con claves privadas tan débiles que cualquiera podía reconstruirlas. El consejo tomó la decisión el jueves, dos días después de que los investigadores hicieran público el hallazgo, según Ars Technica.
El dato que mejor dimensiona el problema: una de esas claves privadas era el número 4. Las otras eran 56, 66, 115, 155, 156, 230 y 237. Una clave de curva elíptica NIST P-384 debería contener unos 384 bits de entropía, con 2^384 combinaciones posibles, un número de 116 dígitos. Las ocho claves comprometidas tenían entre 3 y 8 bits: la más fuerte ofrecía un máximo de 256 posibilidades.
V. Srinivasan, presidente de eMudhra Limited, justificó la salida con el aumento de costos y complejidad de los requisitos de compliance, sumado a que el negocio TLS generaba apenas el 1% de los ingresos de la compañía. También mencionó que la aparición de organizaciones que entregan certificados TLS gratis redujo el retorno de inversión frente a otros productos y servicios de la empresa.
¿Y esto cómo se aplica en tu negocio?
En CAR, dueños de empresa de Latinoamérica y España usan la tecnología para ser más rentables. Empiezas con una ruta de 7 días y terminas con un sistema funcionando en tu negocio.
👥 Probar 7 díasLa compañía fue más explícita en su comunicado: «el nivel de amplificación en redes sociales alrededor de este incidente trajo un escrutinio desproporcionado al lugar que ocupa SSL/TLS en nuestro negocio». Y agregó que, tras deliberaciones detalladas, el consejo concluyó que retirarse del SSL/TLS global «es la decisión correcta para eMudhra y sus accionistas».
Cómo se generaron claves privadas de 4 bits
eMudhra dijo que creó los ocho certificados en una ceremonia de generación de claves (KGC) el 30 de abril de 2025. Un fallo en el paso de wrap/unwrap produjo un segundo juego de claves débiles junto a las originales fuertes, y las débiles fueron las que se publicaron en los root stores de los navegadores, según reportó The Next Web.
El investigador identificado solo como Wayne reportó el problema el 17 de octubre a los programas de raíces de los navegadores, firmando el mensaje «We have a problem here – Wayne» con cada una de las ocho claves, según el sitio de divulgación del ingeniero de Mozilla Dennis Jackson. El investigador de seguridad Scott Helme contó que recuperó las ocho claves desde los certificados públicos en su laptop en menos de un segundo.
eMudhra sostiene que nunca usó esos ocho certificados para emitir certificados a sitios web o usuarios, y que sus sistemas no fueron vulnerados. Su negocio indio de firmas digitales y eSign corre sobre infraestructura separada y no está afectado, según la empresa.
La respuesta de los navegadores fue casi instantánea
Chrome recibió el reporte a las 18:05 UTC y bloqueó los seis certificados usados para sitios web a las 19:45 UTC, según un post de Google. Mozilla terminó de empujar el bloqueo a los usuarios de Firefox a las 22:59 UTC. Apple bloqueó los certificados el 19 de octubre y Microsoft el 20, según The Next Web.
Chrome eliminará la raíz emSign ECC Root CA – G3, de la que cuelgan los seis certificados, el 27 de octubre. Mozilla ya la quitó de su lista de confianza el 20 de octubre. Google aclaró que ningún certificado de sitio encadenado a esos seis había aparecido en los logs de Certificate Transparency antes del bloqueo, por lo que ningún certificado falsificado podría haber funcionado contra clientes que exigen CT logging, como Chrome.
El efecto dominó: 30.000 certificados y una cola larga
Unos 30.800 certificados sin vencer encadenaban a esa raíz al 21 de octubre, según el conteo de Chrome sobre los logs públicos de CT. El 99,9% se había emitido a través de InCommon, el servicio de certificados que Internet2 creó para la comunidad de educación superior, que migró su servicio a la plataforma CertiNext de eMudhra entre abril y julio de este año, según The Hacker News.
eMudhra estima que hay que mover unos 30.000 certificados y que el 97% se emitió usando ACME, el protocolo que muchos servidores usan para pedir y renovar certificados de forma automática. Chrome advirtió que los clientes ACME estándar no reemplazan certificados fuera de su ventana de renovación, salvo que soporten ACME Renewal Information (ARI) o que alguien intervenga a mano.
Cornell pidió a sus titulares de certificados que soliciten certificados RSA en lugar de ECC, y contabiliza más de 300 certificados afectados propios. La Universidad de Michigan señaló que su alternativa principal por ahora es Let’s Encrypt.
Filippo Valsorda, mantenedor de criptografía del lenguaje Go, le dijo a Ars Technica: «Será un trabajo de limpieza masivo, más grande que Heartbleed. Habrá una cola muy, muy larga: dispositivos IoT, contenedores Docker, máquinas Linux olvidadas, herramientas CLI sin mantenimiento que traen su propia copia de las raíces».
Por qué el negocio de certificados dejó de ser rentable
El argumento comercial de eMudhra tiene respaldo en los números del sector. Let’s Encrypt comenzó a emitir certificados gratuitos en 2015 y hoy provee TLS a más de 600 millones de sitios web, lo que la convierte en la autoridad certificadora más grande del mundo, según TechSpot. Competir contra un proveedor sin costo y con esa escala es una batalla cuesta arriba para cualquier CA regional.
La presión no se detiene ahí. Help Net Security reportó que Let’s Encrypt bajará la vida útil por defecto de sus certificados de 90 a 64 días a partir del 10 de febrero de 2027, como paso previo a ciclos de 45 días en 2028. Certificados más cortos significan más renovaciones automatizadas y menos margen para servicios manuales.
Qué significa esto para tu startup
El episodio deja tres lecciones operativas que aplican a cualquier equipo con infraestructura propia, sin importar el tamaño.
- Audita tus certificados hoy, no cuando venzan. Si tienes certificados emitidos por eMudhra, revisa si cuelgan de la raíz ECC afectada o de la jerarquía RSA emSign Root CA – G1, que por ahora sigue siendo confiable. La propia eMudhra dijo que G1 era «la única alternativa disponible» dentro de su ecosistema.
- Automatiza la renovación con clientes que soporten ARI. El 97% de los certificados afectados se emitió por ACME. Si tu cliente ACME no soporta ACME Renewal Information, no va a reemplazar el certificado fuera de su ventana normal y vas a tener que hacerlo a mano.
- No dependas de una sola autoridad certificadora. El caso muestra que la confianza en una CA puede desaparecer en cuestión de horas por una decisión de Google o Mozilla. Tener un plan B probado, y saber cuánto tarda tu equipo en cambiar de jerarquía, es parte del diseño de infraestructura.
- Revisa la cola larga. Los navegadores se actualizan solos, pero los contenedores Docker, los dispositivos IoT y las máquinas Linux sin mantenimiento no. Si tu producto corre en entornos embebidos o en clientes que no actualizan software, ese inventario merece una revisión propia.
El costo reputacional y regulatorio
El golpe no fue solo técnico. Las acciones de eMudhra cayeron 20% el 21 de octubre y tocaron el límite inferior de cotización, según Mathrubhumi. El Ministerio de Electrónica y Tecnología de India (MeitY) formó un equipo especial para investigar el incidente, y CERT-In emitió el aviso CIAD-2026-0050 el 21 de octubre pidiendo actualizar navegadores y sistemas operativos y reemplazar los certificados afectados.
También quedaron preguntas abiertas sobre la gestión del incidente. En 2025, eMudhra había publicado listas de revocación (CRL) inválidas para seis de esos mismos intermedios, y en octubre de este año publicó una CRL para emSign Root TLS CA – G1 cuya firma no verifica contra la clave de esa CA, según el investigador que reportó las claves débiles. Chrome dijo que esa revelación «genera serias preocupaciones sobre la transparencia y el manejo de incidentes de eMudhra».
Conclusión
El retiro de eMudhra del negocio global de TLS es, en el papel, una decisión de portafolio: un segmento que aportaba el 1% de los ingresos y cargaba costos crecientes de compliance. Pero el detonante fue otro: ocho claves privadas que debían ser números aleatorios de 384 bits y terminaron siendo valores como 4, 56 o 230.
Para un founder, la lección no es sobre eMudhra en particular. Es que la confianza en internet se apoya en un puñado de decisiones técnicas que se toman una sola vez y casi nadie audita después. Revisar de dónde cuelgan tus certificados, automatizar la renovación y tener un plan B probado cuesta poco hoy y evita una semana de incendio mañana.
Fuentes
- Ars Technica: Disgraced eMudhra drops out of TLS business
- The Hacker News: eMudhra to Exit Global SSL/TLS Business
- The Next Web: Eight eMudhra certificate keys were so weak that one was the number 4
- Mathrubhumi: Weak keys, fake websites, 20% crash
- Ars Technica: The Internet goes on high alert after discovery of 8 compromised TLS certs
- Help Net Security: Let’s Encrypt TLS certificate lifetimes to drop from 90 to 64 days
- TechSpot: Let’s Encrypt is now issuing free TLS certificates for IP addresses
¿Y esto cómo se aplica en tu negocio?
En CAR, dueños de empresa de Latinoamérica y España usan la tecnología para ser más rentables. Empiezas con una ruta de 7 días y terminas con un sistema funcionando en tu negocio.
👥 Probar 7 días
