Ten of 30 popular Docker images still trust the emSign root that Chrome removed

Browsers moved, images did not

Chrome removed emSign ECC Root CA - G3 from its trusted root list on October 27, 2026, catching up with Mozilla's NSS library, which had dropped the root on October 20. The removals follow an incident involving weak keys in eight eMudhra intermediate certificates. According to a dev.to analysis citing the Google Security Blog, Chrome blocked the affected intermediates through CRLSet within hours of a report on October 17, and Firefox shipped equivalent protection via OneCRL on October 19. NSS 3.131.1 distrusted three emSign roots — emSign ECC Root CA - G3, emSign Root CA - C1 and emSign ECC Root CA - C3 — per an oss-security notice the post references.

Those revocation channels only reach browsers. As the dev.to post points out, curl, Python's requests, Go's net/http, Node and the JVM neither read CRLSets or OneCRL nor check revocation by default. For server-side and containerized code, the only real control is what sits inside the trust store — and if the root is still there, the application keeps accepting certificate chains to it.

What the scan found

The author scanned 30 of the most commonly used Docker images on October 24, 2026, for linux/amd64, reading image layers directly from the registry and inspecting the final contents of every trust store: system CA bundles, Python's certifi, and Java's cacerts.

Ten images still carried G3, including alpine:3.20, golang:1.24-alpine, amazonlinux:2023, amazoncorretto:21, eclipse-temurin:17-jre, eclipse-temurin:21-jre, both distroless Debian 12 variants, python:3.12-slim and python:3.12-alpine.

Ten more had bundles already free of G3 — among them alpine:3.22, alpine:latest, redhat/ubi9-minimal, python:3.13, node:22-alpine, both nginx images, httpd:2.4 and curlimages/curl — although four Debian trixie-based images in this group still shipped the C1 and C3 roots that NSS also distrusted.

The remaining ten, including the debian and ubuntu images, the node:*-slim variants, redis:7 and postgres:16, contained no CA bundle at all.

Three findings worth noting

One image can hold several trust stores. python:3.12-slim has a clean system bundle, yet the copy of certifi installed by pip still contains G3. The Temurin images carry both the operating system bundle and the JDK's cacerts, and both still include the root.

A recent build date means little. amazonlinux:2023 and amazoncorretto:21 were built on October 23, three days after the NSS fix, and still carried all four emSign roots, the post reports.

The absence of a bundle is not safety. Minimal images ship without ca-certificates, so what lands in your image depends on the package mirror or build cache at the moment your Dockerfile installs it.

How to fix it

The post offers a short checklist. Inventory the trust stores inside your finished application image, not just the base, since your own layers can add new ones — search for ca-certificates.crt, cacert.pem, ca-bundle.crt and cacerts. Inspect each PEM bundle with openssl storeutl and grep for the root's name, and check Java keystores with keytool. Then rebuild from fresh layers with docker build --pull --no-cache and repeat the checks.

Remediation depends on the store: refresh ca-certificates through the package manager, upgrade certifi (the 2026.10.19 release removed G3, per Endor Labs and SafeDep as cited in the post), or delete the emSign entries from cacerts with keytool -delete until a JDK update lands. Pointing Python at the system bundle via SSL_CERT_FILE reduces the number of bundles to maintain. For images without a shell, the post suggests docker create plus docker cp to extract the files. Finally, schedule regular --pull rebuilds and run the bundle check in CI.

Why it matters

Browser vendors contained this incident within hours because browsers update themselves; container images sit on a different supply chain with a different clock and will not change until someone rebuilds them. A stale trust store means a backend service silently keeps accepting certificate chains that every browser now rejects — a divergence between what users see as secure and what your infrastructure actually trusts. The scan has limits the author is explicit about: it was a one-time linux/amd64 snapshot, it skipped Node's built-in store and application-bundled certificates, and finding a root proves only that clients will accept chains to it, not that an attack occurred. The practical lesson stands regardless: the next CA incident will arrive on the browser vendors' schedule, but your exposure to it is set by your rebuild cadence.