Apple bloquea los certificados de eMudhra: qué hacer en Mac

Apple bloquea los certificados de eMudhra: qué cambia en tu Mac

Doce certificados. Ese es el número exacto que Apple empezó a bloquear desde el 19 de octubre de 2026 en todos sus dispositivos, y la cifra importa porque cada uno de ellos podía usarse para falsificar la identidad de cualquier sitio web. Si tu equipo de desarrollo trabaja sobre Mac, hay una parte de la historia que sí te toca: las herramientas de línea de comandos que usas a diario no revisan ese bloqueo por defecto.

El problema no nació en Apple. Nació en eMudhra, una autoridad certificadora india cuyos certificados intermedios resultaron tener claves privadas tan débiles que cualquiera podía reconstruirlas. Apple reaccionó rápido y de forma automática. El hueco está en los rincones del sistema donde la verificación de certificados no pasa por los frameworks de seguridad de Apple.

Qué pasó exactamente con los certificados de eMudhra

Según el documento de soporte de Apple, las claves privadas de ocho autoridades certificadoras intermedias operadas por eMudhra quedaron comprometidas. Dos de esas CAs emiten certificados de firma de código, que los frameworks de Apple no confían. Las otras seis emiten certificados TLS, y quien tuviera sus claves podía crear certificados que parecieran válidos para cualquier sitio web.

¿Y esto cómo se aplica en tu negocio?

Dueños de negocio de Latinoamérica y España usan un agente de IA para ganar más y recuperar su tiempo. El Kit «tu mano derecha con IA» te muestra cómo en un video de 11 minutos, con una ficha para armar el tuyo. CAR está cerrada por ahora; al anotarte, te avisamos cuando abra.

👥 Quiero el Kit →

Cada una de esas seis CAs TLS tiene dos certificados, para un total de doce:

Un certificado emitido por emSign Root TLS CA - G3, que encadena a emSign ECC Root CA - G3.
Un certificado firmado de forma cruzada por Sectigo, que encadena a AAA Certificate Services.

Tanto eMudhra como Sectigo revocaron los certificados afectados. El 23 de octubre de 2026, Apple también empezó a bloquear la raíz emSign ECC Root CA - G3.

Por qué las claves eran tan fáciles de romper

Aquí está el dato que convierte este incidente en algo más que una nota de seguridad. InfoQ reportó que las claves privadas no fueron robadas: se generaron con un mecanismo inseguro. En lugar de ser números aleatorios grandes, eran todos cero excepto el último byte, que tomaba valores como 4, 56, 66, 115, 155, 156, 230 o 237.

Ars Technica puso la magnitud en perspectiva: las claves de curva elíptica NIST P-384 deberían contener unos 384 bits de entropía, pero las ocho comprometidas tenían entre 3 y 8 bits. La más fuerte de las claves defectuosas tenía un máximo de 256 posibilidades. El investigador conocido como Wayne descubrió la debilidad el 17 de octubre mientras escaneaba datos públicos de certificados, según BleepingComputer.

The Hacker News recogió la explicación de la compañía: un fallo en la ceremonia de generación de claves del 30 de abril de 2025 produjo un segundo juego de claves débiles junto a las correctas, y ese juego débil fue el que terminó publicado en los almacenes de confianza de los navegadores. eMudhra sostiene que su infraestructura no fue vulnerada y que no hay evidencia de uso malicioso.

El golpe reputacional fue inmediato. Ars Technica informó que eMudhra anunció su salida del negocio global de SSL/TLS, que representaba alrededor del 1% de sus ingresos, y The Hacker News citó a Business Standard para señalar que sus acciones cayeron un 20% en Mumbai el 21 de octubre. El Ministerio de Electrónica y Tecnología de la India abrió una investigación, según reportó ThePrint.

Qué está haciendo Apple y dónde queda el hueco

Apple bloquea los certificados de forma automática. Las actualizaciones de configuración de certificados se envían a los dispositivos sin necesidad de instalar una actualización de software, y lo mismo aplica a los bloqueos adicionales. Si no usas Terminal en tu flujo de trabajo, no tienes nada que hacer: Safari, Mail y las apps que usan los frameworks de red y seguridad de Apple ya los bloquean.

