jdk-openssl-fips

packaged by Chainguard

Chainguard Container for jdk-openssl-fips

Minimal Java JDK image whose FIPS cryptography comes from the OpenSSL-backed Jipher JCE provider. Used for compiling Java applications.

Chainguard Containers are regularly-updated, secure-by-default container images.

Download this Container Image

For those with access, this container image is available on cgr.dev:

docker pull cgr.dev/ORGANIZATION/jdk-openssl-fips:latest

Be sure to replace the ORGANIZATION placeholder with the name used for your organization's private repository within the Chainguard Registry.

jdk-openssl-fips is a variant of cgr.dev/ORGANIZATION/jdk that gets its FIPS cryptography from Jipher, an OpenSSL-backed JCE provider, instead of from BouncyCastle FIPS. Jipher is compiled into the JDK (jlinked) and delegates cryptography to the system Chainguard FIPS Provider for OpenSSL.

Getting started

Unlike BouncyCastle FIPS based jdk-fips, jdk-openssl-fips needs no FIPS-specific configuration: the hardened Jipher provider is the JDK default, so there is no module path, no classpath, and no environment variable to set. Build and run Java code exactly as you would with the non-FIPS cgr.dev/ORGANIZATION/jdk image.

FROM cgr.dev/ORGANIZATION/jdk-openssl-fips:26

WORKDIR /src
COPY MyClass.java .

RUN javac MyClass.java && \
    jar cvf my-app.jar *.class

java -jar works as-is here, whereas on jdk-fips it needs an explicit --module-path for the BouncyCastle libraries.

Comparison with stock OpenJDK and BouncyCastle FIPS

The following tables enumerate every JCA service, algorithm alias, and TLS default that each image actually installs, on the same Java 26 base:

Marker meanings:

• ✅ Available.
• ⚠️ Available, but legacy, deprecated, or not FIPS-approved for that use — a hazard left reachable by default.
• 🚫 Not installed. Requesting it throws NoSuchAlgorithmException.
• ⏳ Not available yet, expected in a future release.

At a glance

All three images share the same truststore: the java-cacerts package installs a JKS cacerts at /etc/ssl/certs/java/cacerts, extracted from the system truststore, and all three symlink $JAVA_HOME/lib/security/cacerts at it.

The keystore difference is the one most likely to show up in practice. Stock OpenJDK writes PKCS#12 keystores MAC'd with HmacPBESHA256, which is the legacy PKCS#12 v1 KDF and not FIPS-approved. jdk-openssl-fips sets keystore.pkcs12.macAlgorithm=PBEWithHmacSHA256, which selects PBMAC1 — Mac.HmacSHA256 over SecretKeyFactory.PBKDF2WithHmacSHA256, both from Jipher. So keystores stay in the standard, interoperable PKCS#12 container, unlike jdk-fips, which needs them converted to BCFKS.

CVE counts are point-in-time; the per-tag view in the Chainguard Containers Directory is authoritative. The durable difference is revalidation: a fix to a validated module normally invalidates its certificate, so the BC-FJA jars carry their known issues, whereas the Chainguard OpenSSL FIPS provider is revalidated as it is patched.

The BC-FIPS image also installs the OpenSSL FIPS provider for its native, non-Java consumers; the FIPS validation row in the preceding table covers its Java cryptography.

Installed providers

Service counts are the algorithms each provider registers, in provider precedence order. The first provider that offers an algorithm is the one that serves an unqualified getInstance() call.

The two FIPS stacks take opposite approaches to the JDK's own crypto providers.

The BC-FIPS stack unregisters rather than removes them: SUN, SunRsaSign, SunEC, SunJCE, and SunJSSE are absent from the default provider list, but the implementations are still in the runtime, so an application can put any of them back using, for example, Security.addProvider(), Security.insertProviderAt(), or its own java.security overrides. That is what the ⚠️ marks: nothing in the image prevents a non-validated RSA, EC, or AES implementation from being reinstated, ahead of BouncyCastle if inserted at position 1, which takes the application outside the FIPS boundary.

The Chainguard OpenSSL stack closes that door twice over. The Sun providers are still on the list, but register no algorithms at all — the image empties out SunRsaSign, SunEC, and SunJCE, so re-registering one gains nothing. SUN keeps only PKI plumbing (X.509, PKIX, keystores, and JAAS config) plus the MD5 and SHA-1 digests, and SunJSSE keeps the TLS engine, which calls into Jipher for every primitive.

Separately, the image restricts provider installation to providers whose class comes from a module baked into the runtime image: the runtime refuses an application-supplied provider — a class-path jar, an application module, or a class from a custom loader — with a SecurityException, at both the Security.insertProviderAt() path and the configured security.provider.N path. The check is on where the class came from, not what it is called, so shading or renaming cannot sidestep it.

Digests and MACs

