Skip to content

FIPS compliance

Palo Alto Networks Kubernetes components are standard Go binaries that rely on the Go standard library for cryptography. Since the Go standard library is not FIPS-validated, we also offer FIPS-compliant versions of these components.

This topic explains how Palo Alto Networks builds FIPS-compliant components, how to confirm that a component is a FIPS build, and how to avoid non-compliant cryptography.

FIPS cryptographic modules by version

FIPS versions use upstream Go's native FIPS 140-3 support, which embeds the Go Cryptographic Module directly in each binary and carries Certificate #5247 (FIPS 140-3, Level 1). Because the module ships inside the binary, FIPS compliance doesn't depend on the host, the base image, or an external library such as OpenSSL.

Earlier FIPS builds used Microsoft's fork of Go to link against OpenSSL, which required a Red Hat UBI base image running in FIPS mode. Palo Alto Networks still supports these builds.

Deprecation of Certificate #4642

This certificate will be sunset on 21 September 2026. If you run components that rely on it, plan to upgrade to a release built with the Go Cryptographic Module before then.

Each Palo Alto Networks FIPS build uses one of the following cryptographic modules:

Module Certificate Standard
Go Cryptographic Module v1.0.0 Certificate #5247 FIPS 140-3
RHEL 8 OpenSSL, via Microsoft Go Certificate #4642 FIPS 140-2

Some very old FIPS builds used the BoringSSL module (Certificate #3678); none of those releases are supported today, so upgrade to a newer version. For more information on the OpenSSL module, see Red Hat's FIPS compliance page.

FIPS module by component

The following table shows which cryptographic module each component's FIPS builds use, by version.

Component Microsoft Go / OpenSSL 4642 Go Cryptographic Module 5247
cert-manager 1.12 v1.12.7 to v1.12.17 N/A
cert-manager 1.13 v1.13.3 to v1.13.6 N/A
cert-manager 1.14 and later v1.14.0 to v1.21.1 Forthcoming releases
CSI Driver v0.7.0 to v0.16.0 Forthcoming releases
CSI Driver for SPIFFE v0.4.1 to v0.15.0 Forthcoming releases
Distributed Issuer v1.10.0 to v1.12.0 Forthcoming releases
Enterprise Issuer for CyberArk Certificate Manager v0.10.1 to v0.22.0 Forthcoming releases
Istio CSR v0.7.1 to v0.17.0 Forthcoming releases
Trust Manager v0.7.1 to v0.22.1 Forthcoming releases
OpenShift Routes for cert-manager N/A Forthcoming releases

Confirming FIPS compliance

Since the cryptographic module is compiled into each binary, Palo Alto Networks FIPS components are FIPS-compliant regardless of the host or base image. They do not require the underlying platform to run in FIPS mode, and they do not panic when run on a non-FIPS host.

There are two ways to confirm that a component is a FIPS build.

Check the compliance flag

All Palo Alto Networks FIPS binaries for these Kubernetes components include a hidden --venafi-fips-enabled flag. Run the binary or container with this flag as its only argument:

<binary> --venafi-fips-enabled

The exit code is the reliable check: 0 means FIPS mode is on, non-zero means it isn't. The command also prints Venafi FIPS: true or false to standard error (redirect with 2>&1 to read it).

A true result confirms FIPS mode is on but not which module provides it: both the validated module (v1.0.0) and a newer, unvalidated one report true. To confirm the validated module, use the next check.

Check the module recorded in the binary

FIPS builds are compiled with the Go Cryptographic Module, which is recorded in the binary's build information:

go version -m <binary> | grep GOFIPS140

Non-compliant cryptography

A FIPS-validated cryptographic module is not enough to be FIPS-compliant at runtime: you must also use only FIPS-approved algorithms. Some Palo Alto Networks FIPS-compliant components can use non-compliant algorithms if requested.

Whether a given algorithm is approved depends on the cryptographic module the component was built with, as described in FIPS cryptographic modules by version. The following guidance applies to builds that use the Go Cryptographic Module, Certificate #5247. To maintain FIPS compliance, avoid these algorithms.

Certificate algorithms

Distributed Issuer can issue certificates using the following algorithms:

Algorithm Compliance consideration
ECDSA (P-256, P-384, P-521) Curve compliance varies; verify each curve before use.
RSA Key-size compliance varies; verify key size before use.
Ed25519 Approved under the Go Cryptographic Module. It was outside the validated boundary in earlier Microsoft Go / OpenSSL builds; if you excluded it from your issuance policies solely to maintain FIPS compliance, you no longer need to for module builds.

Keystore output formats

cert-manager and Trust Manager can write to the following keystore formats:

Format Component Why it may be non-compliant Compliant approach
PKCS#12 cert-manager Default profiles may use RC2, and the library includes a custom PBKDF that may be non-compliant. Use a modern profile: Modern2023 (v1.14 and later) or Modern2026 (v1.21 and later). The LegacyDES and LegacyRC2 profiles are non-compliant. Confirm the profile you choose can be read by your consumers.
PKCS#12 Trust Manager Passwordless by default and uses the LegacyRC2 encoder, which may use RC2. The library also includes a custom PBKDF that may be non-compliant. Trust Manager does not support the Modern2026 profile, so its guidance differs from cert-manager. Choose a compliant profile that your consumers can read.
JKS cert-manager, Trust Manager May use the SHA-1 hash algorithm. Avoid where you need to maintain compliance.

PKCS#12 and JKS use these algorithms for backwards compatibility, not security. For more information, see the open-source documentation.

FIPS-only TLS

Palo Alto Networks FIPS-compliant binaries enforce FIPS-compliant TLS at runtime. In FIPS mode, TLS is restricted to FIPS-approved settings: TLS 1.0 and 1.1 are refused, and non-approved cipher suites — such as ChaCha20-Poly1305 and CBC suites — are unavailable. Only TLS 1.2 and 1.3 with approved cipher suites are allowed.

FIPS builds enable this by shipping with GODEBUG=fips140=on.

Warning

Do not set GODEBUG=fips140=only. Unlike on, the stricter only mode does not degrade gracefully: it causes the process to panic when non-approved cryptography is used — for example, the SHA-1 that Trust Manager uses when writing JKS or PKCS#12 files — which can take a component down. Palo Alto Networks FIPS builds are not supported with fips140=only.

You can turn FIPS mode off by setting GODEBUG=fips140=off, which downgrades a FIPS image to standard cryptography. This is a deliberate operator action and makes the component non-compliant.

FIPS container images

Palo Alto Networks provides signed FIPS-compliant container images for its Kubernetes components. Images are single-arch (linux/amd64 only) and their names end with -fips.

Image names contain the -fips suffix, but some drop the cert-manager- prefix, for example csi-driver-fips.

Install a FIPS build

To install a component's FIPS build, use the FIPS variant of its Helm chart. For example, to install Trust Manager:

VERSION=v0.24.0
helm upgrade demo oci://registry.ngts.paloaltonetworks.com/charts/trust-manager-fips \
    --install \
    --wait \
    --create-namespace \
    --namespace venafi \
    --set global.imagePullSecret[0].name="ngts-image-pull-secret" \
    --version $VERSION

To confirm the correct build is running, check that the pod's container image has the -fips suffix.