Enable and Verify FIPS Mode in 389 Directory Server

Directory Server can run with FIPS-approved cryptographic modules when the host operating system and each instance NSS database are both configured for FIPS operation. On my lab host I used that workflow to run ns-slapd with approved algorithms for TLS, certificate handling, and related NSS operations, then verified that LDAP clients, replication, and authentication still worked with the stricter policy.

In this guide I'll walk through host and NSS prerequisites, pre-change inventory, backup, modutil enablement, TLS and LDAP verification, client compatibility checks, troubleshooting, and migration-based rollback. It assumes LDAPS or STARTTLS is already deployed on the instance you plan to change.

Before you start:

• Configure TLS, STARTTLS, and LDAPS — working server certificate and LDAPS listener
• Certificate management — replace incompatible certificates and back up the NSS database
• TLS versions and cipher suites — detailed protocol and cipher tuning after FIPS is enabled
• Require secure LDAP connections — minimum SSF and bind enforcement
• Password storage schemes — PBKDF2, legacy hashes, and migration

Tested on: Rocky Linux 10.2; 389 Directory Server 3.2.0.

The tested change workflow uses instance ldap2 on ldap2.example.com with LDAP port 1389, LDAPS port 1636, and suffix dc=lab,dc=example,dc=com. Instance ldap1 on ldap1.example.com remains an unchanged baseline on the same host. The lab host itself was not operating in FIPS mode (fips_enabled=0), so the exercise demonstrates NSS database behaviour after modutil, not an operational or validated FIPS deployment.

Understand FIPS mode in 389 Directory Server

Directory Server cryptographic services come from Mozilla NSS. FIPS operation requires two layers:

FIPS-enabled operating system
        |
        v
FIPS-enabled NSS database (per instance)
        |
        v
389 Directory Server TLS and cryptographic operations

Enabling NSS FIPS on the instance alone does not establish full system-level FIPS compliance. Red Hat Directory Server documentation requires FIPS at both layers before you treat the deployment as FIPS-operational.

Setting update-crypto-policies --set FIPS is also not equivalent to booting the system in FIPS mode. On RHEL 10, Red Hat documents that the crypto policy alone is insufficient and that FIPS must be enabled during installation for a supported configuration. Turning FIPS off on RHEL 10 requires reinstalling the system. RHDS separately requires FIPS to be enabled in RHEL before enabling it in the instance NSS database. Current RHEL validation work uses FIPS 140-3; Red Hat FIPS certificates cover specific RHEL cryptographic-module versions and operating environments and do not automatically extend to rebuild distributions such as Rocky Linux.

Check operating-system and version requirements

Record the operating system and Directory Server package before you change cryptographic policy.

cat /etc/os-release

Sample output:

NAME="Rocky Linux"
VERSION="10.2 (Red Quartz)"
ID="rocky"
ID_LIKE="rhel centos fedora"

That confirms the distribution family and release you are testing against.

Check the installed Directory Server package and the instance you plan to change:

rpm -q 389-ds-base

Sample output:

389-ds-base-3.2.0-8.el10_2.x86_64

Confirm the target instance is running before you schedule the change:

dsctl ldap2 status

Sample output:

Instance "ldap2" is running

Verify system-level FIPS status:

cat /proc/sys/crypto/fips_enabled

Sample output on the tested lab host:

0

A value of 1 means the kernel reports FIPS mode enabled.

Optionally inspect the active system crypto policy:

update-crypto-policies --show

Sample output on the tested lab host:

DEFAULT

On a host that is actually operating in supported FIPS mode, confirm both the kernel indicator and the active crypto policy:

cat /proc/sys/crypto/fips_enabled

Confirm the active system crypto policy matches FIPS:

update-crypto-policies --show

Expected output on such a deployment:

1

FIPS

Together, 1 and FIPS show that the host is operating under the system FIPS policy, not merely using a stricter non-FIPS profile.

