AlmaLinux FIPS Mode: Architecture, Trust Boundaries, and Operational Checks

The compliance problem is a boundary problem

Enabling FIPS mode on AlmaLinux is often treated as a package installation task. In practice, it is an architectural change: the system moves from a general-purpose cryptographic stack to one where only validated algorithms may cross the kernel and user-space boundary. Applications that embed their own cryptography, link against external OpenSSL builds, or rely on legacy hashing can fail after the switch. The useful takeaway is to scope the FIPS boundary before enabling it, because retrofitting a running system requires rebuilding the initramfs and may cause downtime.

Requirements and the smallest suitable design

The smallest suitable design is a single AlmaLinux host that uses only the distribution-supplied cryptographic libraries and kernel modules. It requires the almalinux-release package, the fips-mode-setup utility, and the openssl-fips and dracut-fips packages. After installation, the initial RAM filesystem must be rebuilt with Dracut so the kernel loads the FIPS-validated cryptographic modules early in boot.

Run the following as root or with sudo on the target AlmaLinux host:

dnf install openssl-fips dracut-fips
fips-mode-setup --enable
dracut -f

The fips-mode-setup --enable command sets the bootloader kernel argument and prepares the system for the next boot. The dracut -f command forces a rebuild of the current initramfs. Verify that the initramfs filename matches your running kernel before rebooting.

This design deliberately excludes external OpenSSL libraries, statically linked crypto in containers, and third-party modules that implement their own algorithms. Any component outside the AlmaLinux-supplied boundary is outside the validation scope.

Trust and data boundaries

FIPS mode on AlmaLinux defines two enforcement points. The first is the kernel cryptographic API, where validated kernel modules gate algorithm access. The second is the user-space OpenSSL library linked against the FIPS Object Module. Data crossing either boundary must use FIPS-approved algorithms. Calls that request non-approved algorithms are blocked or logged, depending on the module and policy.

The boundary is only as strong as the weakest linked library. If an application loads an external libssl or bundles its own cryptographic code, those calls bypass the AlmaLinux validation entirely. The following table summarizes what falls inside and outside the validated boundary.

Component	Inside FIPS boundary?	Notes
Kernel crypto API modules	Yes	Supplied and validated with AlmaLinux
System OpenSSL (openssl-fips)	Yes	Linked against the FIPS Object Module
External OpenSSL builds	No	Bypass AlmaLinux validation unless separately verified
Container-bundled crypto libraries	No	Outside host validation scope
Third-party kernel modules	No	Require independent FIPS validation

A common architecture mistake is assuming that mounting the host's cryptographic device nodes into a container brings the container inside the boundary. It does not. The container's user-space cryptographic calls still traverse its own libraries, which are not covered by the host's validation.

Operational checks

Confirm kernel enforcement

After reboot, check that the kernel reports FIPS mode. Any user can read this file:

cat /proc/sys/crypto/fips_enabled

Expected check: the file contains 1. If it contains 0, the kernel argument was not applied or the initramfs was not rebuilt correctly.

Confirm initramfs and user-space linkage

Verify that the initramfs includes the FIPS kernel modules. This requires the lsinitrd tool, which is typically available after installing dracut:

lsinitrd /boot/initramfs-$(uname -r).img | grep fips

Expected check: output lists FIPS-related modules. An empty result suggests the initramfs predates the change or the rebuild failed.

Check the setup utility and OpenSSL linkage:

fips-mode-setup --check
openssl version -a

Expected check: fips-mode-setup --check reports the system is in FIPS mode, and openssl version -a shows the library is built against the FIPS Object Module. If SELinux is enabled, confirm it remains in enforcing mode, because permissive mode can mask access failures that would otherwise appear during FIPS enforcement.

Test algorithm rejection

A conservative functional test is to attempt a cryptographic operation with a non-approved algorithm and confirm it is rejected. For example, a small test program using MD5 in a security context should fail rather than silently compute a digest. This confirms enforcement is active, but it is not a substitute for application-level testing.

Failure modes

If the FIPS module fails to load during boot, the system may drop into emergency mode rather than starting normally. Applications that request non-FIPS algorithms can receive EPERM errors, and dependent services may fail to start. Containers or custom applications that rely on non-approved algorithms will break without an obvious error unless you test them beforehand.

Because these failures appear at the cryptographic boundary, they can look like application bugs. Log inspection and the checks above help distinguish a missing kernel module from an application requesting a blocked algorithm.

Conditions that would change the design

• Major release upgrade: A new AlmaLinux major version may change package names, validation scope, or drop FIPS support. Re-validate the design before migrating.
• Validation status change: The OpenSSL FIPS Object Module and kernel crypto API are validated under a specific FIPS 140-2 or successor certificate. If that validation lapses or moves to a new module version, the trust boundary changes.
• External library requirement: If a workload requires an external OpenSSL build or a third-party cryptographic library, the minimal design no longer holds. You would need to either replace the library with a validated alternative or accept that part of the stack is outside the AlmaLinux FIPS boundary.
• Performance policy: A decision to disable FIPS mode for performance reasons changes the compliance posture and requires re-testing every application that was adapted to the restricted algorithm set.

Limitations and practical verification

FIPS validation applies only to the cryptographic modules supplied with AlmaLinux. Using external OpenSSL libraries bypasses the validation unless those libraries are also FIPS-verified. Third-party application libraries that implement their own cryptography are similarly outside the boundary.

Enabling FIPS mode on an already-running system is not a live toggle. It requires rebuilding the initramfs and rebooting, which means downtime. Plan the change during a maintenance window.

To verify the result, reboot the host and confirm /proc/sys/crypto/fips_enabled is 1, then run a representative application workload. If the application functions and the operational checks pass, the minimal design is intact. If it fails, inspect whether the failure comes from a blocked algorithm or from a component outside the AlmaLinux-supplied boundary.