Enabling FIPS on UAT Postgres servers meant moving off MD5 passwords

The problem

We needed FIPS mode enabled on our UAT database servers, running RHEL 9.5. The reason was an RBI audit point, so it was not optional.

The first attempt to enable FIPS did not stick, and the reason was on the database side: our Postgres databases were still using the older MD5 password hashing method, which is not compatible with FIPS mode.

Why this mattered more than a usual config change

These are not isolated databases. Our UAT Keycloak identity provider runs on them, and the dependency chain goes like this:

• If Postgres is down, Keycloak does not run.
• If Keycloak is down, Superset does not run.
• If Vault is down, all the application pods end up stuck in CrashLoopBackOff.

So a password hashing change on the database silently sits upstream of the identity provider, the BI tool, and every application pod.

The fix

The order of operations turned out to be the whole trick:

1. Change the password hashing from MD5 to SCRAM.
2. Reformat the existing passwords and add them back under the new scheme.
3. Enable FIPS again, and this time it worked.

Verifying it

After the change I confirmed FIPS mode was actually active using:

sudo fips enable

What I would do differently

I would have checked what authentication and crypto settings the services on the host depend on before enabling FIPS, not after. FIPS is not a single-server change when the server is upstream of Keycloak, Superset and Vault. Mapping the dependency chain first would have made the MD5-to-SCRAM step obvious from the start instead of a fix after the fact.

Comments

[DEV SUPPORT]

You need to verify your account.

tr.ee/dev-to