docker: install ca-certificates in Debian image final stages

[robobun]

Summary

oven/bun:latest stopped being able to apt-get install over HTTPS in 1.3.14. apt fails with:

SSL connection failed: error:0A000086:SSL routines::certificate verify failed

Downgrading to oven/bun:1.3.13 fixes it.

Fixes #33135.

Reproduction

FROM oven/bun:1.3.14        # or :latest, or :1.3.14-slim
RUN apt-get update -y && apt-get install -y --no-install-recommends procps openssl

Err:1 https://deb.debian.org/debian trixie InRelease
  SSL connection failed: error:0A000086:SSL routines::certificate verify failed
E: Unable to locate package procps

oven/bun:1.3.13 builds the same Dockerfile successfully.

Root cause

1.3.14 moved the images from Debian 12 (bookworm) to Debian 13 (trixie) in 5bdb8ec. The tag mapping (.github/workflows/release.yml) is:

• oven/bun:latest, oven/bun:<version>, oven/bun:debian build from dockerhub/debian (FROM debian:trixie)
• oven/bun:<version>-slim, oven/bun:slim build from dockerhub/debian-slim (FROM debian:trixie-slim)

Neither debian:trixie nor debian:trixie-slim ships the ca-certificates package, so the final image has no system CA trust store (/etc/ssl/certs/ca-certificates.crt). The build stage installs ca-certificates, but that stage is thrown away; the runtime stage starts from a fresh base and never installs it.

