fix(docker): replace outdated tcnative 1.2.35 with Apache tcnative 1.3.8

[wezell]

Summary

dotCMS's SSL offloading to openssl has been broken since we moved to Ubuntu 24.04. We haven't noticed because it would fall back to using java's SSL but this has performance implications and it is better to offload it.

Fixes #34067

dotCMS crashed on startup with a JVM SIGSEGV inside libcrypto.so.3 when the Tomcat Native APR library initialized OpenSSL 3.x. Root cause: the Ubuntu 24.04 libtcnative-1 package (1.2.35, Jan 2023) is incompatible with OpenSSL 3.x — the very library version all our images install to offload Tomcat 9's SSL.

Tomcat 9 requires the tcnative 1.x line (2.x is Tomcat 10.1+ only). This PR builds the current Apache release, tcnative 1.3.8, from source (SHA-512 pinned) against the image's own APR 1.7 / OpenSSL 3, and stops installing the distro package.

Changes

File	Change
docker/java-base/Dockerfile	Builds tcnative 1.3.8 into /usr/local/tomcat-native (built once per java-base release, reused downstream); build deps purged; JDK default 25.0.4+1-ms
dotCMS/src/main/docker/original/Dockerfile	Drops distro libtcnative-1; copies tcnative from java-base; sets LD_LIBRARY_PATH
docker/dev-env/Dockerfile	Copies tcnative from the dotcms image (no build of its own)
15-detect-fips-and-set-ssl-engine.sh	Comment updated; FIPS guard kept as defense-in-depth
.sdkmanrc	Bumped to canonical SDKMAN id 25.0.4+1-ms
maven-job action, deployment-phase, legacy-release, java-base workflows	Convert +→- where the SDKMAN id becomes a docker tag (docker tags cannot contain +)
parent/pom.xml	runtime.docker.sdkman.java.version defaults to docker-tag-safe 25.0.4-1-ms (maven cannot transform the .sdkmanrc-loaded property)

Deployment note

The java-base image with tcnative is already pushed as dotcms/java-base:25.0.4-1-ms (built via cicd_manual_build-java-base.yml), so downstream builds resolve immediately.

Validation

• just build (./mvnw -DskipTests clean install): BUILD SUCCESS, including the maven-driven docker image build
• Resulting image (dotcms/dotcms-test:1.0.0-SNAPSHOT): tcnative 1.3.8 present from java-base, no distro libtcnative-1, LD_LIBRARY_PATH set, Java 25.0.4.1
• Loaded through Tomcat 9.0.120's own tomcat-jni.jar (what AprLifecycleListener does at startup):

  Tomcat JNI loaded: tcnative 1.3.8 / APR 1.7.2 / OpenSSL 3.0.13 30 Jan 2024
  

• java-base built end-to-end locally (multi-arch safe: JDK path resolved via SDKMAN, not hardcoded arch); jlink'd JRE loads the library via LD_LIBRARY_PATH
• All touched workflow/action YAML parses cleanly; +→- substitution verified for both +-containing and plain versions

[claude]

Claude finished @wezell's task in 2m 11s —— View job

---

Code Review

