Enable FIPS Mode on SLES 15 and Verify the Boot State

When FIPS status is missing, separate the boot setting from compliance

A server can report that FIPS mode is off even when its owner has installed security updates or selected a hardened profile. On SUSE Linux Enterprise Server 15 SP7, SUSE’s documented method is to install the FIPS support needed for the system, run fips-mode-setup --enable, reboot, and confirm the state with fips-mode-setup --check. The setting changes system cryptographic policy and boot configuration; it does not, by itself, prove that a workload or the whole operating system meets a compliance requirement.

Illustrative example: Imagine a fictional operations team preparing one SLES 15 SP7 server for an internal service that requires FIPS-approved cryptography. The team has a maintenance window and console access, but it does not yet know whether a legacy client uses an incompatible algorithm. That is a reason to verify the exact requirement and test dependencies before changing the production host—not evidence of a real deployment or test.

1. Confirm the release and the requirement

First identify the service pack and architecture. The exact commands and packages may differ between SLES 15 service packs, so do not copy an SP7 procedure onto SP4, SP5, or SP6 without checking that release’s SUSE documentation.

cat /etc/os-release
uname -m

For the example server, the team records the installed SLES release, checks its change window, and confirms that it can recover through a console or approved remote management path if a reboot fails. FIPS can reject cryptographic algorithms or protocols that an application still expects. Schedule time to check the applications that use TLS, SSH, file sharing, Java, databases, or other cryptographic libraries.

Also clarify what the assessor actually requires. FIPS 140-3 validation applies to a cryptographic module in a defined configuration; enabling an operating-system mode is not the same thing as validating every module, application, or deployment. SUSE’s SLES 15 SP7 guide says that SP7 will not be submitted for NIST FIPS 140-3 certification. SUSE separately publishes information about validated modules and configurations. If a contract requires a particular validated module, confirm the exact module, version, operating environment, and certificate against SUSE’s certification material and the NIST CMVP certificate record before proceeding.

2. Prepare the supported FIPS components

SUSE recommends selecting the patterns-base-fips pattern for a new installation. If you are changing a running system, SUSE warns that additional adjustments may be needed, including regenerating keys and auditing the setup. Treat an existing host as a controlled change, not as a one-command certification.

Check whether the setup utility is present:

command -v fips-mode-setup
rpm -q crypto-policies-scripts

The crypto-policies-scripts package provides fips-mode-setup and may not be installed. If it is absent, install it from the system’s authorized SLES repositories:

sudo zypper install crypto-policies-scripts

If repository access, package availability, or the required FIPS packages are unclear, stop and use the support channel and certification guidance for your exact service pack. Do not substitute an old blog command or manually add a kernel parameter copied from a different SLES release. SUSE’s current SP7 instructions use the setup utility to apply the policy and configure the boot process.

3. Enable FIPS mode and reboot

Once the host is backed up according to local policy, dependencies have been reviewed, and the maintenance window is active, enable the mode:

sudo fips-mode-setup --enable

Review the utility’s output. SUSE documents that it sets the FIPS crypto policy and reports that a reboot is required. The reboot is part of the procedure because the initramfs and boot configuration must reflect the new mode. Do not treat the command returning successfully before reboot as proof that the running kernel is already operating in FIPS mode.

Reboot only when you have confirmed service impact and recovery access:

sudo systemctl reboot

For the fictional operations team, the application owner is present during the change window and can run the agreed smoke tests after the server returns. If the server is remote and no recovery path exists, first establish one or postpone the change. FIPS restrictions can expose unsupported cryptography at boot or when services start.

4. Verify the mode, then verify the workload

After the system has fully restarted, run SUSE’s status check:

sudo fips-mode-setup --check

For a successful SP7 configuration, SUSE documents output stating that FIPS mode is enabled, the initramfs FIPS module is enabled, and the current crypto policy is based on the FIPS policy. Compare the actual output with the documentation for your installed service pack; do not rely only on a configuration file or on the fact that the reboot completed.

You can also query the utility’s enablement status:

sudo fips-mode-setup --is-enabled

SUSE documents this as a status check with a nonzero result when FIPS is disabled or when the mode is inconsistent. Use the exit status in automation rather than searching loosely formatted output. Then test the services that matter to the requirement: authenticate with the approved SSH method, make a TLS connection to a representative endpoint, and run application-specific health checks. A service being active does not establish that it uses an approved cryptographic module or configuration.

One compatibility example in SUSE’s guide concerns Samba/CIFS: in a FIPS environment, use Kerberos authentication because the other Samba authentication modes include MD5. Apply that guidance only if the host provides or consumes Samba services; otherwise focus on the protocols and libraries actually in scope.

5. Resolve failures without weakening the requirement

If --check reports that FIPS is not enabled, review the complete command output and confirm that the required reboot occurred. Check the installed release and package set, then consult the matching SUSE guide. If the mode is reported as enabled but an application fails, inspect that application’s logs and identify the algorithm or module it is trying to use. Replace or reconfigure the dependency with an approved option, or obtain a documented exception from the compliance owner.

Do not switch back to a permissive crypto policy merely to make a legacy client work while claiming FIPS operation. If rollback is necessary, use the organization’s incident and approval process; SUSE documents sudo fips-mode-setup --disable followed by a reboot to disable the mode. Reassess compliance status after any rollback.

Before closing the change, save the service-pack identification, package information, command output, reboot record, and application test results in the system’s change record. In the illustrative scenario, that evidence lets the team distinguish three separate facts: the host reports FIPS mode enabled, the intended services function, and the selected cryptographic modules match the compliance requirement. Only the responsible assessor can decide whether those facts satisfy the applicable control.

For the authoritative procedure and release-specific caveats, consult the SUSE Linux Enterprise Server 15 SP7 Security and Hardening Guide, the SUSE FIPS certification information, and the applicable NIST Cryptographic Module Validation Program record.