On the bookworm images this was invisible because apt reached its mirror over HTTP, which needs no TLS verification. On trixie the mirror is reached over HTTPS (the reporter's log), and with no CA store the handshake fails with certificate verify failed.

bun itself is unaffected because it bundles its own root certificates (getBundledRootCertificates), so fetch and bun install over HTTPS keep working. The breakage is limited to system tools that use the system trust store, such as apt, curl, and wget.

Fix

Install ca-certificates in the final stage of both Debian images:

RUN apt-get update -qq \
    && apt-get install -qq --no-install-recommends ca-certificates \
    && apt-get clean \
    && rm -rf /var/lib/apt/lists/*

The alpine image uses apk over HTTP mirrors, and the distroless image has no package manager (and relies on bun's bundled roots), so neither is affected and both are left unchanged.

Tests

Extended the existing docker build smoke tests for the two Debian images (test/js/bun/test/parallel/test-docker-build-debian.ts and test-docker-build-debian-slim.ts) to build the image, then run it and assert the final image contains a non-empty /etc/ssl/certs/ca-certificates.crt. Without this change the file is absent and the assertion fails; with it the assertion passes. These run on the Docker CI lane.

Verification note

This is a Dockerfile-only change, so the automated fail-before/pass-after harness can't exercise it: it strips src//packages/ (this diff touches neither), and building the image requires pulling debian:trixie from Docker Hub, which the CI sandbox firewalls off. The root cause is confirmed from the official Debian rootfs manifests (no ca-certificates in trixie or trixie-slim, both using the same mirror scheme as bookworm which does not), the regressing commit, and the reporter's log. The added tests verify the fix on the Docker CI lane, where image pulls are allowed.

[robobun]

^{Updated 7:21 AM PT - Jun 30th, 2026}

❌ @robobun, your commit d3d103d has 4 failures in Build #67233 (All Failures):

• test/js/node/http/node-http-uaf.test.ts - code 1 on 🍎 26 aarch64
• test/js/bun/http/fetch-file-upload.test.ts - timeout on 🍎 26 aarch64
• test/js/bun/http/fetch-file-upload.test.ts - timeout on 🍎 26 aarch64
• test/js/bun/http/bun-serve-file.test.ts - timeout on 🍎 26 aarch64
• test/js/bun/http/bun-serve-file.test.ts - timeout on 🍎 26 aarch64
• test/js/node/test/parallel/test-net-connect-memleak.js - code 1 on 🐧 3.23 x64
• test/js/node/test/parallel/test-net-connect-memleak.js - code 1 on 🐧 3.23 x64-baseline

---

🧪   To try this PR locally:

bunx bun-pr 33136

That installs a local version of the PR into your bun-33136 executable, so you can run:

bun-33136 --bun

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: ASSERTIVE

Plan: Pro

Run ID: 7d1e4cca-6919-4a8b-afd3-185de457d76d

📥 Commits

Reviewing files that changed from the base of the PR and between ffea69a and fce55db.

📒 Files selected for processing (4)

• dockerhub/debian-slim/Dockerfile
• dockerhub/debian/Dockerfile
• test/js/bun/test/parallel/test-docker-build-debian-slim.ts
• test/js/bun/test/parallel/test-docker-build-debian.ts

---

Walkthrough

Both dockerhub/debian/Dockerfile and dockerhub/debian-slim/Dockerfile add a RUN step in their runtime stage to install ca-certificates and clean apt caches. The corresponding tests are updated to build with a unique image tag, run the built image to assert the CA certificate file exists, and clean up the tag afterward.

Changes

CA Certificates in Debian Docker Images

Layer / File(s)	Summary
Install ca-certificates in runtime stages dockerhub/debian/Dockerfile, dockerhub/debian-slim/Dockerfile	Each Dockerfile's runtime stage gains a RUN apt-get update && apt-get install -y --no-install-recommends ca-certificates block followed by apt cache cleanup.
Tests verify CA cert presence with tagged builds test/js/bun/test/parallel/test-docker-build-debian.ts, test/js/bun/test/parallel/test-docker-build-debian-slim.ts	Tests now build with a randomUUID-based image tag, run a container to check for /etc/ssl/certs/ca-certificates.crt and assert HAS_CA_CERTS output, and remove the tagged image in a finally block.

🚥 Pre-merge checks | ✅ 4

✅ Passed checks (4 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title clearly and concisely summarizes the main change: installing ca-certificates in Debian final image stages.
Description check	✅ Passed	The description covers the problem, root cause, fix, tests, and verification, though it uses custom headings instead of the template.
Linked Issues check	✅ Passed	The Dockerfile and test changes directly address issue #33135 by restoring CA trust stores in Debian images and verifying them.
Out of Scope Changes check	✅ Passed	The PR stays focused on Debian image CA certificates and matching tests, with no unrelated code changes evident.

---

_{Comment @coderabbitai help to get the list of available commands.}

[claude]

LGTM — straightforward Dockerfile fix adding ca-certificates to the trixie runtime stages, with a regression check in the existing Docker smoke tests.

Extended reasoning...

Overview

This PR adds a single RUN apt-get install ca-certificates layer to the final stage of dockerhub/debian/Dockerfile and dockerhub/debian-slim/Dockerfile, fixing a regression introduced when the base images moved from bookworm to trixie (#33135). It also extends the two existing Docker build smoke tests to tag the built image, run it, and assert /etc/ssl/certs/ca-certificates.crt is present and non-empty, with cleanup in a finally block.

Security risks

None. Installing ca-certificates from the official Debian repos is the standard way to provision the system trust store and strictly improves the image's TLS posture. No new network surfaces, credentials, or executable inputs are introduced.

Level of scrutiny

Low. The Dockerfile change is a 4-line idiomatic apt install/clean block identical in shape to what the build stage already runs successfully against the same base image, so there's no bootstrap concern. The test changes are mechanical: same Bun.spawn pattern as before, plus a -t <uuid> tag, a docker run check (the entrypoint correctly execs sh since it's on PATH), and docker rmi -f cleanup.

Other factors

No CODEOWNERS cover dockerhub/ or these test files, there are no outstanding reviewer comments, and the bug-hunting system found nothing. The change is small, self-contained, and clearly motivated by a linked user-reported regression.

[claude]

LGTM — straightforward fix adding ca-certificates to the Debian runtime stages.

Extended reasoning...

Overview

This PR adds a single RUN apt-get install ca-certificates step to the final (runtime) stage of dockerhub/debian/Dockerfile and dockerhub/debian-slim/Dockerfile, and extends the two existing Docker smoke tests to tag the built image, run it, and assert that /etc/ssl/certs/ca-certificates.crt is present and non-empty. The fix addresses #33135, where the bump to debian:trixie left the runtime image without a system CA trust store, breaking apt-get over HTTPS.

Security risks

None. Installing ca-certificates is the standard, expected way to provision a system trust store in Debian images — it strictly improves the security posture (TLS verification works) rather than weakening it. No new network surface, secrets, or permissions are introduced. The test changes only add a docker run invocation against a locally-built image with a UUID tag and clean it up in a finally block.

Level of scrutiny

Low. The Dockerfile change is mechanical and mirrors the identical apt-get install ca-certificates pattern already present in the build stage of the same files. It follows the established cleanup convention (apt-get clean && rm -rf /var/lib/apt/lists/*). The root-cause analysis in the PR description is detailed and correct, and the fix is the canonical remedy for this well-known class of issue.

Other factors

No CODEOWNERS cover the dockerhub/ or affected test paths. The bug-hunting system found no issues. I verified that docker-entrypoint.sh will correctly exec sh -c ... for the new test's docker run command. The test additions properly clean up the tagged image even on failure via try/finally. There are no outstanding reviewer comments.

[robobun]

CI status for reviewers: this diff is Dockerfile-only (plus the two docker-build test updates) and has zero effect on the bun binary. All compile/build lanes are green. The red test lanes across both CI runs are pre-existing flakes and infrastructure, not this change:

• darwin aarch64 test-bun (build 67217): test/cli/update_interactive_install.test.ts and test/js/bun/http/serve.test.ts, both marked flaky in the build annotation.
• alpine musl x64 and x64-baseline test-bun (build 67217): test/js/node/test/parallel/test-net-connect-memleak.js fails assert.strictEqual(collected, true), a GC/FinalizationRegistry timing flake not reachable from a Dockerfile change.
• darwin aarch64 test-bun (build 67233, the re-roll): buildkite-agent artifact download timed out after 120s fetching the darwin-aarch64-build-bun artifact, a CI infrastructure timeout (the runner never received the binary).

The docker-build tests that actually exercise this change (test/js/bun/test/parallel/test-docker-build-debian{,-slim}.ts) pass on the lanes where Docker is available. This is ready for review; I won't keep re-triggering CI for unrelated flakes.