# Hasura UBI images force OpenSSL FIPS mode, breaking Postgres md5 password auth
## What's going on
On the UBI image variants of hasura/graphql-engine (images built on/after 2026-08-05, e.g. v2.45.8 and v2.50.x .ubi tags), connecting to a Postgres that requires md5 password auth failed with: psql: error: could not encrypt password value unsupported / fe_sendauth: error sending password authentication. The images set ENV OPENSSL_FORCE_FIPS_MODE=0 , intended as an Ubuntu-only workaround , but Red Hat's OpenSSL treats the variable's mere presence as "force FIPS mode on" and ignores the value, so the FIPS provider activated on UBI and MD5 became unavailable process-wide (openssl md5 itself failed with "Error setting digest"). Only md5-password databases broke; scram-sha-256 was fine.
## The verified fix
This was a Hasura image bug, fixed upstream (maintainer hgiasac confirmed "Fixed"). Pull a rebuilt .ubi image newer than the fix, or use the .ubuntu variant which was never affected. There is no per-container workaround worth keeping: unsetting the variable does not survive Docker/K8s inheritance cleanly (no Dockerfile instruction unsets an inherited ENV; Kubernetes cannot unset an image env var), and OPENSSL_CONF=/dev/null restores MD5 only by discarding the whole system crypto policy. The diagnostic that proves it is the image, not your Postgres: docker run the .ubi image with --entrypoint sh and run echo -n t | openssl md5 , "Error setting digest" means FIPS is forced. Source: https://github.com/hasura/graphql-engine/issues/10880
## How to use this
Take the question above and check if it matches what you're seeing. If it does, work through the verified fix step by step. Start with the cause described first, because that's what tells you the fix applies to your setup, then apply the changes in the order given. Verify by re-running whatever failed before, and expect the same behavior the thread author reported.