AWS retira raíces eMudhra de sus trust bundles TLS y fija plazos

AWS publicó el boletín 2026-150-AWS tras recuperar investigadores ocho claves privadas de autoridades intermedias de eMudhra generadas con entropía insuficiente. La respuesta de AWS afecta a sus almacenes de confianza TLS salientes: los servicios que los usan validan conexiones iniciadas desde AWS hacia endpoints configurados por clientes, como proveedores de identidad, servidores de origen y webhooks. El cambio consiste en retirar raíces que permiten encadenar certificados a las intermedias afectadas; no significa que se hayan comprometido las claves privadas de esas raíces.

Dónde cambia la validación

El aviso atribuye el problema a una generación criptográfica deficiente en ocho claves de autoridades subordinadas: seis para TLS y dos para firma de código. Con esas claves era posible reconstruir material privado y emitir certificados falsos que encadenaran a una jerarquía confiable. La unidad afectada es la cadena de certificados, no una región de AWS ni una cuenta concreta: una conexión puede dejar de validar si su endpoint presenta una cadena que depende de una raíz retirada.

Google informó por separado de que no encontró certificados TLS encadenados a las seis intermedias en registros de Certificate Transparency (CT) antes de que Chrome las bloqueara. Eso reduce la evidencia de emisión visible para clientes que exigen CT, pero no prueba que ningún certificado se haya utilizado en ningún entorno. AWS, por su parte, identifica sus cambios y servicios; el boletín no atribuye a la retirada una campaña de explotación observada.

-InfraCrew dice: “El navegador sigue abriendo la web” no comprueba la cadena que valida una llamada saliente desde un servicio gestionado.-

AWS indica que los cambios del trust store compartido se integraron y desplegaron el 21 de octubre. También publicó actualizaciones de boto3 y botocore —la versión de botocore debe ser 1.43.117 o posterior—, parches para ca-certificates en Amazon Linux y nuevas versiones de Corretto. Bottlerocket recibe AMI actualizadas; el objetivo es que los parámetros comerciales estén actualizados antes del 28 de octubre. Son rutas distintas: actualizar un SDK no actualiza la AMI de los nodos ni reemplaza un certificado propio.

Los plazos que afectan al servicio

Hay fechas futuras que conviene separar de lo ya desplegado. CloudFront apunta al 28 de octubre para retirar las raíces de su bundle de borde; los orígenes cuyo certificado dependa de ellas pueden empezar a fallar en la validación TLS. Los Application Load Balancers con autenticación OIDC o JWT se actualizarán entre el 29 y el 31, y los ALB nuevos quedarán protegidos el 2 de noviembre. AWS pide reemplazar antes del 28 el certificado del proveedor de identidad que encadene a una raíz afectada.

STS y Cognito ya completaron la retirada para sus conexiones TLS salientes a endpoints de identidad. En RDS para SQL Server, AWS prevé actualizar hosts gestionados el 30 de octubre y señala que no hace falta una acción del cliente; EMR tiene versiones previstas para el día 31. La fecha y la propiedad del cambio importan: un servicio puede requerir actualización del cliente, aceptar mantenimiento gestionado o depender de un certificado que debe sustituir el propio cliente.

-InfraCrew dice: Una fecha de “despliegue objetivo” sirve para organizar una guardia; no equivale a una validación hecha en todas tus cuentas.-

Qué revisar sin romper otra cadena

Empieza por los puntos donde una carga de trabajo de AWS valida TLS hacia un endpoint que administra la organización: orígenes de CloudFront, IdP usados por ALB con OIDC/JWT, destinos de webhooks y clientes que consumen servicios externos desde Amazon Linux, Corretto o el SDK de Python. Compara el certificado realmente presentado y su cadena completa con el almacén que usa el servicio; una comprobación desde el portátil no representa necesariamente el trust store de un servicio administrado.

Si la cadena usa una raíz retirada, solicita e instala un certificado emitido por una autoridad que siga siendo confiable para ese servicio antes de su fecha de cambio. Para componentes administrados por AWS, sigue la fecha y la notificación de AWS Health correspondiente. Después de actualizar librerías o imágenes, confirma que el proceso nuevo las cargó y que la conexión TLS se establece. No elimines certificados de un almacén propio por semejanza de nombre: la intervención debe apuntar a la cadena afectada y al componente que valida.

-InfraCrew dice: La lista de raíces es una dependencia de producción con menos visibilidad que el balanceador; hasta que una renovación la convierte en protagonista.-

Diccionario de la Crew

Autoridad intermedia — CA subordinada que puede emitir certificados bajo una autoridad raíz.
Trust store — Almacén de certificados raíz que un cliente usa para decidir qué cadenas TLS acepta.
Certificate Transparency (CT) — Registros públicos que permiten detectar certificados TLS emitidos para nombres de dominio.