Fuentes consultadas el 22 de octubre de 2026, hora de Beijing. Audiencia: usuarios individuales, operadores de sitios web, desarrolladores y administradores de sistemas.
Graves debilidades hicieron que un grupo de claves privadas eMudhra/emSign intermedias CA fueran recuperables. Esto afecta a los clientes que utilizan el sistema de certificados públicos para autenticar sitios web, API y software. La confianza pública abarca los principales sistemas operativos, pero el conjunto de claves comprometidas y el impacto potencial en el cliente tienen alcances diferentes. 15
El texto principal utiliza corchetes para numerar las fuentes correspondientes, y todos los enlaces de referencia externos se enumeran en el apéndice. La versión enumerada es la versión base confirmada que contiene la solución para este incidente a partir de la fecha de verificación. Al implementar, se da prioridad a la versión estable actualizada en la misma rama compatible.
TL;DR
Echo claves privadas intermedias CA se confirman comprometidas. Los informes actuales no establecen que las claves privadas raíz o la criptografía HTTPS en general hayan sido violadas. Las actualizaciones abarcan gran parte del ecosistema de confianza pública; El riesgo residual depende de la aplicación real.15
- Usuarios individuales: actualiza navegadores, sistemas operativos y componentes de seguridad. En Android, actualice también los servicios Google Play. Utilice Firefox Android 158.0.2 o posterior. 12
- Servidores : actualiza los paquetes
ca-certificates/NSS de la distribución y verifica los almacenes de confianza incluidos en las aplicaciones. Actualizar sólo el host es insuficiente. 7810 - Entornos de desarrollo: actualice Node 24 a 24.22.1 o una versión más reciente en esa rama, según corresponda. En entornos Python, actualice al menos a pip 26.2.2, certifi 2026.10.19 y uv 0.13.4. Obtenga archivos binarios Go fijos o reconstrúyalos; actualice Java de acuerdo con el aviso de su proveedor. 12–15
- Active las actualizaciones: reinicie los servicios afectados y reconstruya y vuelva a implementar contenedores. Para Cloudflare Tunnel, actualice cloudflared a 2026.10.2 o posterior. 7
- Certificados de sitio web: reemplazan una cadena afectada si contiene un CA intermedio revocado o bloqueado, o si depende de una raíz que no es de confianza. La reemisión de un certificado no reemplaza la actualización de los almacenes de confianza del cliente. 158
- Verificación: prueba la ruta TLS real de cada aplicación. Distinga el rechazo de certificados de los tiempos de espera y los errores de DNS. Mantenga habilitada la verificación del certificado; no utilice
-kni omita la verificación para suprimir errores. 7
1 Hechos y causas del incidente.
hechos confirmados
Mozilla y Google han confirmado defectos en ocho claves privadas intermedias eMudhra CA. El investigador proporcionó pruebas de control de clave privada; Mozilla recuperó las claves de forma independiente y reprodujo el problema. Seis CA intermedias prestan servicio a TLS y dos sirven a la firma de código. 25
El defecto radica en las claves generadas: estas CA intermedias utilizan la curva P-384, pero sus claves privadas son números enteros inferiores a 256. Esto está lejos de seleccionar claves al azar de forma segura del amplio rango previsto. La recuperación de estas claves débiles no demuestra que las claves P-384 generadas correctamente puedan romperse. 2
El “certificado descifrado” aquí debe entenderse con precisión como “la clave privada correspondiente se puede recuperar”. El certificado y la clave pública que contiene son inherentemente públicos; lo que realmente debe mantenerse en secreto es la clave privada que puede generar una firma válida.
Los problemas del proceso de generación de claves aún están bajo investigación
Una descripción inicial de eMudhra remonta el problema a una ceremonia de generación de claves en abril de 2025. La explicación implica un paso de encapsulación y desencapsulación de claves: además de la clave segura original, aparece otro conjunto de claves débiles, y las claves débiles se utilizan posteriormente para la solicitud y emisión de certificados. La compañía aún dijo que la causa raíz exacta no se ha determinado de manera concluyente. 6
Por tanto, lo que se puede determinar es que dichas claves son seriamente débiles y han sido comprometidas; La falla no puede describirse con más detalle ya que se ha demostrado que cierta fuente de números aleatorios de hardware de HSM es defectuosa, ni puede describirse como un avance criptográfico general de RSA, ECC o TLS.
¿Qué significa la desconfianza en el certificado raíz?
El navegador o el sistema operativo puede bloquear directamente el certificado o la clave pública del CA intermedio afectado, o puede eliminar la confianza raíz que conduce a ellos. Esta última medida también rechazará algunos certificados legítimos bajo la misma raíz.
Google ha programado la eliminación de emSign ECC Root CA - G3 para proteger a los usuarios del almacén raíz Chrome que no reciben actualizaciones de CRLSet. Se espera que la eliminación del almacén raíz se impulse durante el período correspondiente del 27 al 28 de octubre, hora de Beijing; la hora original de Google es la mañana del 27 de octubre, hora de verano del Pacífico de EE. UU. Este plan es independiente del bloqueo de clave pública de emergencia que se implementó anteriormente. 1
Desconfiar de un root es una medida de respuesta; no prueba por sí solo que la clave privada raíz haya sido comprometida.
2 Por qué el impacto potencial abarca todo el ecosistema de confianza pública
Claves comprometidas y rutas de confianza afectadas
| Objeto de juicio | El alcance de este incidente. |
|---|---|
| Clave problemática identificada | 8 claves privadas intermedias CA para eMudhra |
| Plataformas que pueden requerir acción | Almacén raíz público, navegador, sistema operativo, tiempo de ejecución de lenguaje, paquete de software y ecosistema de contenedores |
| Posible identidad suplantada TLS | Sitios web o servicios visitados por clientes que aún aceptan la cadena de certificados falsificados asociada |
| ¿Significa que todos los dispositivos se han visto comprometidos? | No; Las condiciones de confianza, la ubicación de la red del atacante y otras estrategias de verificación determinan la explotabilidad. |
| ¿Significa esto que todos los certificados legales no son válidos? | No; la invalidación asociada depende de qué raíces o cadenas de certificados no sean de confianza para el cliente. |
Red Hat limita explícitamente la explotación a condiciones en las que el cliente aún acepta la cadena relevante, el atacante posee la clave privada comprometida y puede interceptar la conexión en la red. La cobertura de riesgos no debe confundirse con el número de ataques ocurridos. 10
Los sitios web que utilizan otros CA también pueden ser suplantados.
Supongamos que un sitio web realmente utiliza el certificado Let’s Encrypt y el cliente del visitante confía en varios CA públicos al mismo tiempo. Un atacante podría intentar utilizar el intermedio comprometido CA para crear otro certificado para el mismo nombre de dominio. Los clientes generalmente no requieren por adelantado que el nombre de dominio solo pueda usar Let’s Encrypt; Si aún se acepta la cadena falsa, el CA que realmente utiliza el sitio web no es suficiente para descartar tales ataques. 8
Este mecanismo explica: Reemplazar otro certificado CA que originalmente era normal no reparará automáticamente la confianza del cliente en el CA comprometido. Lo que realmente hay que cortar es el camino para que los clientes acepten identidades falsas.
Los tres efectos deben tratarse por separado.
Riesgo de suplantación de identidad: Los clientes que no han bloqueado la cadena relevante pueden aceptar la identidad falsificada por el atacante, lo que provoca que se envíen solicitudes confidenciales a servicios falsos.
Riesgo de disponibilidad de servicio legítimo: eliminar la confianza raíz puede causar errores de certificado para sitios web legítimos, que pueden necesitar migración a otra cadena aceptada.
Riesgo de cobertura de implementación: el sistema operativo puede repararse mientras un almacén de confianza empaquetado con aplicaciones, un entorno virtual, una imagen de contenedor antigua o un programa compilado conserva el comportamiento de validación anterior.
Estos tres ámbitos no son idénticos. La respuesta de Cloudflare cubre la validación de identidad remota, almacenes de confianza compartidos, imágenes base y aplicaciones individuales, lo que ilustra por qué las dos últimas tareas deben manejarse por separado. 7
3 CA y proveedores de certificados afectados
Proveedor y tipo de impacto
| proveedor o sistema | Papel en este incidente | Límites que es necesario distinguir |
|---|---|---|
| eMudhra／emSign | La clave privada intermedia CA se ve comprometida directamente. | No puede escribir todas las raíces eMudhra y todos los certificados como descifrados |
| Cadena de firma cruzada relacionada con Sectigo | Se emitió el certificado cruzado A para el mismo lote de claves públicas afectadas, formando otra ruta de confianza. | Es necesario bloquear el certificado cruzado o la clave pública correspondiente; No se ha demostrado que la clave privada raíz Sectigo esté comprometida. |
| Niveles de certificado relevantes para Internet2/InCommon | Algunos certificados legítimos dependen de la eliminación de la raíz emSign ECC, lo que implica migración | Es un impacto colateral de la desconfianza de la raíz y no puede contarse como la mitad de esas 8 claves débiles CA |
| Let’s Encrypt, DigiCert, Google Trust Services, GlobalSign, etc. | No figura como la parte cuya clave privada se vio comprometida en este informe | Los certificados legítimos no se invalidan uniformemente; Los clientes vulnerables aún pueden aceptar certificados falsos que se hacen pasar por los sitios web a los que sirven. |
| CDN, plataforma en la nube, distribuidor certificado | Posiblemente proporcione certificados relevantes o utilice un almacén de confianza público al conectarse al origen y API | Para verificar la cadena de certificados y el validador reales, no mire solo la plataforma o el nombre del producto. |
El aviso de Mozilla documenta las claves comprometidas y las firmas cruzadas de Sectigo. La discusión pública sobre incidentes de Google aborda la migración de jerarquías legítimas de Internet2/InCommon. 25 Cloudflare corrige el servicio de direcciones y la confianza del cliente; no indican un compromiso de las claves privadas CA del propio Cloudflare. 7
Cadena de certificados TLS y firma cruzada
La siguiente relación esta vez solo describe las rutas relacionadas con TLS. No incluye rutas de firma de código, ni significa que estas rutas sigan siendo confiables en todas las plataformas. 17
emSign ECC Root CA - G3→emSign Root TLS CA - G3→ TLS afectada Clave pública intermedia CA → Certificado falsificado para el dominio de destinoAAA Certificate Services→ TLS afectada Clave pública intermedia CA → Certificado falsificado para el dominio de destino
emSign Root TLS CA - G3 es un emisor directo de los productos intermedios TLS afectados y puede ser en sí mismo un ancla de confianza en algunas tiendas. emSign ECC Root CA - G3 proporciona otra capa de firma cruzada. AAA Certificate Services de Sectigo crea una ruta adicional a las mismas claves públicas intermedias CA. 17
Por tanto, existen dos granularidades diferentes a la hora de reparar:
- Bloquee el CA intermedio exacto o la clave pública:. Esto puede preservar otras jerarquías legítimas bajo la misma raíz, donde el validador admite ese mecanismo.
- Reliminar la confianza raíz: esto puede proteger a los clientes sin capacidades de bloqueo intermedias de CA, pero puede afectar la compatibilidad. También se deberán recorrer todos los demás caminos que el cliente acepte. 5
“Eliminar todas las raíces Sectigo/eMudhra” no debe tomarse como un paso general indiscriminado, ni la simple eliminación de un certificado con un nombre similar debe significar que todas las rutas están cerradas.
4 Cobertura del sistema operativo y del navegador
Plataforma principal
| Plataforma | disposición conocida | Alcance que debe comprobarse al utilizar |
|---|---|---|
| Windows y Windows Server | Distribución Microsoft bloqueada mediante actualización automática de la lista de confianza de certificados | Si el dispositivo recibió la actualización; El CA bundle independiente no utiliza necesariamente la ruta de verificación de Windows. |
| Plataforma macOS, iOS, iPadOS, etc. Apple | El coordinador de incidentes confirmó que Apple ha desplegado el bloqueo correspondiente. | No se garantiza que todas las versiones anteriores y aplicaciones de terceros reciban la misma cobertura. |
| Android | Google distribuye bloques equivalentes a través del servicio Google Play | ROM sin servicio Google Play debe verificarse según el anuncio del fabricante; use el verificador incorporado para verificación adicional |
| Ubuntu | Se han proporcionado correcciones del paquete de certificados del sistema, incluidas múltiples ramas de versiones actuales y antiguas. | La versión anterior de ESM admite condiciones, paquete de certificado interno del contenedor y biblioteca integrada de la aplicación. |
| Debian y Devuan | Debian grabado ca-certificates arreglado | Debe verificar la rama real utilizada y el paquete instalado, y no puede copiar el número de versión de otra rama. |
| RHEL y derivados | La lista oficial es RHEL 6, 7, 8, 9, 10 y cubre productos e imágenes relacionados que pueden verse afectados. | A partir de esta verificación, el anuncio aún no incluye una lista completa de correcciones y erratas; “Actualización no encontrada” no puede considerarse no afectada |
| Fedora, Arch, Gentoo, Alpine, etc. | El responsable del evento ha recopilado los registros de reparación correspondientes. | Confirmado de forma independiente por lanzamiento, rama de versión e imagen. |
| FreeBSD | Enumera oficialmente todas las versiones compatibles y proporciona reparaciones en el almacén de confianza del sistema. | Después de la actualización, reinicie el proceso del demonio correspondiente según el anuncio; consulte el almacén de confianza de aplicaciones independiente por separado. |
Para obtener un resumen de Windows, Apple y sus versiones, consulte 4; para Android, consulte 1; para Ubuntu, Debian, RHEL y FreeBSD. Los registros de emisor se muestran en 8–11 respectivamente.
Los sistemas que ya no son compatibles, los dispositivos fuera de línea, NAS, enrutadores y otros entornos integrados deben confirmar si todavía confían en la cadena relevante y si tienen canales para recibir revocaciones o actualizaciones de software. El nombre de la plataforma en sí no sustituye la verificación del comportamiento de verificación real.
La protección del navegador es diferente de la protección del sistema operativo
Chrome utiliza CRLSet para distribuir bloques de emergencia; Firefox utiliza mecanismos como OneCRL. Firefox también se lanzó con información de bloqueo para brindar protección adicional para configuraciones que no reciben correctamente la configuración remota. 13
Algunas configuraciones de Firefox Android no habían aplicado correctamente la lista actualizada al inicio, que Mozilla afirmó que fue reparada por 158.0.2.. Por lo tanto, el estado de las primeras 158.0.1 no se puede ampliar para incluir todas las configuraciones de Android Firefox protegidas. 2
Se han tomado medidas para la verificación del sistema de Apple y Windows, pero eso no significa que todos los programas de línea de comando en la misma máquina se someterán a la verificación del sistema. El responsable del evento recordó específicamente que algunas herramientas integradas macOS utilizan archivos de certificados independientes; El backend TLS real y la fuente CA deben registrarse al realizar la verificación. 4
Límites protectores para la transparencia de los certificados
Google confirmó que antes de implementar el bloque, los seis TLS intermedios CA no emitieron el certificado TLS que ingresó al registro CT. Por lo tanto, los clientes Chrome que aplican CT tienen protección adicional. Este hecho no descarta la posibilidad de que otros clientes que no ejecutan CT hayan aceptado certificados no documentados. 15
“Resulta que se puede vincular a la raíz confiable”, “existen condiciones potenciales de explotación” y “ha ocurrido un ataque” son tres juicios diferentes y no deben reemplazarse entre sí.
5 Entorno de desarrollo y línea base de reparación en tiempo de ejecución
La siguiente es una referencia de correcciones confirmadas y no es un requisito para fijar estas versiones a largo plazo. Las distribuciones pueden corregir números de versiones anteriores retrocediendo parches, y también se deben revisar sus avisos de seguridad.
| componentes | Versión confirmada o método de actualización | Consideraciones de implementación |
|---|---|---|
| Node.js 24 | 24.22.1 o actualizar la versión estable de la misma rama | Contiene actualizaciones del repositorio raíz y rechazo de llaveros públicos bloqueados; verifique la ruta Node realmente utilizada por el servicio y reinicie |
| Python certifi | 2026.10.19 o versión más reciente | Verifique cada entorno de ejecución real; no puede actualizar solo un paquete en Python global |
| pip | 26.2.2 o versión más reciente | Actualice por separado pip en el entorno virtual antiguo y revise la versión después de crear el nuevo entorno. |
| uv | 0.13.4 o versión más reciente | Actualice una copia de la herramienta tal como se instaló realmente |
| Go | 1.27.3 o 1.26.10, también está disponible la versión actualizada de la rama correspondiente | Reconstruya e implemente los programas relevantes después de actualizar la cadena de herramientas u obtenga el binario de reparación del proveedor. |
| Oracle JDK | Parches Critical para las líneas de versión compatibles correspondientes | Diferentes editores de JDK siguen sus propios anuncios; no existe un número de versión único que se aplique a todas las versiones Java |
| Cloudflare Tunnel | cloudflared 2026.10.2 o versión más reciente | Actualizar los servicios en ejecución; La implementación del contenedor requiere reemplazar la imagen y volver a implementarla. |
| Cloudflare One／WARP | La versión fija del cliente correspondiente a la plataforma o la versión estable actualizada | Las medidas del lado del cliente y del lado del servidor se confirman por separado. Para versiones de plataforma específicas, consulte el apéndice 7. |
Las instrucciones originales para Node, Python, Go, Oracle y Cloudflare están disponibles respectivamente en 13, 12, 14, 15, 7.
Problema de base de datos de certificados independientes Python
Los funcionarios de Python señalaron que el antiguo pip utilizará una combinación de confianza del sistema y certifi integrado. Simplemente modificar el almacén de certificados del sistema o agregar un archivo CA a pip no puede excluir de manera confiable su antigua confianza incorporada. Por lo tanto, PIP_CERT, REQUESTS_CA_BUNDLE o --cert no se pueden utilizar como reemplazo de reparación universal para el antiguo pip. 12
Verifique los entornos virtuales existentes después de la actualización. Verifique también la versión pip realmente instalada en entornos recién creados para que los componentes de arranque más antiguos no reintroduzcan herramientas vulnerables. Para la actualización inicial, siga las fuentes de descarga y los pasos de verificación de SHA-256 en el aviso de Python antes de actualizar otros paquetes. 12
Go y otros programas compilados
La solución para Go cambió la lógica de validación para crypto/x509. 14 Desde la perspectiva del mecanismo de implementación, actualizar el compilador en la máquina de desarrollo no reescribirá el binario ya implementado. Para obtener el nuevo bloqueo de la capa de código, se debe reconstruir y reemplazar la aplicación, o se debe usar una versión actualizada proporcionada por el proveedor. Que un programa más antiguo también pueda beneficiarse de las actualizaciones de la raíz del sistema depende de la ruta de verificación real que utilice.
Contenedores y aplicaciones empaquetadas.
El paquete de certificado del sistema, las dependencias de la aplicación y el tiempo de ejecución en el contenedor generalmente están determinados por el contenido de la imagen. La actualización del host no es igual a la actualización del contenido de la imagen; la imagen básica y las dependencias deben actualizarse, y la instancia en ejecución real debe reconstruirse, implementarse y verificarse. Las aplicaciones empaquetadas y los programas de escritorio que vienen con su propio tiempo de ejecución también deben actualizarse según los canales de lanzamiento del proveedor. 710
6 Instrucciones de implementación de reparación
Determine primero el objeto de inspección
Se recomienda registrar la siguiente información para los servicios que deben protegerse y luego seleccionar la ruta de reparación correspondiente. Esta es una lista de verificación de implementación y no requiere que todos los componentes estén presentes en todos los sistemas.
| Proyecto | Lo que hay que registrar |
|---|---|
| Aplicaciones y usos | Navegador, cliente de pago API, servicio de envío de correo electrónico, herramienta de descarga, proxy inverso, etc. |
| posición de operación | Host, contenedor, máquina virtual, aplicación de escritorio o dispositivo móvil |
| Verificar implementación | Validador del sistema operativo, biblioteca OpenSSL, Node, Python, Java o implementación personalizada de la aplicación |
| fuente confiable | Paquete del sistema CA, certifi, almacén de confianza JDK, CA bundle integrado o configuración empresarial |
| Estado de reparación | Versión instalada, fuente del parche, si reiniciar o volver a implementar |
| Resultados de aceptación | Si la cadena afectada es rechazada, si la conexión comercial normal es exitosa y el tiempo de verificación |
La guía para desarrolladores de Cloudflare establece específicamente que SDK puede delegar la verificación a otros componentes; Sólo actualizar el SDK de nivel superior no cambia necesariamente la política de confianza real. 7
Sistemas operativos y navegadores.
Windows: habilita y verifica las actualizaciones automáticas de la lista de confianza de certificados. Distribuir actualizaciones a través de políticas de gestión establecidas. Los dispositivos sin conexión o con actualizaciones automáticas deshabilitadas necesitan que el bloqueo se aplique a través de un proceso de gestión adecuado. Verifique los programas que no utilizan la validación del sistema Windows por separado. 4
Apple Plataforma: Actualizaciones completas del sistema, componentes de seguridad y aplicaciones. Para conocer las herramientas de desarrollo en macOS, consulte también su backend TLS, los archivos de certificado y las fuentes de instalación. No se puede juzgar que toda la máquina ha sido reparada solo porque Safari rechazó la cadena de prueba. 4
Android: actualiza los servicios Google Play en los dispositivos que lo tienen. Google afirma que reiniciar un dispositivo puede desencadenar una actualización inmediata. Para dispositivos sin esos servicios, siga el aviso del proveedor o ROM; La declaración de cobertura de Google no se aplica automáticamente a todos los dispositivos Android. 1
Ubuntu/Debian: actualice los paquetes de certificados de los repositorios compatibles y consulte el aviso de la distribución instalada. Por ejemplo, un sistema basado en APT puede utilizar:
sudo apt update
sudo apt install --only-upgrade ca-certificates
dpkg-query -W -f='${Package} ${Version}\n' ca-certificatesLas actualizaciones relevantes para Ubuntu 22.04, 24.04, 26.04 y 26.10 son soporte estándar; Las versiones anteriores deben verificar el soporte y el estado del almacén de ESM. Una vez que el mandato finalice correctamente, aún deberá comparar la versión del fixpack en el boletín. 89
RHEL y productos relacionados: Verifique el paquete de certificados y las erratas de seguridad por canal de producto. La verificación de versiones se puede realizar usando:
rpm -q ca-certificatesUtilice el mecanismo de actualización compatible DNF/YUM para obtener parches del proveedor; Si el canal aún no ha proporcionado una solución, no considere seguro “sin paquete actualizable”. Cuando sea necesario eliminar temporalmente la confianza raíz, adopte medidas claramente enumeradas por el fabricante y evalúe la compatibilidad de los certificados comerciales legítimos. 10
FreeBSD: actualice la rama relevante del sistema según lo indicado en el aviso oficial, luego reinicie los demonios usando la configuración de confianza OpenSSL afectada o reinicie el sistema. 11
Aplicaciones e imágenes
Después de completar las actualizaciones de dependencia de certificados y tiempo de ejecución correspondientes, verifique la ruta del archivo ejecutable donde realmente se está ejecutando el servicio para evitar que el terminal haya cambiado a una nueva versión y el demonio todavía use el directorio de instalación anterior. Para Python de múltiples entornos, los contenedores de servicios y las aplicaciones que vienen con su propio tiempo de ejecución, deben verificarse por separado.
Para los componentes que deben reconstruirse, guarde la versión de compilación, la versión de dependencia y el ID de la imagen de implementación. El objeto de aceptación es la instancia en ejecución real y no puede simplemente verificar la nueva etiqueta en la máquina de compilación o en el registro de imágenes. 71214
Migración de certificado de sitio web
Si la cadena de un sitio web contiene un CA intermedio revocado o bloqueado, o en última instancia depende de una raíz que no es de confianza, obtenga otra cadena que los clientes aún acepten. Instale la cadena de certificados del servidor completa y verifique cada ingreso, incluidos los balanceadores de carga, los servidores proxy inversos, los puntos finales CDN y los orígenes directamente accesibles. 15
Si se requiere migración se basa en la cadena real. Filtrar solo por marca de venta de certificados puede omitir relaciones de reventa o de firma cruzada; Es posible que simplemente esperar la renovación de vencimiento regular no necesariamente complete la migración antes de que se actualice el almacén raíz.
Para otros certificados de sitios web normales emitidos por CA que no dependen de la raíz afectada, no es necesario volver a firmarlos debido a este incidente. Al mismo tiempo, el servidor del sitio web debería seguir realizando comprobaciones de reparación del lado del cliente al llamar a servicios externos.
7 Verifique que la solución realmente surta efecto
La verificación de versión y la verificación de comportamiento se realizan por separado
Las comprobaciones de versión se utilizan para confirmar que se han implementado parches o componentes reparados; Las comprobaciones de comportamiento se utilizan para confirmar que la aplicación realmente utiliza la ruta de verificación esperada. Las dos comprobaciones resuelven problemas diferentes y ninguna de ellas puede ser reemplazada por “El comando de actualización se ejecutó correctamente”.
El responsable del evento proporciona materiales para el sitio de prueba y la cadena de certificados, y la entrada se concentra en el apéndice 4. Debe verificarse en el entorno operativo real de la aplicación de destino, manteniendo la configuración normal de verificación de certificados. 47
| Comprobar resultados | Conclusiones que se pueden sacar |
|---|---|
| Rechazar explícitamente porque no se confía en la cadena afectada | Indica que la ruta de verificación que se está probando rechazó la cadena |
| Aceptar la cadena afectada normalmente | Indica que es necesario continuar reparando esta ruta o verificar la configuración. |
| Error DNS, tiempo de espera de conexión, rechazo de proxy o servicio inalcanzable | Sobre esta base no se puede concluir que se haya eliminado el riesgo del certificado. |
| El navegador rechaza, pero la llamada a la aplicación no está marcada | Sólo puede confirmar el navegador, no el programa en segundo plano. |
| La cadena A fue rechazada | Aún es necesario considerar si el cliente acepta otra ruta de firma cruzada. |
La prueba también debe cubrir las conexiones comerciales normales para evitar confundir todas las solicitudes fallidas con reparaciones exitosas después de que las fallas comerciales se deban a la eliminación de demasiada confianza.
Condiciones de finalización sugeridas
- La fuente de actualización y la versión de los componentes afectados están documentados.
- La instancia en ejecución correspondiente se ha reiniciado, reconstruido o implementado de nuevo.
- La aplicación real rechaza la cadena afectada y la verificación TLS para negocios normales continúa funcionando.
- No existe ninguna configuración para desactivar temporalmente la verificación del certificado para restaurar la conexión.
- Si se trata de una migración de certificados del sitio web, todas las entradas externas se han cambiado y verificado.
Las condiciones de finalización anteriores son sugerencias para la aceptación de operación y mantenimiento de esta eliminación; no equivale a demostrar que el equipo no tiene otros problemas de seguridad.
8 Límites históricos de tráfico y riesgo HTTPS
Tres tipos de claves tienen diferentes usos
| clave | Propósito principal |
|---|---|
| Clave privada CA | Firmar el enlace de identidad y clave pública en el certificado. |
| Clave privada del sitio web | Demuestre la identidad del servidor en el protocolo de enlace TLS autenticado con el certificado |
| clave de sesión | Proteger los datos realmente transmitidos en una conexión. |
Obtener la clave privada CA no equivale a obtener la clave privada del sitio web ni todas las claves de sesión. A La conexión normal con secreto directo mediante el intercambio de claves temporal no expondrá automáticamente las sesiones históricas simplemente porque la clave de firma a largo plazo se ve comprometida más adelante. Para conocer los atributos de seguridad relevantes de TLS 1.3, consulte RFC 8446. 16
El principal riesgo esta vez se produce durante la fase de autenticación: si el cliente acepta el certificado del servidor falso, puede establecer una conexión con el atacante que aún está cifrada. TLS 1.3 también requiere autenticación confiable; simplemente actualizar la versión del protocolo no sustituye el bloqueo de CA.
Juicios que se pueden y no se pueden hacer en la actualidad
Confirmado: las claves privadas intermedias específicas CA están comprometidas; las vías de confianza pública afectadas tienen un amplio alcance; Las principales plataformas y varios ecosistemas de software han tomado medidas. 145
No se establece en este incidente: que todos los usuarios han experimentado ataques de intermediario, que otras claves privadas de CA están comprometidas, que todo el tráfico histórico de HTTPS se puede descifrar o que la actualización de un navegador protege todas las aplicaciones del dispositivo.
El juicio final sobre un servicio específico debe basarse en su cadena de certificados, política de verificación, componentes en ejecución reales y estado de actualización, no solo en si la barra de direcciones dice HTTPS.
Apéndice A Nombre intermedio afectado CA
Los siguientes nombres ayudan en la verificación de activos. Los nombres no reemplazan las huellas digitales de los certificados ni los identificadores de clave pública. La comparación automatizada debe utilizar los identificadores exactos publicados por los responsables o proveedores del incidente, incluidos los certificados con firma cruzada. 5
| Medio CA | Propósito | Organizaciones asociadas |
|---|---|---|
| EM EV TLS CA - G3B | TLS | eMudhra BV |
| EM OV TLS CA - G3B | TLS | eMudhra BV |
| EM DV TLS CA - G3B | TLS | eMudhra BV |
| EM EV TLS CA - G3C | TLS | eMudhra Inc |
| EM OV TLS CA - G3C | TLS | eMudhra Inc |
| EM DV TLS CA - G3C | TLS | eMudhra Inc |
| EM OV CS CA - G3B | firma de código | eMudhra BV |
| EM OV CS CA - G3C | firma de código | eMudhra Inc |
TLS no es exactamente el mismo mecanismo de validación y revocación que la firma de código. El tema central de este artículo es HTTPS/TLS; el entorno de firma de código debe adoptar Microsoft, JDK o proveedores de software relacionados para este propósito de verificación, y los resultados de las pruebas del navegador no deben considerarse como aceptación de la firma de código. 515
Apéndice B Enlace de referencia
Las siguientes fuentes fueron verificadas el 22 de octubre de 2026. El anuncio continuo puede continuar actualizándose y el estado y la versión del texto deben entenderse según la fecha de este documento.
Hechos del incidente y manejo de la plataforma.
Anuncio oficial de [1] Google Chrome y Android Describe fallas de clave privada, bloqueo de SPKI, distribución de servicios de Google Play, protección de CT y planes de eliminación del repositorio raíz de Chrome. Protecting Chrome and Android Users from Compromised eMudhra Intermediate CA Certificates
[2] Mozilla Bugzilla 2083449 Registro de eventos Contiene informes originales, verificación independiente, investigación del proceso de generación, correcciones posteriores para Firefox Android y discusiones sobre migración de certificados legales; céntrese en los comentarios 5, 11, 29 y 30. eMudhra Private key compromise of Intermediate Certificates
[3] Mozilla Firefox Aviso de seguridad Descripción de la distribución de emergencia de OneCRL y posterior eliminación de Firefox/NSS. Protecting Firefox users following the compromise of eMudhra intermediate certificates
[4] Coordinador de eventos Dennis Jackson Portal de detección y resumen de mantenimiento Proporciona instrucciones complementarias sobre el estado de reparación de la plataforma y el software, el ingreso a la prueba, los materiales de la cadena de certificados públicos y entornos como Windows/macOS. Los resultados de las pruebas solo representan las rutas de verificación reales probadas. eMudhra Intermediate CA Compromise
[5] Mozilla Aviso a los mantenedores de distribución y almacén de confianza Describe 6 TLS y 2 intermediarios de firma de código CA, Sectigo límites de procesamiento de confianza raíz, revocación y firma cruzada, y enumera el certificado exacto y la identificación de clave pública. oss-security eMudhra Intermediates Compromise
[6] eMudhra Declaración oficial del evento Proporcionar la explicación preliminar del fabricante sobre el proceso de generación de claves; la causa raíz exacta seguirá estando sujeta a la conclusión de la investigación completa. eMudhra Statement on Recent Certificate Security Incident
[7] Cloudflare Instrucciones oficiales de incidencia y reparación Cubre WARP, Cloudflare Tunnel, verificación del sitio de origen, dependencias de tiempo de ejecución, actualizaciones de imágenes y métodos de verificación. 8 eMudhra certificates are compromised Here is what you need to know
Sistemas operativos y distribuciones.
[8] Ubuntu Anuncio oficial de reparación Enumera los paquetes de arreglos ca-certificates, los canales de soporte y los pasos de actualización específicos para cada versión. eMudhra CA compromise fixes available
[9] Debian Registro oficial de problemas y reparaciones El registro de arreglos del mantenedor y el paquete de lanzamiento correspondiente deben tomarse como estándar, y las sugerencias temporales tempranas en la discusión del problema no deben considerarse como la solución final. Debian bug 1151413 eMudhra Intermediate CA key compromise
[10] Red Hat Boletín Oficial de Seguridad RHSB 2026 012 Enumera RHEL 6 a 10, los impactos de productos y contenedores asociados, y corrige las entradas de liberación y eliminación provisional. Certificate compromise eMudhra
[11] FreeBSD Boletín Oficial de Seguridad Proporcione ramas del sistema afectadas, versiones de reparación y requisitos de reinicio del servicio. FreeBSD SA 26 73 caroot
Tiempo de ejecución y protocolos
[12] Python Descripción oficial del evento Proporciona líneas de base de reparación para pip, certifi, uv, etc., explica el problema del antiguo almacén de confianza independiente pip y proporciona el método de actualización inicial con verificación SHA-256. Information for Python users regarding eMudhra emSign CA certificate security incident
[13] Node.js 24.22.1 Lanzamiento oficial Contiene actualizaciones del almacén raíz NSS y rechaza cambios que contienen cadenas de certificados de clave pública bloqueadas. Node.js 24.22.1 security release
[14] Go Comunicado de seguridad oficial Descripción Actualización de filtrado de cadena de certificados crypto/x509 para Go 1.27.3/1.26.10. Go 1.27.3 and Go 1.26.10 are released
[15] Oracle JDK Instrucciones oficiales de eliminación Explique el parche crítico JDK y las medidas de configuración relacionadas cuando no se pueda actualizar de inmediato. Distrusting eMudhra Intermediate Certificates in Oracle JDK
[16] TLS 1.3 Protocolo estándar RFC 8446 Consulte el apéndice E.1 para obtener instrucciones sobre autenticación de identidad, intercambio de claves temporales y secreto de reenvío. The Transport Layer Security Protocol Version 1.3
[17] Certificado raíz relacionado con eventos y datos de relación de emisión Se utiliza para comprender la relación de emisor directo y de firma cruzada; el estado de inclusión del almacén raíz no puede reemplazar el último estado de revocación o bloqueo del cliente. Root certificate relationships JSON