Qué ocurrió, con fechas
El 17 de octubre de 2026, un investigador informó a los programas raíz de que ocho autoridades intermedias de eMudhra se habían creado con claves mal generadas. Firefox y Chrome bloquearon esos certificados el mismo día. El 20 de octubre de 2026, Microsoft empezó a bloquearlos y el paquete de curl pasó a su versión del 20 de octubre. El 22 de octubre de 2026, Apple siguió para las aplicaciones que usan sus frameworks de red.
El 20 de octubre de 2026, Debian publicó además el aviso DSA-6572-1: el paquete ca-certificates en versión 20250419+deb13u1, para Debian stable (trixie), retira los certificados llamados «emSign ECC Root CA - G3» y «Comodo AAA Services root». Dos precisiones importan después. El aviso habla de intermedias de eMudhra comprometidas, pero los dos certificados que nombra llevan nombres de raíces. Y solo indica una versión corregida para trixie: para otras distribuciones, lea el aviso de esa distribución en lugar de suponer.
Por qué «los navegadores ya bloquearon» no cierra el caso
Es la objeción más habitual, y es medio cierta. Según la página de referencia del investigador, los navegadores que exigen Certificate Transparency no podían ser atacados con estas intermedias. Pero un servidor que llama a una API, un script de despliegue que clona un repositorio, una tarea programada que descarga un archivo o un contenedor que instala una dependencia no son navegadores. Estos clientes comprueban la cadena contra un archivo, y por lo general no comprueban ni la transparencia ni la revocación. El 28 de octubre de 2026, la página de referencia del investigador señalaba, por ejemplo, que las herramientas de línea de comandos de Apple (git, curl, python3) seguían confiando en estos certificados.
Segunda objeción: ¿quién es responsable? La agencia mantiene la relación con el cliente. La infraestructura se controla servidor por servidor, y nadie más lo hará por usted.
Dónde vive un almacén de confianza en una máquina
- El paquete del sistema —
ca-certificatesen Debian, Ubuntu y Alpine, con el mismo nombre en RHEL y derivadas. Es la referencia de todo lo que lee/etc/ssl/certs. - El paquete de curl — según la compilación, curl lee el almacén del sistema o un archivo aparte.
curl-config --caindica cuál. - Python y certifi — el módulo
certifiincluye su propio paquete, y pip lo usa. Una actualización del sistema no lo toca. - Node.js — el binario incorpora una lista de autoridades.
NODE_EXTRA_CA_CERTSañade algunas, no retira ninguna. - Java — el archivo
cacertsdel JDK es un almacén independiente del resto. La corrección de OpenJDK seguía pendiente en la página de referencia, y nada garantiza que su distribución traslade la actualización del paquete del sistema a este archivo. - Cada imagen de contenedor — tiene su propio
/etc/ssl/certs, congelado en el momento de la construcción. La corrección del anfitrión no le llega.
Requisitos cifrados de la auditoría
Cuente con acceso root o sudo en cada máquina, unos 15 minutos para la primera pasada de un servidor y luego 5 minutos de rutina cuando ya domine los comandos. Hay cinco lugares que inspeccionar por máquina (paquete del sistema, curl, certifi, Node, Java) y uno más por imagen de contenedor. Tenga a mano al menos dos anfitriones de prueba cuya cadena conozca, por ejemplo www.your-domain.com y una API que llamen sus aplicaciones. Para los servicios Java, prevea además una ventana de reinicio: un almacén reemplazado solo se vuelve a leer al arrancar la JVM.
El procedimiento, servidor por servidor
Leer la versión del paquete
dpkg -l ca-certificatesen Debian y Ubuntu,rpm -q ca-certificatesen RHEL y derivadas,apk info -v ca-certificatesen Alpine. En Debian stable (trixie), la versión corregida del aviso DSA-6572-1 es 20250419+deb13u1: si la suya es anterior, pase al paso siguiente.Actualizar el almacén
En Debian y Ubuntu:
apt updatey luegoapt install --only-upgrade ca-certificates, y despuésupdate-ca-certificates. En RHEL y derivadas:dnf upgrade ca-certificatesy luegoupdate-ca-trust. En Alpine:apk upgrade ca-certificates.Comprobar que los certificados retirados han desaparecido
ls /usr/share/ca-certificates/mozilla | grep -i -E 'emSign_ECC_Root_CA_-_G3|Comodo_AAA'ls /etc/ssl/certs | grep -i -E 'emSign_ECC_Root_CA_-_G3|Comodo_AAA'
Tras una actualización que retira los dos certificados nombrados por Debian, no debe salir ninguna línea. El patrón apunta solo a los dos certificados nombrados por el aviso de Debian, porque otras raíces emSign o Comodo válidas siguen presentes de forma legítima. Una línea indica un almacén que se quedó en la versión antigua, o un directorio alimentado a mano. Verifique los nombres de archivo reales en una máquina actualizada.Probar una cadena desde el servidor
openssl s_client -connect www.your-domain.com:443 -showcertsmuestra cada certificado enviado y termina con la líneaVerify return code. El código 0 significa que el almacén local acepta la cadena. Complételo concurl -v https://www.your-domain.comy lea la líneaSSL certificate verify ok.Inventariar los paquetes fuera del almacén del sistema
curl-config --cada la ruta del paquete de curl.python3 -c "import certifi; print(certifi.where())"da la de Python.echo $NODE_EXTRA_CA_CERTSmuestra las posibles incorporaciones de Node.readlink -f $(which java)lleva hasta el JDK, cuyolib/security/cacertses el almacén.Actualizar certifi
pip show certifida la versión instalada,python3 -m pip install --upgrade certifila actualiza. La página de referencia del investigador incluye certifi 2026.10.19 entre las versiones corregidas. Repita en cada entorno virtual, porque cada uno tiene su copia.Controlar el almacén de Java
keytool -list -keystore $JAVA_HOME/lib/security/cacerts -storepass changeit | grep -i -E 'emsign ecc|aaa'busca las entradas afectadas; los alias varían según el JDK, así que compare con la lista de la página de referencia. La corrección de OpenJDK seguía pendiente en la fecha de esa página: si hay una entrada afectada, anote la máquina como «a la espera del proveedor» y no como «corregida».Registrar el resultado en su auditoría mensual
Una línea por servidor: fecha, versión de ca-certificates, rutas de los paquetes, resultado de la prueba de cadena. Este registro es lo que enseña al cliente cuando pregunta qué se verificó, y encaja en la lista de auditoría mensual de los VPS de sus clientes.
Dónde buscar, componente por componente
Desplace la tabla
| Componente | Dónde vive la lista de confianza | Comando de control |
|---|---|---|
| Sistema Debian, Ubuntu | Paquete ca-certificates, directorio /etc/ssl/certs | `dpkg -l ca-certificates` |
| Sistema RHEL y derivadas | Paquete ca-certificates, almacén gestionado por update-ca-trust | `rpm -q ca-certificates` |
| curl | Almacén del sistema o paquete de compilación | `curl-config --ca` |
| Python, pip | Módulo certifi, independiente del sistema | `python3 -c "import certifi; print(certifi.where())"` |
| Node.js | Lista integrada en el binario, más NODE_EXTRA_CA_CERTS | `echo $NODE_EXTRA_CA_CERTS` |
| Java | Archivo cacerts del JDK | `keytool -list -keystore $JAVA_HOME/lib/security/cacerts -storepass changeit` |
| Contenedor Docker | /etc/ssl/certs propio de cada imagen | `docker run --rm IMAGE ls /etc/ssl/certs` |
Los contenedores: la corrección del anfitrión no pasa
Un contenedor no hereda el almacén de su anfitrión. Lleva el de su imagen base, congelado el día de la construcción. Actualizar ca-certificates en el servidor no cambia, por tanto, nada para sus contenedores. Para inspeccionar una imagen, ejecute docker run --rm IMAGE ls /etc/ssl/certs, o docker run --rm IMAGE dpkg -l ca-certificates si la imagen se basa en Debian o Ubuntu.
El remedio es reconstruir: docker build --pull --no-cache -t mi-aplicacion:2026-10 . descarga la última imagen base y rehace la capa de certificados. Sin --pull, Docker reutiliza la base en caché, y reconstruye el mismo defecto. Después vuelva a desplegar y repita la comprobación en el contenedor en marcha. Piense en las imágenes de terceros (base de datos, proxy, herramienta de supervisión) que usted no construye: su editor debe publicar una versión nueva, y hay que verificarlo.
Si un certificado de cliente encadena con estas autoridades
Hay dos casos, y conviene separarlos. El primero: un certificado emitido para su cliente, o para usted, fue firmado por una de las intermedias afectadas. Lea el emisor con openssl x509 -in certificat.pem -noout -subject -issuer -dates, y luego la cadena servida con openssl s_client -connect www.your-domain.com:443 -showcerts. La página de referencia publica la lista de intermedias afectadas (archivo impacted-intermediates.json): compárela con lo que lee. Si el emisor figura en ella, pida a la autoridad emisora una reemisión bajo otra cadena, sin esperar a la caducidad.
El segundo caso: un socio se conecta a su sistema con un certificado de cliente (mTLS) y su servidor lo acepta porque su almacén contiene una autoridad afectada. Tras la actualización, ese socio puede ser rechazado, que es el comportamiento buscado pero debe anunciarse. Avíselo antes, liste los certificados de cliente activos y conserve un registro de la fecha de sustitución.
Pruebe antes y después, con anfitriones reales
Retirar una raíz puede romper cadenas legítimas que dependen de ella. Antes de la actualización, ejecute curl -sS -o /dev/null -w '%{http_code}\n' https://www.your-domain.com contra tres o cuatro anfitriones que sus aplicaciones llaman de verdad, y repita el mismo comando después. Un código distinto o un error de verificación se resuelve enseguida, en un servidor, y no en producción un lunes por la mañana.
Resolución de problemas: los errores que verá
Tras la actualización vuelven cuatro mensajes. curl: (60) SSL certificate problem: unable to get local issuer certificate: el servidor remoto envía una cadena incompleta, o su cadena pasaba por un certificado ahora retirado. Pruebe con openssl s_client -showcerts y pida al responsable del servicio que corrija su cadena.
ssl.SSLCertVerificationError: CERTIFICATE_VERIFY_FAILED en Python: el intérprete usa el almacén de certifi o el del sistema, según la aplicación. Lea la ruta con certifi.where() y actualice el componente correcto.
PKIX path building failed: unable to find valid certification path to requested target en Java: el archivo cacerts no contiene la autoridad esperada o fue reemplazado. Verifique con keytool y reinicie la JVM.
Verify return code: 20 (unable to get local issuer certificate) en openssl s_client: la autoridad ya no está en /etc/ssl/certs. Si el sitio es legítimo, es una señal que debe tratarse en el servidor remoto, no eludirse desactivando la verificación.
Lo que sigue pendiente y quién carga con qué
En la fecha de la página de referencia, actualizada el 28 de octubre de 2026, la biblioteca NSS estaba corregida en la versión 3.131.1 y el paquete de curl lo estaba desde el 20 de octubre de 2026, pero la corrección de OpenJDK seguía pendiente, y las herramientas de línea de comandos de Apple seguían confiando en los certificados. Relea esa página antes de decirle a un cliente que todo está corregido: el estado cambia, y su informe debe indicar la fecha de la verificación.
Para una agencia, el reparto es simple. Usted mantiene la relación con el cliente y el informe que prueba lo verificado. El control en sí se hace máquina por máquina. Si gestiona sus propios servidores, el informe es el mismo sin el cliente: una línea por máquina, con la fecha.