Host enablement is distribution- and version-specific. RHEL 8 and RHEL 9 document procedures for switching supported systems to FIPS mode. RHEL 10 requires FIPS mode to be enabled during installation. Other distributions may provide different FIPS packages, modules, or certification status. Follow your platform documentation rather than one universal host command.

Understand the changes caused by FIPS mode

Expect these effects after both layers are in FIPS operation:

• Non-approved cryptographic algorithms become unavailable.
• Legacy SSL protocols are disabled.
• Directory Server uses TLS protocols and ciphers permitted by the FIPS policy.
• Existing clients may fail if they require legacy algorithms.
• Certificates and keys must use supported algorithms and sizes.
• SASL, Kerberos, replication, chaining, and client authentication must be retested.

Red Hat Directory Server documentation states that FIPS mode disables legacy SSL and permits TLS 1.2 and TLS 1.3 for encrypted connections.

On the tested ldap2 workflow, enabling NSS FIPS reduced the enabled cipher list from twenty-two suites to eighteen. Suites such as TLS_CHACHA20_POLY1305_SHA256 were no longer listed as enabled after NSS FIPS mode was turned on.

Inventory the current Directory Server security configuration

Before you enable FIPS on ldap2, record its current TLS and certificate settings.

dsconf ldap2 security get

Sample output:

nsslapd-security: on
nsslapd-secureport: 1636
nsslapd-ssl-check-hostname: on
sslversionmin: TLS1.2
sslversionmax: TLS1.3
nsssl3ciphers: default

List enabled cipher suites:

dsconf ldap2 security ciphers list --enabled

Sample output:

TLS_AES_128_GCM_SHA256
TLS_CHACHA20_POLY1305_SHA256
TLS_AES_256_GCM_SHA384
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256

The full enabled list on ldap2 before the change contained twenty-two suites spanning TLS 1.2 and TLS 1.3.

List the certificate nicknames stored in the instance NSS database:

dsconf ldap2 security certificate list

That command shows every server and CA nickname stored in the instance NSS database.

List trusted CA certificates separately so you can confirm which issuer clients must trust:

dsconf ldap2 security ca-certificate list

Compare this list with the leaf certificate issuer before I export a client trust bundle.

Export the issuing CA as a client trust bundle for later LDAPS and openssl tests. When the NSS database lists both Self-Signed-CA and Server-Cert, Server-Cert is the leaf certificate and Self-Signed-CA is its issuer. Export the issuer, not the leaf:

dsctl ldap2 tls export-cert "Self-Signed-CA" --output-file /root/ldap2-ca-chain.pem

The exported PEM file becomes the trust anchor for later LDAPTLS_CACERT, dsconf over LDAPS, and openssl -CAfile checks.

You can also export the same CA with certutil:

certutil -d /etc/dirsrv/slapd-ldap2/ -L -n "Self-Signed-CA" -a -o /root/ldap2-ca-chain.pem

For an externally issued certificate, build the file from the intended root trust anchor and required intermediate CA certificates. Do not describe a leaf-certificate export as a CA-chain export. RHDS client verification guidance is based on trusting the issuing CA.

Record the NSS certificate and module state while the instance is still online:

certutil -d /etc/dirsrv/slapd-ldap2/ -L

Sample output:

Certificate Nickname                                         Trust Attributes
                                                             SSL,S/MIME,JAR/XPI

Self-Signed-CA                                               CT,, 
Server-Cert                                                  u,u,u

That inventory confirms the leaf certificate and issuing CA nicknames you must preserve.

List PKCS #11 modules in the NSS database so I have a baseline before modutil -fips changes module state:

modutil -dbdir /etc/dirsrv/slapd-ldap2/ -list

Sample output:

1. NSS Internal PKCS #11 Module
	 slots: 2 slots attached
	status: loaded

The module list gives you a baseline for the NSS state that modutil -fips will change.

Also inventory server certificate algorithms, password storage schemes, attribute encryption, SASL mechanisms, client-certificate authentication, replication agreements, chaining connections, application LDAP libraries, and private-key provenance. Before you enable NSS FIPS, record for each credential:

• Where each server, replication, attribute-encryption, GSSAPI, and client-certificate private key was generated
• Whether migration or regeneration is required by the applicable compliance policy

Unchanged baseline on ldap1

Instance ldap1 was not modified during the lab exercise. Confirm that its NSS database remained outside FIPS mode:

modutil -dbdir /etc/dirsrv/slapd-ldap1/ -chkfips true

Sample output:

FIPS mode disabled.

Use a separate unchanged instance only as a baseline. Do not use it as evidence that the instance you changed still works after enabling NSS FIPS.

Back up the instance before enabling FIPS

Back up the instance configuration directory, which contains the NSS database:

/etc/dirsrv/slapd-ldap2/

Include cert9.db, key4.db, pkcs11.txt, pin.txt, pwdfile.txt, dse.ldif, and certificate nicknames with trust flags. Modern NSS SQL databases consist of cert9.db, key4.db, and pkcs11.txt. Because modutil manages PKCS #11 module information, pkcs11.txt is directly relevant to preserving and reversing the NSS FIPS-module state.

Create an online backup while ldap2 is running. Point administrative LDAP clients at the issuing CA before you connect over LDAPS:

export LDAPTLS_CACERT=/root/ldap2-ca-chain.pem

With client trust configured, I create an online backup over LDAPS:

dsconf -D "cn=Directory Manager" -y /root/ldap2-dm.pw ldaps://ldap2.example.com:1636 backup create

Sample output:

The backup create task has finished successfully

Resolve the exact backup directory created in this run rather than matching every historical backup:

BACKUP_DIR=$(find /var/lib/dirsrv/slapd-ldap2/bak -mindepth 1 -maxdepth 1 -type d -name 'ldap2-*' -printf '%T@ %p\n' | sort -nr | head -1 | cut -d' ' -f2-)

Verify that backup:

printf 'Verifying backup: %s\n' "$BACKUP_DIR"

List the configuration files captured in that backup directory:

ls "$BACKUP_DIR/config_files/"

Sample output:

Verifying backup: /var/lib/dirsrv/slapd-ldap2/bak/ldap2-2026-07-16T10:24:31.717294
cert9.db
certmap.conf
dse.ldif
key4.db
pin.txt
pwdfile.txt
schema
slapd-collations.conf

Check whether that specific backup contains pkcs11.txt:

test -f "$BACKUP_DIR/config_files/pkcs11.txt" && echo "pkcs11.txt is included" || echo "pkcs11.txt is absent; the full stopped-instance archive is required"

Sample output on the tested lab backup:

pkcs11.txt is absent; the full stopped-instance archive is required

When pkcs11.txt is missing from the Directory Server backup, do not treat dsconf backup create or db2bak alone as sufficient rollback protection for the modutil change. Make the stopped-instance full-directory archive mandatory before you enable NSS FIPS.

Current RHDS backups created through dsconf backup create or dsctl db2bak include configuration files, the certificate database, and custom schema under config_files/; these files are not restored automatically.

Store NSS and private-key backups as sensitive data with restrictive permissions. Avoid backup destinations under /var/tmp, /tmp, and /root when dsctl db2bak fails because of systemd PrivateTmp or Directory Server permissions.

Verify certificates and cryptographic keys

Inspect the active server certificate before you enable FIPS:

certutil -d /etc/dirsrv/slapd-ldap2/ -L -n "Server-Cert"

Sample output:

Signature Algorithm: PKCS #1 SHA-256 With RSA Encryption
        Subject: "CN=ldap2.example.com"
            Public Key Algorithm: PKCS #1 RSA Encryption

The output identifies an RSA public key and a SHA-256 certificate signature. This alone does not establish FIPS suitability. Verify the RSA key size, complete chain, signature parameters, module security policy, and applicable compliance requirements. Replace incompatible certificates first using certificate management.

Review password and encryption configuration

Check configured password storage schemes over LDAPS. Use the same CA file you exported earlier:

