SupportConsoleDevelopersStart a trialContact

Chapter 1. Switching RHEL to FIPS mode

To enable the cryptographic module self-checks mandated by the Federal Information Processing Standard (FIPS) 140-3, you must operate RHEL 10 in FIPS mode. The only correct way to switch the system to FIPS mode is to enable it during the RHEL installation.

Switching a system to FIPS mode after installation is not supported in Red Hat Enterprise Linux 10. In particular, setting the FIPS system-wide cryptographic policy is not sufficient to enable FIPS mode and guarantee compliance with the FIPS 140 standard. The fips-mode-setup tool, which used the FIPS policy for enabling FIPS mode, has been removed from RHEL.

To turn off FIPS mode, you must reinstall the system without enabling FIPS mode during the installation process.

The Federal Information Processing Standard (FIPS) 140 is a government standard specifying cryptographic module security. FIPS mode enables required self-checks for compliance.

The FIPS Publication 140 is a series of computer security standards developed by the National Institute of Standards and Technology (NIST). It ensures the quality of cryptographic modules. The FIPS 140 standard ensures that cryptographic tools implement their algorithms correctly. Runtime cryptographic algorithms and integrity self-tests are some mechanisms that ensure a system uses compliant cryptography.

1.1.1. RHEL in FIPS mode
Copy link

To ensure that your RHEL system generates and uses all cryptographic keys only with FIPS-approved algorithms, you must switch RHEL to FIPS mode.

To enable FIPS mode, start the installation in FIPS mode. This avoids cryptographic key material regeneration and compliance reevaluation when converting deployed systems. Additionally, components that change their algorithm choices based on FIPS mode choose the correct algorithms. For example, LUKS disk encryption uses the PBKDF2 key derivation function (KDF) during installation in FIPS mode. Otherwise, it chooses the non-FIPS-compliant Argon2 KDF. Therefore, a non-FIPS installation with disk encryption is either not compliant or potentially unbootable when switched to FIPS mode after installation.

To operate a FIPS-compliant system, create all cryptographic key material in FIPS mode. Furthermore, the cryptographic key material must never leave the FIPS environment unless it is securely wrapped and never unwrapped in non-FIPS environments.

1.1.2. FIPS mode status
Copy link

The fips=1 boot option on the kernel command line determines whether FIPS mode is enabled. The system-wide cryptographic policy automatically follows this setting unless you explicitly set it by using the update-crypto-policies --set FIPS command. Systems with a separate partition for /boot additionally require a boot=UUID=<uuid-of-boot-disk> kernel command line argument. The installation program performs the required changes when started in FIPS mode.

Enforcement of restrictions required in FIPS mode depends on the contents of the /proc/sys/crypto/fips_enabled file. If the file contains 1, RHEL core cryptographic components switch to mode, in which they use only FIPS-approved implementations of cryptographic algorithms. If /proc/sys/crypto/fips_enabled contains 0, the cryptographic components do not enable their FIPS mode.

1.1.3. FIPS in crypto-policies
Copy link

The FIPS system-wide cryptographic policy helps configure higher-level restrictions. Communication protocols supporting cryptographic agility do not announce ciphers that the system refuses when selected. For example, the ChaCha20 algorithm is not FIPS-approved. The FIPS cryptographic policy ensures that TLS servers and clients do not announce the TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256 TLS cipher suite because any attempt to use it fails.

If you operate RHEL in FIPS mode and use an application providing its own FIPS-mode-related configuration options, ignore these options and the corresponding application guidance. The system running in FIPS mode and the system-wide cryptographic policies enforce only FIPS-compliant cryptography. For example, the Node.js --enable-fips and --force-fips options are not supported. Do not use these options. On RHEL, Node.js follows the system FIPS mode and uses FIPS-certified OpenSSL libraries provided by RHEL. Using these options causes Node.js to exit with an explanatory error message, regardless of whether the system is running in FIPS mode.

1.1.4. RHEL 10.0 OpenSSL FIPS indicators
Copy link

Because RHEL introduced OpenSSL FIPS indicators before the OpenSSL upstream did, and both designs differ, the indicators might change in a future minor version of RHEL 10. After the potential adoption of the upstream API, the RHEL 10.0 indicators might return an error message "unsupported" instead of a result. See the OpenSSL FIPS Indicators GitHub document for details.

