Todos los artículos

Una CA perdió la confianza de la web. ¿Lo sabe tu app Node?

Seguridad · 4 min de lectura ·

En la semana del 18 de octubre de 2026, una autoridad de certificación perdió la confianza de la web. Según el rastreador de incidentes pwn.watch, un investigador informó de que las claves privadas de ocho CA intermedias de eMudhra Global TLS eran criptográficamente débiles y podían recuperarse; Mozilla, Chrome, Apple y Microsoft bloquearon esas intermedias, y eMudhra las revocó el 19 de octubre. El 22 de octubre la empresa anunció que abandona el negocio global de certificados SSL/TLS. Si escribes PHP o Node.js, a tu navegador lo protegió su fabricante. Tus servicios de backend solo quedaron protegidos si alguien los actualizó.

Qué pasó, según la empresa y según el rastreador

El comunicado de eMudhra dice que revocó las CA afectadas "within 14 hours of discovery" y que lo comunicó con rapidez. Esa cifra es de la propia empresa. También dice que no se emitió ningún certificado final desde esas CA, que su infraestructura no fue comprometida, que no se filtraron datos y que el SSL/TLS global supone alrededor del 1 % de sus ingresos. Sus raíces G1 RSA seguirán atendiendo a los clientes durante la transición, los clientes afectados reciben certificados de reemplazo gratis a través de socios, y los servicios de revocación y estado siguen activos hasta que cada certificado emitido haya caducado o se haya sustituido.

El rastreador pwn.watch añade que la raíz ECC dejó de ser de confianza como precaución, y que los runtimes que llevan su propio almacén de confianza, entre ellos cita Go, Node.js, Electron, certifi de Python y curl, necesitaron una actualización urgente de su paquete de CA. La publicación de seguridad de octubre de 2026 del proyecto Node.js confirma su parte: incluye una actualización de ca-cert por la "eMudhra Intermediate CA Compromise" en las ramas 26.x, 24.x y 22.x.

CA raíz en el almacén firma CA intermedia clave débil firma Certificado final api.example Sin confianza o revocada: lo de abajo falla
Un cliente confía en un certificado final por la cadena que tiene encima. Quita la intermedia y la cadena se corta ahí.

La lista de tu navegador no es la de tu servidor

Esta parte es conocimiento general sobre cómo funcionan los clientes TLS, no un detalle del incidente. Un cliente TLS decide en quién confiar a partir de una lista de certificados raíz, su almacén de confianza. Los navegadores y los sistemas operativos traen la suya y la actualizan solos. Muchos runtimes y librerías llevan en cambio su propia copia: Node.js incluye la lista de Mozilla dentro de cada versión, y el código Python que usa certifi confía en el archivo de certifi. Otros runtimes leen el almacén del sistema salvo que se les indique otra cosa, así que revisa la documentación del tuyo en lugar de suponer.

Por eso una retirada de confianza llega a cada uno a distinta velocidad. Chrome en tu portátil se actualizó solo. Un servicio Node que llama a una API de pagos desde una imagen Docker que construiste en agosto sigue llevando la lista de agosto, y seguirá confiando en una intermedia revocada hasta que cambie el runtime o el paquete dentro de esa imagen.

Navegador se actualiza solo Almacén del SO con el SO Paquete runtime Node, certifi Imagen Docker fija al construir Tu servicio Node llamando a una API no lo usan los servidores discontinuo: depende del runtime y de cómo se construyó la imagen
Cuatro listas, cuatro calendarios de actualización. Una app de backend confía en la que traía al construirse.

Qué hacer esta semana

Actualiza el runtime de cada servicio y después reconstruye y vuelve a desplegar las imágenes, porque una versión nueva de Node.js en tu portátil no cambia nada dentro de una imagen que ya está corriendo. Donde haya Python, actualiza también certifi.

node --version
docker build --pull --no-cache -t my-api .
pip install --upgrade certifi

Si una llamada empieza a fallar con un error de certificado después de actualizar, esa es la protección funcionando. No pongas NODE_TLS_REJECT_UNAUTHORIZED=0 ni pases rejectUnauthorized: false para quitártelo de encima: eso desactiva la verificación en todas las conexiones del proceso, no solo en la que falla. Averigua qué certificado presenta el otro lado y consigue que lo sustituyan; eMudhra dice que los clientes afectados reciben el reemplazo sin coste.

Apunta de dónde saca cada servicio su lista de CA, y convierte "actualizar el runtime y reconstruir la imagen" en una tarea mensual, no en una respuesta a un incidente.

Siguiente paso: abre el Dockerfile de tu servicio más antiguo en producción, mira la fecha de su imagen base y reconstrúyelo hoy. Después añade monitorización de caducidad de certificados y de Certificate Transparency para tus propios dominios, para que el próximo cambio en quién los emite te llegue a ti antes que a tus usuarios.

Fuente: comunicado de prensa de eMudhra, 22 de octubre de 2026, y las publicaciones de seguridad de Node.js de octubre de 2026.

Notas de los lectores

  1. Todavía no hay notas. La primera siempre es la más valiente.
¿Estás construyendo algo parecido? Puedo ayudarte. Escríbeme por WhatsApp