Raw MD5 and SHA-1 digests stay reachable in all three for legacy, non-security uses such as checksums, which FIPS 140-3 I.G. 2.4.A permits. For more information, refer to non-approved algorithms. What matters is their use in HMAC and signatures, and there the three diverge: both FIPS images drop HMAC-MD5 and MD5 signatures, and jdk-openssl-fips goes further by turning SHA-1 digest signatures off entirely, alongside 3DES and DSA. Jipher still registers a SHA1withECDSA service name, but disables the capability behind it, so it refuses the signature. Stock OpenJDK and jdk-openssl-fips separately disable SHA-1 handshake signatures in TLS, via the rsa_pkcs1_sha1, ecdsa_sha1, and dsa_sha1 usage HandshakeSignature entries in jdk.tls.disabledAlgorithms; the BC-FIPS list carries no equivalent entry.

Symmetric ciphers

Public-key algorithms

Cipher.getInstance("RSA") and "RSA/ECB/PKCS1Padding" are the most likely sources of breakage when moving an application from stock or jdk-fips to jdk-openssl-fips: Jipher registers only the RSA/ECB/OAEP* transformations, because PKCS#1 v1.5 key transport is not an approved key-establishment scheme. Signing with PKCS#1 v1.5 (SHA256withRSA) is unaffected and works everywhere.

Key derivation, random, and keystores

Two of these are compatibility wins over jdk-fips. PKCS#12 keystores load normally — on the BC-FIPS stack no provider registers KeyStore.PKCS12, so applications have to convert their keystores to BCFKS. And the javax.crypto.KDF API works, which BC-FIPS does not implement at all.

TLS defaults

Supported is what the stack can negotiate if an application asks for it; default is what the stack enables without any configuration. The profile rows say whether you can configure the stack to meet that profile; the last two rows say whether anything below it is still reachable. Deprecated covers TLSv1.1, TLSv1, and DTLSv1.0 (RFC 8996); obsolete covers SSLv3 and SSLv2Hello.

Jipher's TLS surface is deliberately the narrowest of the three: seven cipher suites, all AEAD; ECDHE over NIST prime curves only; and every SHA-1, CBC, static-RSA, plain-ECDH, and finite-field-DHE path removed rather than merely deprioritized. Its jdk.tls.disabledAlgorithms extends the stock list with DHE, AES_128_CBC, AES_256_CBC, ChaCha20-Poly1305, ffdhe2048–ffdhe8192, x25519, x448, ECDH, and TLS_RSA_*. That is a stricter posture than jdk-fips, which still enables CBC suites by default. On the BC-FIPS stack the whole DTLS engine is missing rather than disabled: asking for it fails with NoSuchAlgorithmException: DTLS SSLContext not available.

Checking that the configuration loads correctly

jdk-openssl-fips ships a hardening validator that reports the providers, services, and algorithm aliases, along with the default TLS protocols, key exchange groups, cipher suites, and signature schemes, that the image should expose. It exits non-zero if any of them differ:

docker run --rm --entrypoint java cgr.dev/ORGANIZATION/jdk-openssl-fips:26 \
  -jar /usr/lib/jvm/default-jvm/lib/jipher/jipher-hardening-validator.jar

Pass --expected to print the allow lists the validator enforces.

What are Chainguard Containers?

Chainguard's free tier of Starter container images are built with Wolfi, our minimal Linux undistro.

All other Chainguard Containers are built with Chainguard OS, Chainguard's minimal Linux operating system designed to produce container images that meet the requirements of a more secure software supply chain.

The main features of Chainguard Containers include:

• Minimal design, without unnecessary software bloat
• Daily builds to ensure container images are up-to-date with available security patches
• High quality build-time SBOMs attesting to the provenance of all artifacts within the image
• Verifiable signatures provided by Sigstore
• Reproducible builds with Cosign and apko (read more about reproducibility)

For cases where you need container images with shells and package managers to build or debug, most Chainguard Containers come paired with a development, or -dev, variant.

In all other cases, including Chainguard Containers tagged as :latest or with a specific version number, the container images include only an open-source application and its runtime dependencies. These minimal container images typically do not contain a shell or package manager.

Although the -dev container image variants have similar security features as their more minimal versions, they include additional software that is typically not necessary in production environments. We recommend using multi-stage builds to copy artifacts from the -dev variant into a more minimal production image.

Need additional packages?

To improve security, Chainguard Containers include only essential dependencies. Need more packages? Chainguard customers can use Custom Assembly to add packages, either through the Console, chainctl, or API.

To use Custom Assembly in the Chainguard Console: navigate to the image you'd like to customize in your Organization's list of images, and click on the Customize image button at the top of the page.

Learn More

Refer to our Chainguard Containers documentation on Chainguard Academy. Chainguard also offers VMs and Libraries — contact us for access.

Trademarks

This software listing is packaged by Chainguard. The trademarks set forth in this offering are owned by their respective companies, and use of them does not imply any affiliation, sponsorship, or endorsement by such companies.