Note

For the certification status of RHEL 10 cryptographic modules according to the FIPS 140-3 requirements, see the Product compliance Red Hat Customer Portal page. The requirements are defined by the National Institute of Standards and Technology (NIST) Cryptographic Module Validation Program (CMVP). Look for the FIPS - Federal Information Processing Standards section.

1.2. Installing the system with FIPS mode enabled
Copy link

To enable the cryptographic module self-checks mandated by the Federal Information Processing Standard (FIPS) 140, enable FIPS mode during the Red Hat Enterprise Linux system installation.

Warning

After you complete the setup of FIPS mode, you cannot disable FIPS mode without putting the system into an inconsistent state. If your scenario requires this change, the only correct way is a complete re-installation of the system.

Procedure

  1. Add the fips=1 option to the kernel command line at the start of the system installation when the Red Hat Enterprise Linux boot window opens and displays available boot options.

    1. On UEFI systems, press the e key, move the cursor to the end of the linuxefi kernel command line, and add fips=1 to the end of this line, for example: 

      linuxefi /images/pxeboot/vmlinuz inst.stage2=hd:LABEL=RHEL-10-0-BaseOS-x86_64 rd.live.\
check quiet fips=1

    2. On BIOS systems, press the Tab key, move the cursor to the end of the kernel command line, and add fips=1 to the end of this line, for example: 

      > vmlinuz initrd=initrd.img inst.stage2=hd:LABEL=RHEL-10-0-BaseOS-x86_64 rd.live.check quiet fips=1
  2. During the software selection stage, do not install any third-party software.
  3. After the installation, the system starts in FIPS mode automatically.

Verification

  • After the system starts, check that FIPS mode is enabled: 

    $ cat /proc/sys/crypto/fips_enabled
1

1.3. Enabling FIPS mode with RHEL image builder
Copy link

You can create a customized image and boot a FIPS-enabled RHEL image. Before you compose the image, you must change the value of the fips directive in your blueprint.

Prerequisites

  • You are logged in as the root user or a user who is a member of the weldr group.

Procedure

  1. Create a plain text file in the Tom’s Obvious, Minimal Language (TOML) format with the following content: 

    name = "system-fips-mode-enabled"
description = "blueprint with FIPS enabled"
version = "0.0.1"

[customizations]
fips = true

[[customizations.user]]
name = "admin"
password = "admin"
groups = ["users", "wheel"]

  2. Build the customized RHEL image: 

    # image-builder build image-type --blueprint blueprint-name

Verification

  1. Log in to the system image with the username and password that you configured in your blueprint.

  2. Check if FIPS mode is enabled: 

    $ cat /proc/sys/crypto/fips_enabled
1

You can create a disk image and enable FIPS mode when performing an Anaconda installation. You must add the fips=1 kernel argument when booting the disk image.

Prerequisites

  • You have Podman installed on your host machine.
  • You have virt-install installed on your host machine.
  • You have root access to run the bootc-image-builder tool, and run the containers in --privileged mode, to build the images.

Procedure

  1. Create a 01-fips.toml to configure FIPS enablement, for example: 

    # Enable FIPS
kargs = ["fips=1"]

  2. Create a Containerfile with the following instructions to enable the fips=1 kernel argument and adjust the cryptographic policies: 

    FROM quay.io/<namespace>/<image>:latest
# Enable fips=1 kernel argument: https://bootc-dev.github.io/bootc/building/kernel-arguments.html
COPY 01-fips.toml /usr/lib/bootc/kargs.d/
# Install and enable the FIPS crypto policy
RUN dnf install -y crypto-policies-scripts && update-crypto-policies --no-reload --set FIPS

  3. Before running the container, initialize the output folder. Use the -p argument to ensure that the command does not fail if the directory already exists: 

    $ mkdir -p ./output

  4. Create your bootc <image> compatible base disk image by using Containerfile in the current directory: 

    $ sudo podman run \
    --rm \
    -it \
    --privileged \
    --pull=newer \
    --security-opt label=type:unconfined_t \
    -v ./config.toml:/config.toml \
    -v ./output:/output \
    -v /var/lib/containers/storage:/var/lib/containers/storage \
    registry.redhat.io/rhel10/bootc-image-builder:latest \
    --type iso \
    quay.io/<namespace>/<image>:<tag>

  5. Enable FIPS mode during the system installation:

    1. When booting the RHEL Anaconda installer, on the installation screen, press the TAB key and add the fips=1 kernel argument. After the installation, the system starts in FIPS mode automatically.

