Windows y Edge dejan de confiar en siete raíces ligadas a eMudhra: qué revisar en equipos aislados

Windows y Edge dejan de confiar en siete raíces ligadas a eMudhra: qué revisar en equipos aislados
0 0 votos
Valora la Publicación

Microsoft sacó el 26 de octubre de 2026 actualizaciones fuera de ciclo (por fuera del martes de parches mensual) para Windows que quitan de la lista de raíces confiables siete certificados ligados a eMudhra: seis raíces emSign G3 y la AAA Certificate Services de Sectigo, que también les daba validez a las CA comprometidas. El 27 de octubre hizo lo mismo en Microsoft Edge y en WebView2, el componente con el que muchas aplicaciones de escritorio muestran contenido web.

Es la continuación del incidente que contamos el 20 de octubre: las claves privadas de ocho CA intermedias de eMudhra se podían recuperar. Ahora Microsoft va un paso más allá de bloquear esas ocho claves y deja de confiar por defecto en las raíces que les daban validez.

Qué es una raíz y por qué sacarla es distinto de revocar

Cuando un navegador o un programa se conecta por HTTPS, recibe el certificado del servidor y arma una cadena hacia arriba: ese certificado lo firmó una CA intermedia, y a esa intermedia la firmó una raíz. Si la raíz está en la lista de confianza del sistema, la cadena vale.

En octubre se supo que ocho intermedias de eMudhra (seis para TLS y dos para firma de código) tenían claves tan débiles que cualquiera podía recuperarlas. Con esas claves se pueden fabricar certificados que el sistema aceptaría como legítimos: para hacerse pasar por un sitio o para que un malware parezca firmado por un editor confiable.

Hay dos formas de cortar eso, y Microsoft las separa con cuidado:

  • Revocar o bloquear las intermedias: eMudhra revocó las ocho, Sectigo revocó sus firmas cruzadas y Microsoft las bloqueó por su clave pública el 20 de octubre, en la lista de certificados no confiables de Windows (la «Disallowed CTL») y en el CRLSet de Edge (la lista de certificados bloqueados que el navegador recibe solo, sin actualizarse).
  • Quitar las raíces: una decisión más amplia. Deja de confiar por defecto en todo lo que cuelga de esas raíces, no solo en las ocho intermedias conocidas.

La razón del segundo paso está en el software que no consulta revocaciones ni la lista de no confiables de Microsoft. Mientras la raíz siga en su almacén, un certificado fabricado con las claves comprometidas todavía puede validar ahí.

Qué certificados salen y cuándo

Según el anuncio del Microsoft Trusted Root Program, los siete certificados quitados son:

  • emSign Root TLS CA - G3 y emSign ECC Root CA - G3.
  • emSign Root CS CA - G3 (firma de código) y emSign Root TSA CA - G3 (sellado de tiempo).
  • emSign Root Client Auth CA - G3 y emSign Root SMIME CA - G3 (correo firmado).
  • AAA Certificate Services de Sectigo. Sectigo había firmado en forma cruzada a las intermedias comprometidas, es decir, les había dado una segunda firma que les abría otro camino de confianza a través de esta raíz.

El calendario fue este:

  • 20 de octubre: bloqueo de las ocho claves en Windows y en Edge/WebView2.
  • 26 de octubre: Windows saca las siete raíces de su lista de confianza. Lo distribuye por el canal automático de listas de certificados y, para los equipos que no lo reciben, con las actualizaciones fuera de ciclo KB5134133 (Windows 11 24H2, 25H2 y 26H2), KB5134125 (Windows 10 21H2 y 22H2) y KB5134137 (Windows Server 2025).
  • 27 de octubre: Edge y WebView2 sacan las mismas siete con el componente PKI Metadata 72.0.0.0, que se actualiza solo.

Microsoft aclara que no fue un compromiso de sus sistemas sino un incidente de eMudhra, y que sigue evaluando por separado el resto de las raíces de esa CA.

A quién le toca hacer algo

Un equipo conectado que recibe las actualizaciones automáticas de la lista de certificados ya tiene el cambio, sin instalar nada. Las actualizaciones fuera de ciclo existen para el resto:

  • Equipos en redes aisladas o sin salida a internet.
  • Equipos que no llegan al servicio de actualización de certificados de Microsoft (por un proxy o un firewall, por ejemplo).
  • Equipos donde se desactivó por política la actualización automática de raíces.
  • Máquinas virtuales de Azure sin conexión, en Virtual Machine Scale Sets o sueltas: Microsoft publicó imágenes actualizadas en Azure Marketplace.

En Azure App Service para Windows la plataforma ya aplicó el cambio del sistema operativo, pero el equipo de App Service recuerda que no toca los almacenes de certificados que trae cada aplicación o runtime: esos se revisan aparte.

Qué revisar esta semana

  • Que el bloqueo llegó: en Windows, certutil -f -verifyCTL DisallowedWU | findstr SequenceNumber tiene que mostrar 01dd5f6ca45c9d86 o una posterior; en Edge, edge://components tiene que mostrar el CRLSet 2026.10.20 o posterior.
  • Los equipos desconectados: que el proceso de actualización interno les lleve la lista de no confiables y la nueva lista de raíces, o instalar el KB que corresponda. Microsoft lo explica en Configure trusted roots and disallowed certificates in Windows.
  • Las dependencias propias: buscar certificados de servidores, de firma o de clientes que encadenen a alguna de las siete raíces y reemplazarlos, o conseguir una cadena alternativa confiable, antes de que el cambio llegue a todos los equipos. Los que dependan de ellas van a empezar a fallar en la validación TLS.
  • No volver a confiar a mano: Microsoft admite que una organización puede confiar localmente en un certificado por compatibilidad, pero advierte que no se restaure la confianza en estas jerarquías sin entender el riesgo, sobre todo en software que no verifica revocaciones.

¿Saben qué raíces confían sus equipos aislados?

El incidente de eMudhra muestra que la confianza en una raíz no es eterna: cuando un navegador o un sistema operativo la saca, el que no tiene inventario de sus cadenas se entera por un error de TLS en producción.

¿Ya revisaron qué servicios dependen de estas raíces y cómo actualizan los equipos sin internet? Te leemos en los comentarios.

Fuentes

Escrito por

Pablo Ariel Di Loreto

Profesor. Informático. Fanático del helado de dulce de leche. Director de Ingeniería en MODO, y Secretario del Microsoft Users Group Asociación Civil. Además, soy owner de iniciativas como ConoSurTech y Aprender IT.

Ver todas las entradas de Pablo Ariel Di Loreto →
Suscribirse
Notificarme de
guest

0 Comentarios
Viejos
Nuevos Más votados
Scroll al inicio
0
Nos encantaría conocer tu opinión: ¡comenta!x