export LDAPTLS_CACERT=/root/ldap2-ca-chain.pem

Read the configured password storage schemes over the same LDAPS session:

dsconf -D "cn=Directory Manager" -y /root/ldap2-dm.pw ldaps://ldap2.example.com:1636 config get nsslapd-pwstoragescheme nsslapd-rootpwstoragescheme

Sample output:

nsslapd-rootpwstoragescheme: PBKDF2-SHA512

The instance is configured with PBKDF2-SHA512, which is the current RHDS default password-storage scheme. Verify that the scheme, implementation, parameters, and existing stored hashes satisfy the policy for the target FIPS deployment, then test authentication after migration.

Populate the instance with a test user under the suffix it serves before you change NSS policy. The lab uses uid=user1,ou=people,dc=lab,dc=example,dc=com on ldap2. Store the test password in a protected file rather than on the command line:

install -m 600 /dev/null /root/user1.pw

Write the test password into /root/user1.pw with a text editor or redirection. Mode 600 limits read access to the file owner.

Confirm that the test user can authenticate while ldap2 is still online:

export LDAPTLS_CACERT=/root/ldap2-ca-chain.pem

Confirm the test user can still bind over LDAPS before the maintenance window:

ldapwhoami -x -H ldaps://ldap2.example.com:1636 -D "uid=user1,ou=people,dc=lab,dc=example,dc=com" -y /root/user1.pw

Sample output:

dn: uid=user1,ou=people,dc=lab,dc=example,dc=com

That baseline bind confirms password verification works before you open the maintenance window.

Review user password schemes, Directory Manager storage, replication credentials, chaining credentials, pass-through authentication, and attribute-encryption keys. Do not assume every historical hash or encryption algorithm remains usable under the current operating-system FIPS policy.

Stop applications and verify instance health

Confirm ldap2 health before the maintenance window:

dsctl ldap2 healthcheck

Sample output:

Healthcheck complete.
No issues found.

Confirm the instance is still running before you open the maintenance window:

dsctl ldap2 status

Sample output:

Instance "ldap2" is running

Verify database health, TLS operation, replication status, certificate expiry, and a tested administrative access method over LDAPS. Schedule the NSS FIPS change during a maintenance window because it requires an instance restart.

Verify LDAPS and STARTTLS before the change

Record a working TLS baseline while ldap2 is still online. Confirm LDAPS negotiates TLS 1.2 with trusted certificate validation through OpenSSL:

openssl s_client -connect ldap2.example.com:1636 -servername ldap2.example.com -tls1_2 -CAfile /root/ldap2-ca-chain.pem -verify_hostname ldap2.example.com -verify_return_error </dev/null

Sample output:

New, TLSv1.2, Cipher is ECDHE-RSA-AES128-GCM-SHA256
    Protocol  : TLSv1.2
    Cipher    : ECDHE-RSA-AES128-GCM-SHA256
    Verify return code: 0 (ok)

Verify return code: 0 (ok) confirms that the client trusted the certificate chain and that hostname verification succeeded. Record the negotiated protocol and cipher as the pre-change baseline.

Repeat the check for STARTTLS on the plain LDAP port:

openssl s_client -starttls ldap -connect ldap2.example.com:1389 -servername ldap2.example.com -CAfile /root/ldap2-ca-chain.pem -verify_hostname ldap2.example.com -verify_return_error </dev/null

Sample output:

New, TLSv1.3, Cipher is TLS_AES_128_GCM_SHA256
Protocol: TLSv1.3
Verify return code: 0 (ok)

These pre-change results give you a comparison point after NSS FIPS mode is enabled.

Enable FIPS mode for the NSS database

After the online checks above succeed, run one uninterrupted maintenance sequence: stop the instance once, create the offline backups, enable NSS FIPS, and restart. RHDS requires dsctl db2bak while the instance is offline, and modutil must run while the NSS database is not in use.

Stop ldap2:

dsctl ldap2 stop

Sample output:

Instance "ldap2" has been stopped