Verification

  • After login in to the system, check that FIPS mode is enabled: 

    $ cat /proc/sys/crypto/fips_enabled
1
$ update-crypto-policies --show
FIPS

Additional resources

Review the RHEL applications that use cryptography that is not compliant with FIPS 140-3. To pass all relevant cryptographic certifications, such as FIPS 140-3, use libraries from the core cryptographic components set.

These libraries, except for libgcrypt, also follow the RHEL system-wide cryptographic policies.

See the RHEL core cryptographic components Red Hat Knowledgebase article for information about the core cryptographic components. It explains how they are selected, how they integrate with the operating system, and how they support hardware security modules and smart cards. It also describes how cryptographic certifications apply to them.

The following RHEL 10 applications use cryptography that is not compliant with FIPS 140-3:

Bacula
Implements the CRAM-MD5 authentication protocol.
Cyrus SASL
Uses the SCRAM-SHA-1 authentication method.
curl
Supports NTLM authentication which uses MD4 and MD5.
Dovecot
Uses SCRAM-SHA-1.
Emacs
Uses SCRAM-SHA-1.
FreeRADIUS
Uses MD5 and SHA-1 for authentication protocols.
Ghostscript
Custom cryptography implementation (MD5, RC4, SHA-2, AES) to encrypt and decrypt documents.
GnuPG
The package uses the libgcrypt module, which is not validated.
GRUB2
Supports legacy firmware protocols requiring SHA-1 and includes the libgcrypt library.
iPXE
Implements TLS stack.
Kerberos
Preserves support for SHA-1 (interoperability with Windows).
Lasso
The lasso_wsse_username_token_derive_key() key derivation function (KDF) uses SHA-1.
libgcrypt
The module is deprecated. It is no longer validated since RHEL 10.0.
MariaDB, MariaDB Connector
The mysql_native_password authentication plugin uses SHA-1.
MySQL
mysql_native_password uses SHA-1.
OpenIPMI
The RAKP-HMAC-MD5 authentication method is not approved for FIPS usage and does not work in FIPS mode.
Ovmf (UEFI firmware), Edk2, shim
Full cryptographic stack (an embedded copy of the OpenSSL library).
Perl
Uses HMAC, HMAC-SHA1, HMAC-MD5, SHA-1, and SHA-224.
Pidgin
Implements DES and RC4 ciphers.
Poppler
Can save PDFs with signatures, passwords, and encryption based on non-allowed algorithms if they are present in the original PDF (for example, MD5, RC4, and SHA-1).
PostgreSQL
Implements Blowfish, DES, and MD5. A KDF uses SHA-1.
QAT Engine
Uses a mix of hardware and software implementation of cryptographic primitives (RSA, EC, DH, AES, and others).
Ruby
Provides insecure MD5 and SHA-1 library functions.
Samba
Preserves support for RC4 and DES (interoperability with Windows).
Sequoia
Uses the deprecated OpenSSL API, which does not work in FIPS mode.
Syslinux
Firmware passwords use SHA-1.
SWTPM
Explicitly disables FIPS mode in its OpenSSL usage.
Unbound
DNS specification requires that DNSSEC resolvers use a SHA-1-based algorithm in DNSKEY records for validation.
Valgrind
AES, SHA hashes.[1]
zip
Custom cryptography implementation (insecure PKWARE encryption algorithm) to encrypt and decrypt archives by using a password.

[1] Re-implements in software hardware-offload operations, such as AES-NI or SHA-1 and SHA-2 on ARM.
Red Hat logoGithubRedditYoutubeTwitter

Learn

Try, buy, & sell

Communities

About Red Hat

We deliver hardened solutions that make it easier for enterprises to work across platforms and environments, from the core datacenter to the network edge.

Making open source more inclusive

Red Hat is committed to replacing problematic language in our code, documentation, and web properties. For more details, see the Red Hat Blog.

About Red Hat Documentation

We help Red Hat users innovate and achieve their goals with our products and services with content they can trust. Explore our recent updates.

Legal Notice

Theme

© 2026 Red HatBack to top