# Saya Memindai 30 Image Docker Populer. 10 Masih Percaya Root CA yang Sudah Dicabut Chrome

> Checklist trust store container dengan data nyata: 30 image Docker dipindai 24 Oktober 2026. Sepertiga masih membawa emSign ECC Root CA - G3.

- URL: https://www.kielltampubolon.id/writing/saya-memindai-30-image-docker-populer-10-masih-percaya-root-ca-yang-dicabut-chrome/
- Author: Kiell Tampubolon
- Published: 2026-10-25
- Last updated: 2026-10-25
- Language: id
- Tags: Security Engineering, Deployment

## Key takeaways

- Mozilla mencabut emSign ECC Root CA - G3 pada 20 Oktober dan Chrome menyusul pada 27 Oktober, tetapi image container tidak memperbarui dirinya sendiri.
- Dari 30 image Docker yang dipindai pada 24 Oktober 2026, 10 masih membawa G3, 10 sudah tanpa G3, dan 10 tidak punya bundle CA.
- python:3.12-slim bersih di bundle sistem, tetapi salinan certifi di dalam pip masih membawa G3.
- amazonlinux:2023 dan amazoncorretto:21 dibangun 23 Oktober, tiga hari setelah perbaikan NSS, dan masih membawa keempat root emSign.
- Perbaikannya: cari semua trust store, cek isinya, lalu rebuild dengan docker build --pull --no-cache.