Create the offline database backup:

dsctl ldap2 db2bak

Archive the full instance configuration directory, including pkcs11.txt, while the server remains stopped:

I'll set umask 077 before creating the archive so the tarball is not group- or world-readable:

umask 077

I'll save the full stopped-instance archive path in a variable:

ARCHIVE="/root/slapd-ldap2-pre-fips-$(date +%F-%H%M).tar.gz"

Archive the instance configuration directory with tar, preserving ACLs, extended attributes, and SELinux labels:

tar --acls --xattrs --selinux -czpf "$ARCHIVE" -C /etc/dirsrv slapd-ldap2

Verify the archive before you modify NSS:

tar -tzf "$ARCHIVE" | grep -E 'cert9\.db|key4\.db|pkcs11\.txt|pin\.txt|pwdfile\.txt|dse\.ldif'

A matching line for each file confirms that the full NSS state, including pkcs11.txt, is preserved.

Enable FIPS for the instance NSS database:

printf '\n' | modutil -dbdir /etc/dirsrv/slapd-ldap2/ -fips true

modutil may prompt you to continue. Press Enter after you stop Directory Server. The command may print FIPS mode enabled. when the change succeeds.

Bring the instance back online:

dsctl ldap2 start

Sample output:

Instance "ldap2" has been started

Repeat the same stop, offline backup, modutil, and start sequence for every instance you move to NSS FIPS mode.

Verify the instance NSS FIPS setting

Confirm the NSS database FIPS setting:

modutil -dbdir /etc/dirsrv/slapd-ldap2/ -chkfips true

Sample output:

FIPS mode enabled.

That output confirms the NSS database setting only. It does not prove full platform FIPS compliance.

Confirm Directory Server started cleanly after the NSS change:

dsctl ldap2 status

Sample output:

Instance "ldap2" is running

Review recent service log entries for NSS or keytab errors raised during startup with journalctl:

journalctl -u dirsrv@ldap2 --since "10 minutes ago"

Inspect the instance error log when the journal is not detailed enough:

/var/log/dirsrv/slapd-ldap2/errors

On this non-FIPS lab host, FIPS mode enabled. proves only that the instance NSS database has its FIPS setting enabled. RHDS requires host FIPS mode as a prerequisite before enabling NSS FIPS for a supported deployment. RHEL uses /proc/sys/crypto/fips_enabled to determine whether core cryptographic components activate FIPS restrictions.

Full platform verification additionally requires /proc/sys/crypto/fips_enabled to return 1, the system crypto policy to report FIPS, and the deployed cryptographic modules and platform versions to fall within the applicable CMVP validation boundary. The instance must also start and serve LDAP operations on the changed server.

Verify TLS protocols and cipher suites

List enabled ciphers after NSS FIPS mode is enabled. Connect over LDAPS with the issuing CA you exported earlier:

export LDAPTLS_CACERT=/root/ldap2-ca-chain.pem

List enabled cipher suites again after NSS FIPS mode is turned on:

dsconf -D "cn=Directory Manager" -y /root/ldap2-dm.pw ldaps://ldap2.example.com:1636 security ciphers list --enabled

Sample output after NSS FIPS was enabled on ldap2:

TLS_AES_128_GCM_SHA256
TLS_AES_256_GCM_SHA384
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256

The enabled list contained eighteen suites and no longer included TLS_CHACHA20_POLY1305_SHA256.

Confirm LDAPS negotiates TLS 1.2 with trusted certificate validation:

openssl s_client \
    -connect ldap2.example.com:1636 \
    -servername ldap2.example.com \
    -tls1_2 \
    -CAfile /root/ldap2-ca-chain.pem \
    -verify_hostname ldap2.example.com \
    -verify_return_error \
    </dev/null

Sample output:

New, TLSv1.2, Cipher is ECDHE-RSA-AES128-GCM-SHA256
    Protocol  : TLSv1.2
    Cipher    : ECDHE-RSA-AES128-GCM-SHA256
    Verify return code: 0 (ok)