El problema aparece si eres administrador de sistemas o desarrollador. Algunas herramientas incluidas con macOS o con las Xcode Command Line Tools —como curl y git— verifican los certificados contra el archivo /etc/ssl/cert.pem y pueden seguir aceptando estos certificados hasta una futura actualización de software. Ese archivo no consulta el bloqueo de Apple ni el estado de revocación.

Apple ofrece un procedimiento opcional para adelantarse: hacer una copia de seguridad del archivo y eliminar de él los certificados raíz a los que encadenan los certificados bloqueados. La compañía advierte que esos pasos afectan a todas las herramientas que usan /etc/ssl/cert.pem y que, después, algunas herramientas podrían no poder verificar sitios legítimos cuyos certificados encadenan a esas raíces a través de CAs intermedias no afectadas. También aclara que una actualización de macOS puede reemplazar el archivo, así que el procedimiento debe repetirse tras cada actualización hasta instalar la versión que incluya los cambios de Apple.

¿Tienes que editar /etc/ssl/cert.pem?

La respuesta corta de Apple es que la mayoría de los usuarios no necesita hacerlo. La respuesta útil para un equipo técnico es que depende de qué tan expuesto esté tu stack.

BleepingComputer advirtió que la utilidad /usr/bin/curl integrada en macOS puede seguir confiando en los certificados comprometidos porque su paquete de certificados no revisa información de revocación. The Hacker News documentó el mismo punto y agregó que las distribuciones y los lenguajes fueron parcheando a distinta velocidad: Go (1.27.3 y 1.26.10, CVE-2026-111943), Node.js, Python certifi, rustls-webpki, Electron, pip, uv y los paquetes ca-certificates de Ubuntu, Debian, Arch, Gentoo y Alpine, entre otros.

Hay un ángulo que suele pasarse por alto. InfoQ citó a Andrew Ayer, fundador de SSLMate, con una advertencia directa: quienes usan CAs de WebPKI para mTLS o autenticación de cliente TLS son los que deberían estar más preocupados, porque un atacante puede acuñar un certificado y autenticarse contra el endpoint sin necesidad de un secuestro de BGP ni de otro ataque de red.

Qué significa esto para tu startup

Este incidente no es una curiosidad de infraestructura: es un recordatorio de que la confianza en internet se apoya en cientos de CAs y miles de intermediarios, y que basta una ceremonia de claves mal ejecutada para que toda esa cadena se vuelva frágil. Para un equipo pequeño, la lección práctica es que la seguridad de la cadena de certificados no se resuelve sola.

Dos acciones concretas que puedes ejecutar esta semana:

Inventaría dónde viven tus certificados raíz. No es solo tu Mac. Son tus imágenes Docker, tus runners de CI/CD, tus contenedores en producción y cualquier binario que empaquete su propio cacerts. The Hacker News señaló que Cloudflare liberó clientes WARP y 1.1.1.1 corregidos y advirtió que quienes corren sus propios servidores de origen, mTLS o contenedores deben actualizar sus almacenes de confianza por su cuenta. Reconstruye las imágenes base en lugar de parchear en caliente.
Revisa si dependes de mTLS con CAs de WebPKI. Si tu arquitectura autentica servicios con certificados de cliente emitidos por una CA pública, ese diseño hereda el riesgo de cualquier compromiso de esa CA. Evalúa mover la autenticación interna a una CA propia o a un mecanismo que no dependa del ecosistema de confianza público.

Y una tercera, más de fondo: no esperes a que la actualización llegue sola. Si tu equipo usa curl, git, python3, ruby, perl u openssl desde Terminal para tareas de despliegue o scripts de integración, vale la pena validar hoy si esos flujos siguen aceptando las cadenas comprometidas. Apple publica en su documento los comandos exactos para verificar el resultado y restaurar la copia de seguridad si algo sale mal.

La buena noticia es que el ecosistema reaccionó en horas, no en semanas: Mozilla bloqueó los certificados vía OneCRL el mismo 17 de octubre, menos de tres horas después de recibir el reporte, según su propio blog de seguridad. La mala es que los sistemas que no se parchean activamente —incluido todo lo que ya pasó su fin de vida— seguirán confiando en esas claves.