eMudhra anunció el 22 de octubre de 2026 su retirada del negocio global de certificados SSL/TLS. El anuncio llega tras el compromiso de ocho certificados de CA intermedias. Si administras una web, una API o un VPS, hay dos tareas distintas: sustituir las cadenas que perderán confianza y actualizar los clientes que todavía aceptan las claves comprometidas.
Información revisada el 22 de octubre de 2026. Distinguimos el plan anunciado por el proveedor, las medidas de los navegadores y las actualizaciones de aplicaciones. No es una auditoría de servidores de clientes.
22 de octubre: eMudhra anuncia su salida del negocio SSL/TLS
En su comunicado del 22 de octubre, eMudhra anuncia una retirada voluntaria del negocio global de certificados SSL/TLS. No dice que vaya a cerrar todos sus servicios ni que deje inmediatamente de atender a sus clientes: sus raíces RSA G1 seguirán dando servicio durante la transición, según la compañía.
La empresa promete reemplazos gratuitos mediante socios y mantener los servicios de revocación y estado hasta que los certificados emitidos expiren o se sustituyan. También afirma que sus servicios de firma digital, eSign, PKI empresarial e identidad continúan. Es un plan anunciado, no una migración ya completada. El comunicado no fija una fecha única de cierre para todos los clientes.
Para tu web, la decisión práctica es pedir por escrito la nueva jerarquía de confianza, el responsable de instalarla y el calendario de transición. No esperes a la caducidad normal de un certificado que perderá confianza antes.
Alcance real: ocho intermedias no son 30 000 víctimas
| Dato | Qué significa | Qué no demuestra |
|---|---|---|
| 8 certificados intermedios | 6 de TLS y 2 de firma de código con claves recuperables. | No son ocho sitios web; una CA puede autorizar otros certificados. |
| Unos 30 000 certificados | Estimación inicial de eMudhra, del 20 de octubre, que requerían migración de la jerarquía G3. | No es un recuento de ataques, personas o servidores comprometidos. |
| Aproximadamente 97 % vía ACME | Proporción reportada por eMudhra dentro de esa estimación de migración. | No garantiza que un cliente ACME renueve antes de la retirada de confianza. |
| 27 de octubre, mañana PDT | Despliegue general previsto por Chrome para retirar la raíz G3 de su almacén. | No es una fecha hasta la que todos los clientes sigan aceptándola: otros ya la retiraron. |
Fuentes: registro del incidente, estimación de eMudhra del 20 de octubre y calendario de Google. No presentamos esas estimaciones como un inventario final auditado.
El aviso de CERT-In del 21 de octubre distingue el servicio internacional de los servicios domésticos de firma digital de India y señala que los reportes citados no establecen explotación maliciosa confirmada. Eso no elimina el riesgo para clientes sin actualizar. Tampoco supone que el algoritmo P-384 esté roto: el problema fue la generación de claves con insuficiente aleatoriedad.
Qué pasó con los certificados de eMudhra
El registro público del incidente identifica ocho certificados de autoridades de certificación intermedias: seis para TLS y dos para firma de código. Mozilla recuperó sus claves privadas de forma independiente. Su investigación encontró que los ocho valores privados de P-384 eran inferiores a 256.
Una CA intermedia puede firmar otros certificados dentro de las facultades que recibe de una raíz. El alcance, por tanto, va más allá de la clave de una sola web. Conviene distinguir tres elementos al revisar el caso: la raíz de confianza, los certificados intermedios y el certificado que presenta cada servicio.
Por qué una clave con valor 4 no protege una CA
El análisis independiente de Scott Helme describe una clave cuyo valor era 4: un solo dígito, no cuatro dígitos. La referencia a unos 116 dígitos expresa la escala decimal del espacio de valores de P-384, no una regla de formato que garantice seguridad. Lo decisivo es generar valores impredecibles con suficiente entropía; añadir ceros a un número pequeño no lo hace seguro.
La recuperación documentada de claves débiles no demuestra un robo tras una intrusión. En Bugzilla, eMudhra atribuye preliminarmente el fallo al proceso de generación y selección de claves; la investigación sigue abierta.
Qué hizo Firefox y cuál era el riesgo
Según Mozilla, un atacante capaz de interceptar una conexión podía usar certificados fraudulentos para suplantar sitios. La aceptación dependía de que el cliente siguiera confiando en esa cadena. Firefox completó el bloqueo mediante OneCRL el 17 de octubre a las 22:59 UTC, 2 horas y 53 minutos después del aviso, para configuraciones estándar y sin reinicio. El 20 de octubre publicó Firefox 158.0.1 y ESR 115.43.1/153.5.1 para cubrir también configuraciones que no recibieran OneCRL.
Actualización del 21 de octubre: Mozilla publicó Firefox para Android 158.0.2 a las 08:29 UTC para corregir casos en los que la lista OneCRL incluida no se aplicaba inmediatamente al iniciar. En Android, instala también esta actualización.
No hay base para afirmar que todo HTTPS quedó roto ni que todas las webs fueron atacadas. La capacidad técnica, la confianza del cliente y la evidencia de explotación son cuestiones distintas.
eMudhra afirma que sus raíces y otros certificados intermedios no están afectados y que ninguno de los ocho había emitido certificados finales. Son declaraciones de la compañía, no una conclusión independiente de que todos los sistemas estén protegidos. Retirar la confianza en una raíz no demuestra que su clave privada estuviera comprometida.
Chrome: retirada de emSign ECC Root CA–G3 el 27 de octubre
Google anuncia la retirada de emSign ECC Root CA–G3 del Chrome Root Store, cuyo despliegue general está previsto para la mañana del 27 de octubre de 2026, horario del Pacífico (PDT). Si tu servicio depende de esa raíz, pide un certificado bajo otra jerarquía confiable e instálalo antes. Google también afirma que los clientes con Certificate Transparency obligatorio estaban protegidos frente a esta vía. No extrapoles esa protección a cualquier cliente.
Qué revisar en tu hosting, VPS o aplicación
Proponemos este procedimiento para organizar el trabajo. Adáptalo a tus servicios y al canal oficial de soporte de cada componente.
1. Separa las conexiones entrantes y salientes
Haz dos listas: los dominios y API que atiendes, y los servicios HTTPS a los que se conectan tus aplicaciones. Incluye webhooks, tareas programadas, integraciones, agentes de monitorización y entornos de pruebas. Asigna a cada elemento un responsable y una prueba de aceptación.
Si tienes CDN o proxy, registra por separado el tramo público y el tramo hacia el origen. Una revisión de la portada de la web no sustituye una comprobación de las rutas que usa tu aplicación.
2. Identifica la cadena real y el almacén que la valida
Desde un equipo de administración con OpenSSL puedes consultar un dominio propio o que estés autorizado a revisar. Sustituye el nombre del ejemplo:
openssl s_client -connect example.com:443 -servername example.com -showcerts -verify_hostname example.com -verify_return_error < /dev/null
Tu proyecto en un VPS, con responsabilidades claras
Compara recursos para tu web o API y define quién mantiene certificados, aplicaciones y sistema. Elegir un VPS no sustituye su mantenimiento.
La documentación de OpenSSL explica que -showcerts muestra los certificados enviados por el servidor, no una cadena ya verificada. La raíz puede no aparecer. -verify_hostname comprueba el nombre y -verify_return_error detiene la conexión si falla la validación. El resultado depende del almacén local; un éxito no prueba protección universal ni ausencia de compromiso.
Para inspeccionar un certificado público guardado en PEM, sin abrir ni compartir una clave privada:
openssl x509 -in certificado.pem -noout -subject -issuer -serial -dates -fingerprint -sha256
Este comando muestra identidad, emisor, vigencia y huella; no calcula la fortaleza de una clave privada ni certifica que toda la cadena sea confiable. Contrasta la identificación con el aviso de tu proveedor. Referencia de openssl x509.
3. Actualiza los componentes que realmente hacen TLS
Cloudflare recomienda actualizar sistemas, runtimes y paquetes de CA, incluidas las imágenes de contenedores. Una aplicación puede utilizar un almacén distinto al navegador. No soluciones un error nuevo desactivando la validación TLS. Su afirmación de no haber observado explotación activa se limita a sus propios servicios; no demuestra ausencia global de ataques.
Como control de despliegue, registra qué paquete o imagen cambió, cuándo quedó activo y qué instancia se comprobó. Prueba la integración desde el mismo runtime que atiende producción. Un ticket marcado como resuelto debe incluir evidencia del cambio, no solo una instalación prevista.
4. Sustituye la cadena cuando corresponda y comprueba el resultado
- Confirma el alcance: dominio, punto de terminación TLS, emisor y dependencia de la raíz retirada.
- Coordina la reemisión: solicita al proveedor una jerarquía alternativa confiable. Confirma qué certificado y cadena completa debes desplegar.
- Prepara el cambio: conserva la configuración necesaria para recuperar el servicio sin reintroducir confianza insegura. Define responsable y ventana de ejecución.
- Verifica después: revisa dominio y cadena servida, navegadores y clientes de API relevantes. Prueba también las renovaciones automatizadas.
Python, Node.js y contenedores: el navegador no los actualiza
El aviso de Python ya recomienda certifi 2026.10.19, pip 26.2.2 y uv 0.13.4 o versiones posteriores, además de revisar sigstore, Conda y Pixi si se utilizan. Python 3.15.1, 3.14.9 y 3.13.17 incorporan el pip corregido, pero los entornos virtuales anteriores requieren atención por separado. Consulta nuestra guía de eMudhra en Python: diagnóstico y actualización de pip, certifi y uv.
Node.js también publicó correcciones el 21 de octubre. Nuestra guía de Node.js 22.23.4, 24.22.1 y 26.12.1 explica los cambios y el bloqueo de claves eMudhra, incluido el límite de las sesiones TLS reanudadas. Actualizar paquetes en el host no reemplaza los runtimes ni almacenes de CA que una imagen antigua lleva dentro.
Preguntas frecuentes
¿Debo reemplazar todos mis certificados?
No decidas solo por el titular. Determina qué cadenas usas y sigue las instrucciones aplicables a ellas. Pide al proveedor una respuesta específica para tus dominios.
¿Cambiar contraseñas o migrar de hosting resuelve esto?
Son decisiones diferentes de gestionar la confianza TLS. Prioriza la cadena y los clientes implicados; si hay señales de intrusión, abre además el procedimiento de respuesta correspondiente.
¿Qué debo pedir a mi proveedor?
Una confirmación escrita del alcance, el responsable de cada cambio, la cadena de reemplazo si corresponde y la prueba de funcionamiento. Evita una respuesta genérica de «todo actualizado» sin identificar servicios.
Organiza el mantenimiento de tu proyecto
Para evaluar infraestructura, consulta los planes de VPS de TERAMONT y acuerda quién mantiene certificados, aplicaciones y sistema. Si estás empezando, esta guía explica qué es un VPS y sus responsabilidades. Contratar recursos no sustituye una revisión de seguridad.