Verify return code: 0 (ok) confirms that the client trusted the certificate chain and that hostname verification succeeded. The negotiated protocol and cipher can then be recorded for compatibility testing. FIPS approval depends separately on the host state, validated cryptographic-module boundary, approved mode, and applicable security policy.

Where supported, repeat the same check for TLS 1.3:

openssl s_client \
    -connect ldap2.example.com:1636 \
    -servername ldap2.example.com \
    -tls1_3 \
    -CAfile /root/ldap2-ca-chain.pem \
    -verify_hostname ldap2.example.com \
    -verify_return_error \
    </dev/null

Sample output:

New, TLSv1.3, Cipher is TLS_AES_128_GCM_SHA256
Protocol: TLSv1.3
Verify return code: 0 (ok)

Test STARTTLS on the plain LDAP port with the same trust bundle and hostname checks:

openssl s_client \
    -starttls ldap \
    -connect ldap2.example.com:1389 \
    -servername ldap2.example.com \
    -CAfile /root/ldap2-ca-chain.pem \
    -verify_hostname ldap2.example.com \
    -verify_return_error \
    </dev/null

Sample output:

New, TLSv1.3, Cipher is TLS_AES_128_GCM_SHA256
Protocol: TLSv1.3
Verify return code: 0 (ok)

Confirm certificate validation still succeeds with Verify return code: 0 (ok), record the negotiated protocol and cipher, and compare the result with your pre-change baseline. Disabled legacy protocols should fail when you test them explicitly. Detailed cipher management belongs in TLS versions and cipher suites.

When multiple instances run on one host, ensure the LDAP URI hostname resolves to the host that carries the instance under test.

Test LDAP authentication and operations

Retest user authentication on the changed instance. Trust the issuing CA and read the password from the protected file:

export LDAPTLS_CACERT=/root/ldap2-ca-chain.pem

Retest the same user bind over LDAPS after the NSS change:

ldapwhoami -x -H ldaps://ldap2.example.com:1636 -D "uid=user1,ou=people,dc=lab,dc=example,dc=com" -y /root/user1.pw

Sample output:

dn: uid=user1,ou=people,dc=lab,dc=example,dc=com

The returned DN confirms that password verification still works after the NSS database setting change.

Repeat the check through STARTTLS on the plain LDAP port:

ldapsearch -x -H ldap://ldap2.example.com:1389 -ZZ -D "uid=user1,ou=people,dc=lab,dc=example,dc=com" -y /root/user1.pw -b "dc=lab,dc=example,dc=com" "(uid=user1)" dn

Sample output:

dn: uid=user1,ou=people,dc=lab,dc=example,dc=com

# numEntries: 1

One matching entry means search and bind still work after the NSS policy change.

Also retest password change, entry modification, Directory Manager administration over LDAPS, LDAPI administration, client-certificate authentication, and SASL GSSAPI where configured on the changed instance.

Verify replication and server-to-server connections

For every replication agreement, test supplier-to-consumer connectivity, TLS negotiation, certificate validation, replication bind authentication, and backlog status.

Also verify database chaining, pass-through authentication, synchronization agreements, monitoring probes, and backup automation.

A peer that requires a legacy protocol or algorithm may fail after FIPS is enabled even when the directory data itself is healthy.

Test application compatibility

During the maintenance window, record pass or fail results for each client type you depend on:

Check application runtime versions and supported algorithms before you weaken any policy.

Monitor Directory Server after the change

Review logs for the changed instance:

/var/log/dirsrv/slapd-ldap2/errors
/var/log/dirsrv/slapd-ldap2/access
/var/log/dirsrv/slapd-ldap2/security

Look for NSS initialization errors, unsupported algorithm messages, TLS handshake failures, certificate validation errors, SASL or Kerberos failures, replication connection failures, and password verification failures.

Review recent systemd journal entries for startup or TLS errors that may not yet appear in the access log:

journalctl -u dirsrv@ldap2 --since "10 minutes ago"

