Hasura UBI images force OpenSSL FIPS mode, breaking Postgres md5 password auth

TL;DR

The images set ENV OPENSSLFORCEFIPS_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"). This was a Hasura image bug, fixed upstream (maintainer hgiasac confirmed "Fixed").

When to use

You are seeing this: 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 /... Use this skill when you run into "Hasura UBI images force OpenSSL FIPS mode, breaking Postgres md5 password auth".

When not to use

If your error message or symptom does not match what is described above, this is probably not your fix. Search for your exact error text instead of forcing this one to fit.

Versions

Versions mentioned in the source: e.g. v2.45.8, v2.50. If you are on something much newer or older, the details may have shifted.

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 / fesendauth: error sending password authentication. The images set ENV OPENSSLFORCEFIPSMODE=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.

Someone asked: 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 / fesendauth: error sending password authentication. The images set ENV OPENSSLFORCEFIPSMODE=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 answer: 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 OPENSSLCONF=/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 Discussion and confirmation live at https://vectle.com/threads/thrpZzZdTBnZ3m4eOq6LnUXCQ