I reviewed the diff against origin/main (docker/CI/tcnative changes — the DataSourceStrategyProvider work referenced in older review threads is no longer part of this branch's diff).

• Gather context (full diff, downstream Dockerfiles, CI flows)
• Trace the +→- docker-tag conversion end-to-end
• Verify tcnative build/copy + runtime deps across images
• Recheck prior findings still in the diff

I traced the tag flow: .sdkmanrc (25.0.4+1-ms) → CI converts +→- for the tag while passing the raw + id to sdk install → FROM dotcms/java-base:${SDKMAN_JAVA_VERSION} in both dotCMS/src/main/docker/original/Dockerfile:7 (- form, correct) and --build-arg at maven-job/action.yml:395. That's internally consistent: the tag is sanitized everywhere it lands as a docker tag, and the raw id only feeds sdk install java. tcnative is built once in java-base (before the SDKMAN/JDK cleanup, so JNI headers are present), then COPY'd into the runtime and dev-env images, both of which install libapr1 + openssl (pulls libssl3) and are Ubuntu 24.04 — ABI-matched to where the .so was built. LD_LIBRARY_PATH / -Djava.library.path wiring looks correct.

Existing

• 🟡 Medium: dotCMS/src/main/resources/container/tomcat9/conf/server.xml:133 — SSLProtocol="${CMS_SSL_PROTOCOLS:-TLSv1.3}" changes the direct connector's default from Tomcat's TLSv1.2+TLSv1.3 to TLS 1.3 only, so TLS 1.2-only clients hitting port 8443 directly are rejected unless an operator sets CMS_SSL_PROTOCOLS. The author has stated this is intentional secure-by-default hardening (overridable via CMS_SSL_PROTOCOLS), and it's documented in the adjacent comment — non-blocking, flagging only so the behavior change is a conscious call. Most deployments terminate TLS at a proxy, which limits blast radius.

Resolved

• ✅ docker/java-base/Dockerfile:61 — tcnative tarball now falls back to archive.apache.org when downloads.apache.org prunes the superseded release; SHA-512 pin still enforced on whichever tarball is fetched.
• ✅ dotCMS/src/main/java/com/dotmarketing/db/DataSourceStrategyProvider.java — no longer part of this branch's diff vs origin/main; prior datasource-precedence findings don't apply to the current change set.

Nothing blocking in the docker/CI changes — the tag sanitization, tcnative build placement, dependency purges (libssl-dev/libpq-dev removed while runtime libssl3/libapr1 are retained), and library-path wiring all check out. The one item worth a conscious sign-off is the TLS 1.3-only default above.

· issue-34067-fix-tcnative-apr-openssl3

[dotCMS-Machine-User]

✅ dotbot review: all reviewer models (meta/muse-spark-1.3, ~z-ai/glm-latest) agree — patch is correct.

_{approved automatically by dotbot}

[github-actions]

🐳 PR Docker test image

Latest build for commit b3219fa pushed to dotcms/dotcms-test:

docker pull dotcms/dotcms-test:pr-37399-issue-34067-fix-tcnative-apr-openssl3
docker pull dotcms/dotcms-test:pr-37399-issue-34067-fix-tcnative-apr-openssl3_b3219fa

[dotCMS-Machine-User]

✅ dotbot review: all reviewer models (meta/muse-spark-1.3, ~z-ai/glm-latest) agree — patch is correct.

_{approved automatically by dotbot}

[dotCMS-Machine-User]

✅ dotbot review: all reviewer models (meta/muse-spark-1.3, ~z-ai/glm-latest) agree — patch is correct.

_{approved automatically by dotbot}

[github-actions]

dotbot code review:

• Reviewer: meta/muse-spark-1.3 (medium)
• Overall: patch is correct
• New findings this run: 0
• Prior unresolved dotbot findings still relevant: 0
• Active findings total: 0

Replaces distro libtcnative-1 1.2.35 with source-built Apache tcnative 1.3.8 and propagates library path consistently across images; tag sanitization and TLS default are intentional and documented with no blocking defect found.

Tip: comment with "/dotbot address comments" to attempt automated fixes for unresolved review threads.

_{reviewed by dotbot · meta/muse-spark-1.3 · medium}

[github-actions]

dotbot code review:

• Reviewer: ~z-ai/glm-latest (medium)
• Overall: patch is correct
• New findings this run: 0
• Prior unresolved dotbot findings still relevant: 0
• Active findings total: 0

The tcnative 1.3.8 source build is SHA-512 pinned with an archive.apache.org fallback, and the library is propagated consistently (COPY + LD_LIBRARY_PATH + java.library.path) across the java-base, dotcms runtime, and dev-env images. The '+'→'-' docker-tag sanitization is applied consistently in all four CI paths and matches the parent/pom.xml default. Prior findings about the tarball URL, the pom literal, the TLS default, and the datasource strategy precedence were either fixed or explicitly confirmed intentional by the author, so no qualifying new findings remain.

Tip: comment with "/dotbot address comments" to attempt automated fixes for unresolved review threads.

_{reviewed by dotbot · ~z-ai/glm-latest · medium}

[dotCMS-Machine-User]

✅ dotbot review: all reviewer models (meta/muse-spark-1.3, ~z-ai/glm-latest) agree — patch is correct.

_{approved automatically by dotbot}