Run the health check again on the changed instance:

dsctl ldap2 healthcheck

Sample output:

Healthcheck complete.
No issues found.

A clean post-change health check gives you a quick sign that certificate expiry, database health, and listener configuration still pass the built-in checks.

Troubleshoot FIPS mode

Understand rollback limitations

Distinguish between these recovery paths:

• Disabling FIPS for one NSS database with modutil -fips false
• Disabling operating-system FIPS mode
• Restoring a pre-change Directory Server instance from backup
• Migrating to a new non-FIPS host

Operating-system FIPS mode is not always safely reversible. RHEL 10 documentation requires FIPS mode to be enabled during installation and requires reinstallation to return to a supported non-FIPS configuration.

The following modutil -fips false operation is only for the non-FIPS laboratory host used in this exercise. Do not use it as the rollback for a production host that must remain in FIPS mode. For such a deployment, restore the instance on another FIPS-enabled host or migrate to a separately installed non-FIPS system according to the required target state.

Also restore the complete pre-change NSS and configuration backup if the instance does not return cleanly after merely toggling the NSS setting.

To roll back NSS FIPS on ldap2 during the lab exercise:

Stop the instance before you change the NSS database again:

dsctl ldap2 stop

Sample output:

Instance "ldap2" has been stopped

Disable NSS FIPS mode in the instance database:

printf '\n' | modutil -dbdir /etc/dirsrv/slapd-ldap2/ -fips false

Sample output:

FIPS mode disabled.

Start Directory Server with the restored NSS setting:

dsctl ldap2 start

Sample output:

Instance "ldap2" has been started

Confirm the NSS database is no longer in FIPS mode:

modutil -dbdir /etc/dirsrv/slapd-ldap2/ -chkfips true

Sample output:

FIPS mode disabled.

After rollback on the tested ldap2 instance, the enabled cipher list returned to twenty-two suites.

Prefer migration to a tested replacement host as the production rollback design rather than assuming a single configuration toggle will restore every layer.

FIPS migration recommendations

For an existing production service, prefer this sequence:

1. Install a new host with FIPS enabled according to your distribution documentation.
2. Install the required Directory Server version.
3. Generate new server private keys and CSRs on the FIPS-enabled target host whenever required by the compliance policy. Import an existing private key only when the approved key-management procedure permits it, the key was generated using acceptable algorithms and parameters, and it is transferred in an approved protected form.
4. Replicate or migrate directory data.
5. Test applications and authentication.
6. Move traffic to the FIPS-enabled server.
7. Retire the old instance after validation.

RHEL recommends enabling FIPS during installation partly so cryptographic keys are generated under the correct FIPS operating conditions and do not require later compliance reevaluation.

This reduces the risk of changing cryptographic behavior on the only working directory server.

What's Next

• Password storage schemes — hash algorithms allowed in FIPS deployments
• TLS ciphers and protocol versions — approved TLS suites on a FIPS host
• Certificate management — NSS database backup before modutil changes

References

• Red Hat Directory Server 13 — Securing Red Hat Directory Server
• Red Hat Directory Server 13 — Enabling the FIPS mode
• Red Hat Enterprise Linux — Switching the system to FIPS mode
• Mozilla NSS — modutil
• NIST FIPS 140-3
• NIST Cryptographic Module Validation Program

Summary

1. Enable FIPS mode at the operating-system level using distribution-supported procedures.
2. Audit certificates, password schemes, clients, and replication on the instance you plan to change.
3. Create an online backup, verify the exact backup directory, and confirm whether pkcs11.txt is included.
4. Complete pre-change certificate, password, authentication, health, and TLS checks while the instance is online.
5. Stop the instance, run offline db2bak and a full configuration archive, enable NSS FIPS with modutil -fips true, and restart.
6. Verify the NSS setting, host FIPS indicators, TLS with trusted certificate validation, and LDAP authentication on the same instance.
7. Plan migration-based recovery because host-level FIPS may not be safely reversible.