*Versi bahasa Inggris dengan metodologi lengkap: [The eMudhra Fallout, Part 2: I Scanned 30 Docker Images](https://www.kielltampubolon.id/writing/the-emudhra-fallout-part-2-i-scanned-30-docker-images-10-still-trust-the-root-chrome-is-dropping/).*

Mulai 27 Oktober 2026, Chrome menghapus emSign ECC Root CA - G3 dari daftar root yang dipercayainya. Mozilla NSS sudah menghapusnya sejak 20 Oktober. Browser di laptop kamu sudah aman. Pertanyaan yang lebih penting untuk tim backend: bagaimana dengan image Docker yang kamu pakai minggu ini?

Saya memindai 30 image Docker paling umum dan membuka setiap trust store di dalamnya. Hasilnya: 10 image masih membawa root yang sudah dicabut itu.

## TL;DR

> - Setelah insiden kunci lemah di delapan intermediate CA eMudhra, Mozilla mencabut root emSign ECC Root CA - G3 pada 20 Oktober, dan Chrome menyusul pada 27 Oktober. Browser memperbarui dirinya sendiri; image container tidak.
> - Dari 30 image yang saya pindai pada 24 Oktober 2026: **10 masih membawa G3**, **10 sudah tanpa G3**, dan **10 tidak punya bundle CA sama sekali**.
> - Image yang terlihat "sudah dipatch" bisa tetap rentan: `python:3.12-slim` bersih di bundle sistem, tapi salinan certifi di dalam pip masih membawa G3.
> - Image baru belum tentu sudah berisi perbaikan: `amazonlinux:2023` dan `amazoncorretto:21` dibangun 23 Oktober, tiga hari setelah perbaikan NSS, dan masih membawa keempat root emSign.
> - Perbaikannya murah: cari semua bundle, cek isinya, lalu rebuild dengan `--pull`. Checklist lengkapnya ada di bawah.

## Kenapa ini urusan backend, bukan browser

Chrome memblokir delapan intermediate CA itu lewat CRLSet dalam hitungan jam setelah laporan masuk pada 17 Oktober ([Google Security Blog](https://blog.google/security/protecting-chrome-and-android-users-from-compromised-emudhra-intermediate-ca-certificates/)). Firefox terlindungi lewat OneCRL pada 19 Oktober. Lalu NSS 3.131.1 pada 20 Oktober mencabut kepercayaan pada emSign ECC Root CA - G3, emSign Root CA - C1, dan emSign ECC Root CA - C3 ([oss-security](https://www.openwall.com/lists/oss-security/2026/10/20/30)).

Masalahnya, CRLSet dan OneCRL hanya dipakai browser. curl, `requests` di Python, `net/http` di Go, Node, dan JVM tidak membacanya, dan secara default juga tidak mengecek revocation. Untuk aplikasi seperti itu, satu-satunya kontrol adalah isi trust store. Kalau root-nya masih ada di sana, aplikasi akan tetap menerima rantai sertifikat ke root tersebut.

## Hasil pemindaian

![Grid 30 image Docker: 10 masih membawa emSign ECC Root CA - G3, 10 punya bundle dengan G3 sudah dihapus, 10 tidak punya bundle CA.](https://www.kielltampubolon.id/writing/saya-memindai-30-image-docker-populer-10-masih-percaya-root-ca-yang-dicabut-chrome/img-1.png)

Saya membaca layer image langsung dari registry (tanpa Docker daemon), mengambil isi akhir setiap trust store, lalu memeriksa sertifikat di dalamnya. Yang diperiksa: bundle sistem (`/etc/ssl/certs/ca-certificates.crt` dan padanannya di keluarga RHEL), `certifi/cacert.pem`, dan `cacerts` milik Java.

| Kelompok | Image |
|---|---|
| Masih membawa G3 (10) | alpine:3.20, golang:1.24-alpine, amazonlinux:2023, amazoncorretto:21, eclipse-temurin:17-jre, eclipse-temurin:21-jre, distroless base-debian12, distroless static-debian12, python:3.12-slim, python:3.12-alpine |
| Bundle ada, G3 sudah hilang (10; empat di antaranya, berbasis Debian trixie, masih membawa root C1 dan C3 yang juga dicabut NSS) | alpine:3.22, alpine:latest, redhat/ubi9-minimal, python:3.13, python:3.13-slim, node:22-alpine, nginx:stable, nginx:alpine, httpd:2.4, curlimages/curl |
| Tidak ada bundle CA (10) | debian:12, debian:12-slim, debian:13-slim, ubuntu:22.04, ubuntu:24.04, node:20-slim, node:22-slim, node:24-slim, redis:7, postgres:16 |

Tiga pelajaran yang paling berguna untuk tim:

**1. Satu image bisa punya lebih dari satu trust store.** `python:3.12-slim` sudah bersih di bundle sistem, tapi pip membawa salinan certifi sendiri yang masih berisi G3. Image Java seperti Temurin punya bundle Ubuntu *dan* `cacerts` milik JDK, dan keduanya masih membawa G3.

![Dua kartu: python:3.12-slim bersih di bundle sistem tapi G3 masih ada di certifi milik pip; eclipse-temurin:21-jre membawa G3 di bundle sistem dan di cacerts JDK.](https://www.kielltampubolon.id/writing/saya-memindai-30-image-docker-populer-10-masih-percaya-root-ca-yang-dicabut-chrome/img-2.png)

**2. Tanggal build bukan jaminan.** `amazonlinux:2023` dan `amazoncorretto:21` dibangun 23 Oktober, tapi keempat root emSign masih ada di dalamnya.

**3. "Tidak ada bundle" bukan berarti aman.** `debian:12-slim` dan image `node:*-slim` tidak membawa `ca-certificates`. Begitu Dockerfile kamu menjalankan `apt-get install ca-certificates`, versi yang terpasang tergantung mirror hari itu, atau cache build lama kamu.

## Checklist untuk tim

Jalankan di dalam container dari image *kamu sendiri*, bukan base image-nya, karena layer kamu bisa menambah trust store baru. Image minimal (Alpine, distroless) sering tidak punya `openssl`, `keytool`, bahkan shell; untuk image seperti itu, `docker create` image-nya lalu salin file bundle dengan `docker cp` dan periksa di mesin kamu.

**1. Inventaris trust store**

```bash
find / \( -name 'ca-certificates.crt' -o -name 'cacert.pem' -o -name 'ca-bundle.crt' -o -name cacerts \) 2>/dev/null
```

**2. Cek root di setiap bundle PEM**

```bash
openssl storeutl -noout -text -certs /etc/ssl/certs/ca-certificates.crt | grep 'emSign ECC Root CA - G3'
```

**3. Cek keystore Java**

```bash
keytool -list -cacerts -storepass changeit | grep -i emsign
```

**4. Rebuild dari layer segar, lalu ulangi langkah 1 sampai 3**

```bash
docker build --pull --no-cache -t aplikasi:ca-refresh .
```

**5. Perbaiki sesuai jenis store**

- **Bundle sistem:** pakai base image yang sudah memuat `ca-certificates` terbaru, atau tambahkan `apt-get update && apt-get install -y ca-certificates` / `apk upgrade ca-certificates` di layer kamu.
- **certifi:** jalankan `pip install -U certifi` (menurut Endor Labs dan SafeDep, versi 2026.10.19 sudah menghapus G3). Salinan certifi di dalam pip baru ikut berubah kalau pip-nya diperbarui. Lebih baik lagi, arahkan Python ke bundle sistem dengan `SSL_CERT_FILE`, supaya hanya ada satu bundle yang perlu dirawat.
- **Java:** pakai build JDK yang sudah memuat pembaruan, atau hapus alias emSign dari `cacerts` dengan `keytool -delete` sampai vendor JDK merilis versi baru.

**6. Jadikan rutin.** Jadwalkan rebuild mingguan dengan `--pull` dan tambahkan langkah 2 sebagai cek di CI. Insiden CA berikutnya akan datang, dan yang menentukan seberapa cepat kamu aman adalah jadwal rebuild, bukan jadwal browser.

## Batasan data

- Pemindaian dilakukan sekali, 24 Oktober 2026, untuk `linux/amd64`. Tag image terus bergerak, jadi ulangi sebelum mengutip angka ini.
- Yang diperiksa hanya bundle sistem, certifi, dan `cacerts` Java. Trust store bawaan Node dan bundle yang dibawa aplikasi tidak termasuk.
- Versi paket perbaikan per distro berasal dari sumber sekunder (Endor Labs, SafeDep), kecuali yang terlihat langsung di image.
- Keberadaan root hanya menunjukkan bahwa klien *akan* menerima rantai ke root itu, bukan bukti ada serangan.

## Penutup

Vendor browser menangani insiden ini dalam hitungan jam. Image container punya jalur pasokan yang berbeda, dengan jam yang berbeda, dan tidak akan berubah sampai kamu rebuild. Empat perintah di checklist di atas cukup untuk tahu posisi tim kamu hari ini.

Di tim kamu, siapa yang bertanggung jawab memastikan trust store di image produksi tetap mutakhir?

## FAQ

### Image Docker mana yang masih membawa emSign ECC Root CA - G3?

Pada pemindaian 24 Oktober 2026, 10 dari 30 image, antara lain alpine:3.20, amazonlinux:2023, amazoncorretto:21, eclipse-temurin:17-jre dan 21-jre, distroless Debian 12, python:3.12-slim, dan python:3.12-alpine.

### Kenapa image yang sudah dipatch bisa tetap membawa root itu?

Satu image bisa punya beberapa trust store. python:3.12-slim bersih di bundle sistem, tetapi pip membawa certifi sendiri yang masih berisi G3, dan image Java punya cacerts terpisah.

### Apakah image tanpa bundle CA otomatis aman?

Tidak. debian:12-slim dan image node:*-slim tidak membawa ca-certificates, sehingga versi yang terpasang nanti tergantung mirror atau cache build kamu.

### Bagaimana cara memeriksa image saya sendiri?

Cari semua bundle dengan find, periksa bundle PEM dengan openssl storeutl dan keystore Java dengan keytool, lalu rebuild dengan docker build --pull --no-cache dan ulangi pemeriksaan.