[{"data":1,"prerenderedAt":189},["ShallowReactive",2],{"seo-verification":3,"blog-emudhra-check-the-trust-store-on-your-servers-en":6},{"google":4,"bing":5},"EycwPY2XMyTkVzas3n1ygeNJFGAH513qrMjfDljzsMQ","",{"key":7,"data":8},"blog-emudhra-check-the-trust-store-on-your-servers-en",{"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-check-the-trust-store-on-your-servers",{"fr":12,"en":10,"ar":13,"es":14},"emudhra-ca-intermediaires-compromises-magasin-confiance-verifier","emudhra-تحقق-من-مخزن-الثقة-في-خوادمك","emudhra-verificar-el-almacen-de-confianza-de-sus-servidores","eMudhra: check the trust store on your servers","Eight eMudhra intermediate CAs were compromised: audit ca-certificates, curl, Python, Node, Java and containers with commands, and see what still awaits a fix.",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,"Security & Monitoring","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","In October 2026, browsers blocked eight eMudhra intermediate certificate authorities, but a server is not a browser: curl, git, Python, Node, Java and your containers each carry their own list of trusted authorities. Whether you run a fleet of client machines or your own servers, the question is no longer \"does the browser protect the user?\" but \"which machine still trusts these certificates, and exactly where?\". This guide gives the full audit, command by command, and states plainly what was still waiting for an upstream fix when it was written.",[35,39,42,52,55,83,119,122,125,129,132],{"type":36,"title":37,"body":38},"h2","What happened, with dates","On 17 October 2026, a researcher reported to the root programs that eight eMudhra intermediate authorities had been created with badly generated keys. Firefox and Chrome blocked these certificates the same day. On 20 October 2026, Microsoft started blocking them and the curl bundle moved to its 20 October version. On 22 October 2026, Apple followed for applications that use its networking frameworks.\n\nOn 20 October 2026, Debian also published advisory DSA-6572-1: the ca-certificates package in version 20250419+deb13u1, for Debian stable (trixie), removes the certificates named \"emSign ECC Root CA - G3\" and \"Comodo AAA Services root\". Two details matter later. The advisory speaks of compromised eMudhra intermediates, but the two certificates it names carry root names. And it lists a fixed version only for trixie: for other distributions, read that distribution's own advisory rather than assuming.",{"type":36,"title":40,"body":41},"Why \"browsers already blocked it\" does not close the case","This is the most common objection, and it is half right. According to the researcher's reference page, browsers that enforce Certificate Transparency could not be attacked through these intermediates. But a server calling an API, a deployment script cloning a repository, a scheduled job downloading an archive or a container installing a dependency are not browsers. These clients check the chain against a file, and generally check neither transparency nor revocation. On 28 October 2026, the researcher's reference page noted, for example, that Apple's command-line tools (git, curl, python3) still trusted these certificates.\n\nSecond objection: who is responsible? The agency owns the client relationship. The infrastructure is checked server by server, and nobody else will do it for you.",{"type":43,"title":44,"items":45},"ul","Where a trust store lives on a machine",[46,47,48,49,50,51],"**The system package** — `ca-certificates` on Debian, Ubuntu and Alpine, the same name on RHEL and derivatives. It is the reference for everything that reads `\u002Fetc\u002Fssl\u002Fcerts`.","**The curl bundle** — depending on the build, curl reads the system store or a separate file. `curl-config --ca` tells you which.","**Python and certifi** — the `certifi` module ships its own bundle, and pip uses it. A system update does not touch it.","**Node.js** — the binary embeds a list of authorities. `NODE_EXTRA_CA_CERTS` adds some, it removes none.","**Java** — the JDK `cacerts` file is a store independent of the rest. The OpenJDK fix was still pending on the reference page, and nothing guarantees that your distribution carries the system package update into it.","**Every container image** — it has its own `\u002Fetc\u002Fssl\u002Fcerts`, frozen at build time. The host fix does not reach it.",{"type":36,"title":53,"body":54},"Audit prerequisites, in numbers","Plan for root or sudo access on each machine, about 15 minutes for the first pass on a server, then 5 minutes as a routine once the commands are familiar. There are five places to inspect per machine (system package, curl, certifi, Node, Java) and one more per container image. Keep at least two test hosts whose chain you know, for example www.your-domain.com and an API your applications call. For Java services, also plan a restart window: a replaced store is only read again when the JVM starts.",{"type":56,"title":57,"steps":58},"steps","The procedure, server by server",[59,62,65,68,71,74,77,80],{"title":60,"body":61},"Read the package version","`dpkg -l ca-certificates` on Debian and Ubuntu, `rpm -q ca-certificates` on RHEL and derivatives, `apk info -v ca-certificates` on Alpine. On Debian stable (trixie), the fixed version in advisory DSA-6572-1 is 20250419+deb13u1: if yours is older, go to the next step.",{"title":63,"body":64},"Update the store","On Debian and Ubuntu: `apt update` then `apt install --only-upgrade ca-certificates`, then `update-ca-certificates`. On RHEL and derivatives: `dnf upgrade ca-certificates` then `update-ca-trust`. On Alpine: `apk upgrade ca-certificates`.",{"title":66,"body":67},"Check that the removed certificates are gone","`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'`\nAfter an update that removes the two certificates named by Debian, no line should come out. The pattern targets only the two certificates named by the Debian advisory, because other valid emSign or Comodo roots legitimately remain. A line means a store left at the old version, or a directory fed by hand. Check the real file names on an up-to-date machine.",{"title":69,"body":70},"Test a chain from the server","`openssl s_client -connect www.your-domain.com:443 -showcerts` prints each certificate sent and ends with the `Verify return code` line. Code 0 means the chain is accepted by the local store. Complete it with `curl -v https:\u002F\u002Fwww.your-domain.com` and read the `SSL certificate verify ok` line.",{"title":72,"body":73},"List the bundles outside the system store","`curl-config --ca` gives the path of the curl bundle.\n`python3 -c \"import certifi; print(certifi.where())\"` gives the Python one.\n`echo $NODE_EXTRA_CA_CERTS` shows any Node additions.\n`readlink -f $(which java)` leads back to the JDK, whose `lib\u002Fsecurity\u002Fcacerts` is the store.",{"title":75,"body":76},"Update certifi","`pip show certifi` gives the installed version, `python3 -m pip install --upgrade certifi` updates it. The researcher's reference page lists certifi 2026.10.19 among the fixed versions. Repeat in every virtual environment, since each has its own copy.",{"title":78,"body":79},"Check the Java store","`keytool -list -keystore $JAVA_HOME\u002Flib\u002Fsecurity\u002Fcacerts -storepass changeit | grep -i -E 'emsign ecc|aaa'` looks for the entries concerned; aliases vary by JDK, so compare with the list on the reference page. The OpenJDK fix was still pending at the date of that page: if an affected entry is present, record the machine as \"awaiting upstream\" rather than \"fixed\".",{"title":81,"body":82},"Record the result in your monthly audit","One line per server: date, ca-certificates version, bundle paths, chain test result. This record is what you show the client when they ask what was checked, and it fits into the monthly audit checklist for your client VPS.",{"type":84,"title":85,"headers":86,"rows":90},"comparison","Where to look, component by component",[87,88,89],"Component","Where the trust list lives","Check command",[91,95,99,103,107,111,115],[92,93,94],"Debian, Ubuntu system","ca-certificates package, \u002Fetc\u002Fssl\u002Fcerts directory","`dpkg -l ca-certificates`",[96,97,98],"RHEL and derivatives system","ca-certificates package, store managed by update-ca-trust","`rpm -q ca-certificates`",[100,101,102],"curl","System store or build-time bundle","`curl-config --ca`",[104,105,106],"Python, pip","certifi module, independent of the system","`python3 -c \"import certifi; print(certifi.where())\"`",[108,109,110],"Node.js","List built into the binary, plus NODE_EXTRA_CA_CERTS","`echo $NODE_EXTRA_CA_CERTS`",[112,113,114],"Java","JDK cacerts file","`keytool -list -keystore $JAVA_HOME\u002Flib\u002Fsecurity\u002Fcacerts -storepass changeit`",[116,117,118],"Docker container","\u002Fetc\u002Fssl\u002Fcerts specific to each image","`docker run --rm IMAGE ls \u002Fetc\u002Fssl\u002Fcerts`",{"type":36,"title":120,"body":121},"Containers: the host fix does not pass through","A container does not inherit its host's store. It carries the one from its base image, frozen on the day of the build. Updating ca-certificates on the server therefore changes nothing for your containers. To inspect an image, run `docker run --rm IMAGE ls \u002Fetc\u002Fssl\u002Fcerts`, or `docker run --rm IMAGE dpkg -l ca-certificates` if the image is based on Debian or Ubuntu.\n\nThe remedy is a rebuild: `docker build --pull --no-cache -t my-application:2026-10 .` pulls the latest base image and redoes the certificate layer. Without `--pull`, Docker reuses the cached base, and you rebuild the same defect. Then redeploy and rerun the check on the running container. Remember third-party images (database, proxy, monitoring tool) that you do not build: their publisher must release a new version, and you need to verify it.",{"type":36,"title":123,"body":124},"If a client certificate chains to these authorities","There are two cases, and they must be kept apart. First: a certificate issued for your client, or for you, was signed by one of the affected intermediates. Read the issuer with `openssl x509 -in certificat.pem -noout -subject -issuer -dates`, then the served chain with `openssl s_client -connect www.your-domain.com:443 -showcerts`. The reference page publishes the list of affected intermediates (file `impacted-intermediates.json`): compare it with what you read. If the issuer is there, ask the issuing authority for a reissue under another chain, without waiting for expiry.\n\nSecond case: a partner connects to you with a client certificate (mTLS) and your server accepts it because its store contains an affected authority. After the update, that partner may be refused, which is the intended behaviour but must be announced. Warn them beforehand, list the active client certificates, and keep a record of the replacement date.",{"type":126,"title":127,"body":128},"tip","Test before and after, on real hosts","Removing a root can break legitimate chains attached to it. Before the update, run `curl -sS -o \u002Fdev\u002Fnull -w '%{http_code}\\n' https:\u002F\u002Fwww.your-domain.com` against three or four hosts that your applications really call, then rerun the same command afterwards. A changed code or a verification error is settled right away, on one server, rather than in production on a Monday morning.",{"type":36,"title":130,"body":131},"Troubleshooting: the errors you will see","After the update, four messages come back. `curl: (60) SSL certificate problem: unable to get local issuer certificate`: the remote server sends an incomplete chain, or its chain went through a certificate that is now removed. Test with `openssl s_client -showcerts`, then ask the service owner to fix their chain.\n\n`ssl.SSLCertVerificationError: CERTIFICATE_VERIFY_FAILED` on the Python side: the interpreter uses the certifi store or the system one, depending on the application. Read the path with `certifi.where()` and update the right component.\n\n`PKIX path building failed: unable to find valid certification path to requested target` on the Java side: the `cacerts` file does not contain the expected authority or has been replaced. Check with `keytool`, then restart the JVM.\n\n`Verify return code: 20 (unable to get local issuer certificate)` in `openssl s_client`: the authority is no longer in `\u002Fetc\u002Fssl\u002Fcerts`. If the site is legitimate, this is a signal to handle on the remote server, not to bypass by disabling verification.",{"type":36,"title":133,"body":134},"What is still pending, and who carries what","At the date of the reference page, updated on 28 October 2026, the NSS library was fixed in version 3.131.1 and the curl bundle had been since 20 October 2026, but the OpenJDK fix was still pending, and Apple's command-line tools kept trusting the certificates. Reread that page before telling a client that everything is fixed: the state changes, and your report should state the date of the check.\n\nFor an agency, the split is simple. You keep the client relationship and the report that proves what was checked. The check itself happens machine by machine. If you run your own servers, the report is the same minus the client: one line per machine, with the date.","A client's servers, gathered in one place","With ServOrbit.com, a client's hosting, VPS and domains sit in one place, which simplifies keeping track of what you manage.","See the security approach","\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,"monthly-security-audit-checklist-client-vps-agency",{"fr":144,"en":142,"ar":145,"es":146},"checklist-audit-securite-mensuel-vps-clients-agence","قائمة-تدقيق-أمان-vps-شهرية-للعملاء-للوكالات","auditoria-seguridad-mensual-vps-clientes-agencia-checklist","Monthly client VPS security audit: a 45-minute checklist","Seven checks to run every month on a client VPS: updates, kernel, SSH accounts, ports, certificates, backups, logs. Includes a dated one-page report.",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,"linux-vps-hardening-checklist-for-agencies",{"fr":160,"en":158,"ar":161,"es":162},"linux-hardening-vps-checklist","قائمة-تصليب-خادم-لينكس-للوكالات-بعد-التسليم","hardening-linux-vps-checklist-para-agencias-tras-la-entrega","Linux VPS Hardening Checklist for Agencies","Reproducible Linux hardening checklist for agencies: auditd, sudo user, SSH key auth, UFW, fail2ban and root lockout — with per-client traceability.",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-audit-and-patch-to-1-30-6",{"fr":177,"en":175,"ar":178,"es":179},"nginx-cve-2026-15176-mettre-a-jour","ثغرة-nginx-cve-2026-15176-الفحص-والتحديث-إلى-1-30-6","nginx-cve-2026-15176-auditar-y-actualizar-a-1-30-6","nginx CVE-2026-15176: audit and patch to 1.30.6","nginx 1.30.6 and 1.31.7 fix five flaws, including CVE-2026-15176. Affected versions, config audit commands, updates per system and mitigations.",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",1793480308191]