[{"data":1,"prerenderedAt":189},["ShallowReactive",2],{"seo-verification":3,"blog-emudhra-verificar-el-almacen-de-confianza-de-sus-servidores-es":6},{"google":4,"bing":5},"EycwPY2XMyTkVzas3n1ygeNJFGAH513qrMjfDljzsMQ","",{"key":7,"data":8},"blog-emudhra-verificar-el-almacen-de-confianza-de-sus-servidores-es",{"id":9,"slug":10,"slugs":11,"title":15,"excerpt":16,"readTime":17,"views":18,"isPinned":19,"publishedAt":20,"updatedAt":21,"category":22,"categories":28,"featuredImage":30,"bgImage":31,"posterImage":32,"relatedSolution":30,"intro":33,"sections":34,"ctaTitle":135,"ctaBody":136,"ctaButton":137,"ctaUrl":138,"relatedPosts":139},551,"emudhra-verificar-el-almacen-de-confianza-de-sus-servidores",{"fr":12,"en":13,"ar":14,"es":10},"emudhra-ca-intermediaires-compromises-magasin-confiance-verifier","emudhra-check-the-trust-store-on-your-servers","emudhra-تحقق-من-مخزن-الثقة-في-خوادمك","eMudhra: verificar el almacén de confianza de sus servidores","Ocho CA intermedias de eMudhra comprometidas: audite ca-certificates, curl, Python, Node, Java y contenedores con comandos, y vea qué espera aún un parche.",9,0,false,"2026-10-31T00:00:00+00:00","2026-10-31T19:07:30+00:00",{"id":23,"name":24,"slug":25,"color":26,"icon":27},8,"Seguridad y monitorización","securite-monitoring","bg-rose-500\u002F10 text-rose-400","security",[29],{"id":23,"name":24,"slug":25,"color":26,"icon":27},null,"\u002Fblog\u002Fcovers\u002Fbg.svg","\u002Fblog\u002Fcovers\u002Femudhra-ca-intermediaires-compromises-magasin-confiance-verifier-poster.svg","En octubre de 2026, los navegadores bloquearon ocho autoridades intermedias de eMudhra, pero un servidor no es un navegador: curl, git, Python, Node, Java y sus contenedores llevan cada uno su propia lista de autoridades de confianza. Ya gestione una flota de máquinas de clientes o sus propios servidores, la pregunta ya no es «¿protege el navegador al usuario?», sino «¿qué máquina sigue confiando en estos certificados, y en qué lugar exacto?». Esta guía ofrece la auditoría completa, comando a comando, e indica con franqueza qué esperaba todavía una corrección del proveedor original cuando se redactó.",[35,39,42,52,55,83,119,122,125,129,132],{"type":36,"title":37,"body":38},"h2","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.\n\nEl 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.",{"type":36,"title":40,"body":41},"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.\n\nSegunda 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.",{"type":43,"title":44,"items":45},"ul","Dónde vive un almacén de confianza en una máquina",[46,47,48,49,50,51],"**El paquete del sistema** — `ca-certificates` en Debian, Ubuntu y Alpine, con el mismo nombre en RHEL y derivadas. Es la referencia de todo lo que lee `\u002Fetc\u002Fssl\u002Fcerts`.","**El paquete de curl** — según la compilación, curl lee el almacén del sistema o un archivo aparte. `curl-config --ca` indica cuál.","**Python y certifi** — el módulo `certifi` incluye 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_CERTS` añade algunas, no retira ninguna.","**Java** — el archivo `cacerts` del 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 `\u002Fetc\u002Fssl\u002Fcerts`, congelado en el momento de la construcción. La corrección del anfitrión no le llega.",{"type":36,"title":53,"body":54},"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.",{"type":56,"title":57,"steps":58},"steps","El procedimiento, servidor por servidor",[59,62,65,68,71,74,77,80],{"title":60,"body":61},"Leer la versión del paquete","`dpkg -l ca-certificates` en Debian y Ubuntu, `rpm -q ca-certificates` en RHEL y derivadas, `apk info -v ca-certificates` en 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.",{"title":63,"body":64},"Actualizar el almacén","En Debian y Ubuntu: `apt update` y luego `apt install --only-upgrade ca-certificates`, y después `update-ca-certificates`. En RHEL y derivadas: `dnf upgrade ca-certificates` y luego `update-ca-trust`. En Alpine: `apk upgrade ca-certificates`.",{"title":66,"body":67},"Comprobar que los certificados retirados han desaparecido","`ls \u002Fusr\u002Fshare\u002Fca-certificates\u002Fmozilla | grep -i -E 'emSign_ECC_Root_CA_-_G3|Comodo_AAA'`\n`ls \u002Fetc\u002Fssl\u002Fcerts | grep -i -E 'emSign_ECC_Root_CA_-_G3|Comodo_AAA'`\nTras 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.",{"title":69,"body":70},"Probar una cadena desde el servidor","`openssl s_client -connect www.your-domain.com:443 -showcerts` muestra cada certificado enviado y termina con la línea `Verify return code`. El código 0 significa que el almacén local acepta la cadena. Complételo con `curl -v https:\u002F\u002Fwww.your-domain.com` y lea la línea `SSL certificate verify ok`.",{"title":72,"body":73},"Inventariar los paquetes fuera del almacén del sistema","`curl-config --ca` da la ruta del paquete de curl.\n`python3 -c \"import certifi; print(certifi.where())\"` da la de Python.\n`echo $NODE_EXTRA_CA_CERTS` muestra las posibles incorporaciones de Node.\n`readlink -f $(which java)` lleva hasta el JDK, cuyo `lib\u002Fsecurity\u002Fcacerts` es el almacén.",{"title":75,"body":76},"Actualizar certifi","`pip show certifi` da la versión instalada, `python3 -m pip install --upgrade certifi` la 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.",{"title":78,"body":79},"Controlar el almacén de Java","`keytool -list -keystore $JAVA_HOME\u002Flib\u002Fsecurity\u002Fcacerts -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».",{"title":81,"body":82},"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.",{"type":84,"title":85,"headers":86,"rows":90},"comparison","Dónde buscar, componente por componente",[87,88,89],"Componente","Dónde vive la lista de confianza","Comando de control",[91,95,99,103,107,111,115],[92,93,94],"Sistema Debian, Ubuntu","Paquete ca-certificates, directorio \u002Fetc\u002Fssl\u002Fcerts","`dpkg -l ca-certificates`",[96,97,98],"Sistema RHEL y derivadas","Paquete ca-certificates, almacén gestionado por update-ca-trust","`rpm -q ca-certificates`",[100,101,102],"curl","Almacén del sistema o paquete de compilación","`curl-config --ca`",[104,105,106],"Python, pip","Módulo certifi, independiente del sistema","`python3 -c \"import certifi; print(certifi.where())\"`",[108,109,110],"Node.js","Lista integrada en el binario, más NODE_EXTRA_CA_CERTS","`echo $NODE_EXTRA_CA_CERTS`",[112,113,114],"Java","Archivo cacerts del JDK","`keytool -list -keystore $JAVA_HOME\u002Flib\u002Fsecurity\u002Fcacerts -storepass changeit`",[116,117,118],"Contenedor Docker","\u002Fetc\u002Fssl\u002Fcerts propio de cada imagen","`docker run --rm IMAGE ls \u002Fetc\u002Fssl\u002Fcerts`",{"type":36,"title":120,"body":121},"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 \u002Fetc\u002Fssl\u002Fcerts`, o `docker run --rm IMAGE dpkg -l ca-certificates` si la imagen se basa en Debian o Ubuntu.\n\nEl 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.",{"type":36,"title":123,"body":124},"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.\n\nEl 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.",{"type":126,"title":127,"body":128},"tip","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 \u002Fdev\u002Fnull -w '%{http_code}\\n' https:\u002F\u002Fwww.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.",{"type":36,"title":130,"body":131},"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.\n\n`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.\n\n`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.\n\n`Verify return code: 20 (unable to get local issuer certificate)` en `openssl s_client`: la autoridad ya no está en `\u002Fetc\u002Fssl\u002Fcerts`. Si el sitio es legítimo, es una señal que debe tratarse en el servidor remoto, no eludirse desactivando la verificación.",{"type":36,"title":133,"body":134},"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.\n\nPara 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.","Los servidores de un cliente, en un mismo lugar","Con ServOrbit.com, el alojamiento, los VPS y los dominios de un cliente están en un mismo lugar, lo que simplifica el seguimiento de lo que usted gestiona.","Ver el enfoque de seguridad","\u002Fpourquoi\u002Fsecurite",[140,156,173],{"id":141,"slug":142,"slugs":143,"title":147,"excerpt":148,"readTime":149,"views":18,"isPinned":19,"publishedAt":150,"updatedAt":151,"category":152,"categories":153,"featuredImage":30,"bgImage":31,"posterImage":155,"relatedSolution":30},521,"auditoria-seguridad-mensual-vps-clientes-agencia-checklist",{"fr":144,"en":145,"ar":146,"es":142},"checklist-audit-securite-mensuel-vps-clients-agence","monthly-security-audit-checklist-client-vps-agency","قائمة-تدقيق-أمان-vps-شهرية-للعملاء-للوكالات","Auditoría mensual de un VPS cliente: checklist en 45 min","Siete controles para repetir cada mes en un VPS cliente: actualizaciones, kernel, cuentas SSH, puertos, certificados, copias, registros. Con informe fechado.",10,"2026-10-28T00:00:00+00:00","2026-10-29T03:10:22+00:00",{"id":23,"name":24,"slug":25,"color":26,"icon":27},[154],{"id":23,"name":24,"slug":25,"color":26,"icon":27},"\u002Fblog\u002Fcovers\u002Fchecklist-audit-securite-mensuel-vps-clients-agence-poster.svg",{"id":157,"slug":158,"slugs":159,"title":163,"excerpt":164,"readTime":165,"views":166,"isPinned":19,"publishedAt":167,"updatedAt":168,"category":169,"categories":170,"featuredImage":30,"bgImage":31,"posterImage":172,"relatedSolution":30},317,"hardening-linux-vps-checklist-para-agencias-tras-la-entrega",{"fr":160,"en":161,"ar":162,"es":158},"linux-hardening-vps-checklist","linux-vps-hardening-checklist-for-agencies","قائمة-تصليب-خادم-لينكس-للوكالات-بعد-التسليم","Hardening Linux VPS : checklist para agencias tras la entrega","Checklist de hardening Linux reproducible para agencias: auditd, sudo, clave SSH, UFW, fail2ban y desactivación de root — con trazabilidad por cliente.",11,2,"2026-08-30T00:00:00+00:00","2026-09-07T11:26:10+00:00",{"id":23,"name":24,"slug":25,"color":26,"icon":27},[171],{"id":23,"name":24,"slug":25,"color":26,"icon":27},"\u002Fblog\u002Fcovers\u002Flinux-hardening-vps-checklist-poster.svg",{"id":174,"slug":175,"slugs":176,"title":180,"excerpt":181,"readTime":182,"views":166,"isPinned":19,"publishedAt":183,"updatedAt":184,"category":185,"categories":186,"featuredImage":30,"bgImage":31,"posterImage":188,"relatedSolution":30},492,"nginx-cve-2026-15176-auditar-y-actualizar-a-1-30-6",{"fr":177,"en":178,"ar":179,"es":175},"nginx-cve-2026-15176-mettre-a-jour","nginx-cve-2026-15176-audit-and-patch-to-1-30-6","ثغرة-nginx-cve-2026-15176-الفحص-والتحديث-إلى-1-30-6","nginx CVE-2026-15176: auditar y actualizar a 1.30.6","nginx 1.30.6 y 1.31.7 corrigen cinco fallos, entre ellos CVE-2026-15176. Versiones afectadas, comandos de auditoría, actualización por sistema y mitigaciones.",12,"2026-10-22T00:00:00+00:00","2026-10-23T13:27:02+00:00",{"id":23,"name":24,"slug":25,"color":26,"icon":27},[187],{"id":23,"name":24,"slug":25,"color":26,"icon":27},"\u002Fblog\u002Fcovers\u002Fnginx-cve-2026-15176-mettre-a-jour-poster.svg",1793480443851]