[assadriaz]

Why

bellsoft/liberica-openjre-alpine:21.0.12.1 still trusts the roots behind the compromised eMudhra intermediate CAs, including the AAA Certificate Services cross-sign path. Java checks neither revocation nor Certificate Transparency by default, so irkalla's outbound TLS would accept certificates from those intermediates. That covers the Auth0 client-credentials calls to partner.entur.org / internal.entur.org (an attacker in the network path could capture the client secret) and the Aiven Kafka connection over SASL_SSL, which uses the JVM's default trust store. BellSoft lists 21.0.13.0.3+5 as the fixed build.

CI had the same problem: setup-java was pinned to Liberica 21.0.1+12, a pre-fix build.

Change

• Dockerfile: 21.0.12.1 → 21.0.13.0.3-5 in both stages. Exact tag; Java major version unchanged.
• .github/workflows/push.yml: maven-verify now runs on Liberica 21.0.13.0.3+5. setup-java's liberica distribution can't select this build: it turns 21.0.13.0.2+5 and 21.0.13.0.3+5 into the same semver (21.0.13+5). So the workflow downloads the exact tarball from BellSoft's GitHub release over HTTPS only (--proto '=https'), checks its SHA-256, and installs it with distribution: jdkfile. Same approach as Bump Liberica base image and CI JDK to 25.0.5.0.3+5 (eMudhra CA compromise) extime#634, Bump Liberica base image and CI JDK to 21.0.13.0.3+5 (eMudhra CA compromise) gibil#178 and Bump Liberica base image and CI JDK to 21.0.13.0.3+5 (eMudhra CA compromise) kakka#254.

Verification

~/.claude/skills/emudhra-fix/verify.sh (OpenJDK CheckCerts + BellSoft 12-chain test, with the image's own java, linux/amd64). Both images were built from this repo's Dockerfile with a jar built from this branch:

Check	Old	New
CheckCerts	FAIL: trusts emSign ECC Root CA - G3 and AAA Certificate Services	PASS: no bad roots
12-chain test	FAIL: 12/12 trusted	PASS: 0/12 trusted, 12 rejected
Ordinary HTTPS	PASS	PASS
OS trust store (curl)	skipped (no curl)	skipped (no curl)

Image digest tested: sha256:7f3dcd47f065b332b65021a8c535174428fa9bfccf3b284d40b4f0f7236425ce (local amd64 build)

Smoke test: both images start as appuser, log JSON ("using Java 21.0.13.0.3" on the new one), start Tomcat, and stop at the same missing dependency of the irkallaAuthorization… bean, which comes from cluster auth configuration.

CI JDK tarball: SHA-1 matches BellSoft's published 080b8962…; the workflow pins the SHA-256 (f6bac5c8…) computed from that verified file. Its cacerts has no emSign ECC Root CA - G3 or AAA Certificate Services. It is the same build as the JRE in the verified image.

Not covered: advisory -noct- hosts, OS store (no curl in image).

Heads-up for a later Renovate bump

src/main/resources/logback.xml uses <if condition='…'>. That stops working with logback 1.5.38 (Spring Boot 4.1.1, superpom 7.1.0): logback silently creates no appenders and the app logs nothing. irkalla is on superpom 4.10.0, so it is fine today, but the condition should move to the <condition> element (placed before <if>) when bumping. See entur/extime#635.

After merge

Re-run verify.sh against the deployed image digest.