diff --git a/other/Dockerfile b/other/Dockerfile
index 80d6c4e..ab91676 100644
--- a/other/Dockerfile
+++ b/other/Dockerfile
@@ -28,6 +28,21 @@ RUN npm prune --omit=dev
 # Build the app
 FROM base as build
 
+# The Sentry bundler plugin shells out to a native `sentry-cli` binary, and that
+# binary — unlike Node — verifies TLS against the system trust store. The slim
+# base image has no CA bundle at all:
+#
+#   $ docker run --rm node:22.23.3-bookworm-slim ls /etc/ssl/certs/ca-certificates.crt
+#   ls: cannot access '/etc/ssl/certs/ca-certificates.crt': No such file or directory
+#
+# So `npm install` succeeds (Node bundles its own roots) and then every release
+# and source-map upload fails with "SSL certificate problem: unable to get local
+# issuer certificate". This only ever surfaces once #16 makes the plugin reach
+# the API at all; before that the `org` guard returned before any network call.
+RUN apt-get update \
+    && apt-get install -y --no-install-recommends ca-certificates \
+    && rm -rf /var/lib/apt/lists/*
+
 ARG COMMIT_SHA
 ENV COMMIT_SHA=$COMMIT_SHA
 
diff --git a/tests/sentry-release.test.ts b/tests/sentry-release.test.ts
index 5cac095..9c5ab92 100644
--- a/tests/sentry-release.test.ts
+++ b/tests/sentry-release.test.ts
@@ -193,6 +193,16 @@ describe('Sentry release management build inputs', () => {
 		expect(dockerfile).toMatch(/^ENV COMMIT_SHA=\$COMMIT_SHA$/m)
 	})
 
+	it('installs a CA bundle, or the Sentry CLI cannot verify TLS', () => {
+		// `@sentry/vite-plugin` shells out to a native `sentry-cli`, which checks
+		// TLS against the system trust store rather than Node's bundled roots.
+		// `node:22.23.3-bookworm-slim` ships no CA bundle, so without this the
+		// first real upload fails with "unable to get local issuer certificate" —
+		// which is only reachable now that the plugin gets far enough to make a
+		// request. See #16.
+		expect(buildStage()).toMatch(/apt-get install[^\n]*ca-certificates/)
+	})
+
 	it('backs each build secret with a value in the step env', () => {
 		// The deploy step passes each secret as `--build-secret "NAME=$NAME"`, so
 		// the value is a shell expansion. If the `env:` entry behind it were