Why Many “FIPS-Compliant” Linux Systems Fail FIPS 140-3

Go straight to an AI summary of this blog post instead

Key Takeaways

FIPS compliance depends on the full OS environment, not just installing a cryptographic library.
“FIPS containers” aren’t compliant unless the host kernel is running in validated FIPS mode.
Bolt-on crypto modules often create instability and complexity compared to native OS cryptography.

Achieving FIPS compliance in Linux environments is often more complicated than it looks. Many organizations rely on third-party cryptographic modules or container images that claim FIPS support, but these setups may not actually meet the requirements of the FIPS 140-3 validation program or deliver true FIPS 140-3 compliance.

The difference between native FIPS implementations and bolt-on cryptography can mean the difference between passing a compliance audit – or failing it.

Native FIPS vs Drop-In Crypto Modules

We recently spoke with a customer running CentOS 7 who needed validated cryptography to support several federal customers and meet strict FedRAMP cryptography requirements. Because CentOS itself wasn’t FIPS-validated, they relied on third-party OpenSSL and Java FIPS providers.

They’ve since migrated to TuxCare’s FIPS-validated AlmaLinux 9 ESU (a FIPS validated Linux environment) and were delighted to find that – due to the way cryptography is configured system-wide from the kernel up – they no longer needed to purchase additional software to meet the requirements of FIPS 140-3, as the OS does it for them. Switching to ESU, which costs just $159/year, instead of software that can cost from $100/month to $25,000/year is a no-brainer!

They also noted that their MySQL database runs more reliably due to this tight integration and being linked to system libraries like OpenSSL rather than bolted-on software not specifically designed for the OS. In fact, they had previously seen server crashes when attempting to run in FIPS mode. Switching to ESU made their FedRAMP deployment possible.

Several customers have mentioned to us that using software built into the AlmaLinux OS rather than third-party forks has given them better performance and made migrations from older operating systems easier.

TuxCare’s AlmaLinux 9 ESU’s FIPS certificates are based on the FIPS 140-3 standard, and not the earlier 140-2 standard that most of this bolt-on software uses. With FIPS 140-2 certificates moving to the historical list, they are increasingly no longer accepted for new federal procurement. With TuxCare’s solution, this becomes a non-issue – your infrastructure is future-proofed with FIPS 140-3 validated cryptography.

Containers mythology

We’ve also met with people who have been sold “FIPS container images” – often marketed as FIPS containers – which aren’t even running in an Operating Environment (OE) that has been tested by an accredited Cryptographic & Security Testing Lab (CSTL) and as such are not listed on any FIPS certificate or signed off by NIST – they aren’t valid and may not even work.

Because containers inherit the host OS kernel, they must run on a host with a FIPS-validated kernel that is operating in FIPS mode. This environment exposes the /proc/sys/crypto/fips_{enabled,name,version} indicators that libraries and applications use to detect and enforce FIPS mode. If your host OS isn’t running in FIPS mode, then your containers aren’t either.

This is particularly important with containers that run VPN’s such as IPSEC or OpenVPN as these protocols use the kernel cryptographic API, so if you’re using the wrong host kernel, your VPN is non-compliant and won’t be allowed to connect to DoD networks.

Running OpenSSL 3.1.2 in a container on an Ubuntu 24.04 host (with FIPS enabled or not) is not a valid environment – you won’t pass a FedRAMP audit and you won’t be able to sell your solution to the US or Canadian Governments.

How AlmaLinux Enforces FIPS System-Wide

As the kernel and various libraries and system components (GnuTLS, Libgcrypt, NSS, NSPR, OpenSSL, libkcapi, nettle….) of AlmaLinux 9 ESU have been FIPS-validated, the operating system provides the validated environment rather than specific software. This is one of the advantages of running a FIPS validated Linux distribution, where the cryptographic environment is built into the OS itself.

For example, CentOS Linux was never FIPS-validated, so people resorted to trying to achieve some form of FIPS “compliance” by using bolt-on modules and complicated configuration and software tweaks which generally just ended up making the system unstable.

With AlmaLinux’s system-wide-crypto-policies, cryptography is centrally configured in one place. This avoids the need to configure individual services or applications separately. It’s as easy as installing using the fips=1 kernel parameter or running fips-mode-setup –enable. With a properly configured FIPS-enabled kernel, you can have OpenSSH, kerberos, bind9 and so on automatically configured in an approved way. For more information see the files under /usr/share/crypto-policies/FIPS/.

The proof is in the pudding

As part of our internal testing of our FIPS modules (a requirement of us adding Rocky Linux 9.6 as a vendor-approved OE to our FIPS certificates) which is traditionally written in C, we decided to test some of TuxCare’s Endless Lifecycle Support for Runtimes products against our FIPS modules too. We created a number of interpreted language scripts that would prove that the OS and its centralized cryptography allowed such software to run in a FIPS-approved manner, restricting the algorithms and protocols available to applications to those approved by the NIST program, largely without having to modify the programs themselves.

To validate how well real applications behave in this environment and maintain FIPS 140-3 compliance, we tested several common runtimes used in enterprise deployments, which are detailed below. In addition, we can provide test scripts and technical support to customers upon request.

.NET

We found that in some cases .NET’s built-in System.Security.Cryptography doesn’t fully enforce FIPS 140-3 compliance on Linux hosts, so would recommend switching to calling OpenSSL natively.

Java

OpenJDK has a number of crypto providers, each with its own weaknesses when it comes to FIPS compliance. We recommend SunPKCS11-NSS-FIPS on Enterprise Linux distributions but even then you must make sure to check FIPS indicators which NSS uses rather than simply blocking and returning an error.

Python

Python’s cryptography module uses native OpenSSL library calls, so works out-of-the-box.

PHP

PHP also uses the system OpenSSL but has some peculiarities you have to deal with – for example it lists more elliptic curves as supported than OpenSSL will return in FIPS mode, largely as “supported” means PHP is aware of them, rather than being allowed to use them. In general you should specifically name the ciphers and digests you want to use and know are FIPS-compliant.

Node.js

The Node.js crypto package again links against the system OpenSSL and makes library calls like EVP_PKEY_keygen() so works very well.

Final Thoughts

FIPS compliance isn’t just about installing a cryptographic library. It depends on the entire operating environment – from the kernel to the runtime libraries your applications rely on.

Native, system-level FIPS validation eliminates the complexity and instability that often comes with bolt-on cryptography.

If your environment depends on FIPS for government contracts or compliance frameworks like FedRAMP, the safest approach is to start with a FIPS validated Linux operating system that provides validated cryptography from the ground up and supports modern FIPS 140-3 compliance requirements.

For more information about FIPS and Extended Security Updates, see our FIPS for AlmaLinux site.

Summary