FIPS 140-3 for PostgreSQL, MySQL, MariaDB and Valkey: What Is Validated and What Is Not

The short answer

FIPS 140-3 validates cryptographic modules, not databases. PostgreSQL, MySQL, MariaDB, Valkey and Redis do their TLS and most of their hashing through a library, almost always OpenSSL, and that library is the part that can hold a certificate from NIST's Cryptographic Module Validation Program (CMVP). A database server is "FIPS-ready" in the useful sense when it sends all of its cryptography through a validated module that is running in its approved mode, on an operating environment the certificate covers.

So the question to ask a vendor, an auditor or your own platform team is never "is this database validated?". It is "which module does it call, what is that module's certificate number, is the certificate active, and is the module configured the way its security policy requires?".

What the CMVP actually validates

A CMVP certificate names a module, a version, the operating environments it was tested on and a security policy that says how it must be configured. Federal agencies buy against that certificate. The CMVP's own page is blunt about the stakes: for agencies, non-validated cryptography is treated as providing no protection at all, so if cryptography is required, it must be validated.

Two dates matter this year:

• FIPS 140-2 has moved to the Historical list. FIPS 140-2 modules could be used for new systems until 21 September 2026. After that date the CMVP moves them to the Historical list, which allows continued use in existing systems only. New systems need a FIPS 140-3 module.
• The OpenSSL FIPS provider has a FIPS 140-3 certificate. Certificate #4985 covers the OpenSSL FIPS Provider built from OpenSSL 3.1.2. It is active, Level 1, and its sunset date is 10 March 2030. The earlier FIPS 140-2 certificate for the 3.0 providers, #4282, is now historical.

OpenSSL's rule is worth reading twice: other OpenSSL releases may load the validated FIPS provider, but they must not build and use their own. In practice you run current libssl and libcrypto for TLS fixes, and point them at a FIPS provider built from the validated source.

Validated, FIPS mode, FIPS-compliant: three different claims

A "FIPS-compliant build" can be perfectly sound, for example a PostgreSQL package that links dynamically against a distribution's validated OpenSSL. It can also mean a build that merely compiles with FIPS options turned on. Only the certificate and the runtime configuration tell you which.

PostgreSQL

PostgreSQL's TLS support needs OpenSSL at build time, and the server reads the system-wide OpenSSL configuration file at start-up (or the file named in OPENSSL_CONF). If the operating system's OpenSSL is set to load its FIPS provider, PostgreSQL's TLS and SCRAM authentication use it. SHOW ssl_library; reports which library the server was built against.

PostgreSQL 18 added two helpers in pgcrypto. fips_mode() returns true when OpenSSL is running in FIPS mode, and setting pgcrypto.builtin_crypto_enabled = fips disables pgcrypto's own built-in crypt() and gen_salt() when it is, because those do not go through OpenSSL. Versions before 18 do not have these, so on 13 to 17 you check FIPS mode at the operating system and decide yourself whether those two functions are allowed.

Use scram-sha-256 for passwords. MD5 password authentication is deprecated as of PostgreSQL 18, and a FIPS review is a good moment to move the remaining accounts off it.

MySQL

MySQL supports FIPS mode when a suitable OpenSSL library and FIPS module are present as shared libraries at runtime. Its manual says MySQL has no FIPS-specific code beyond passing the mode to OpenSSL, which is the clearest statement any of these projects makes that the module, not the server, is what counts. Check it with SELECT @@ssl_fips_mode;: 1 (ON) or 2 (STRICT) means FIPS mode is active, 0 (OFF) means it is not available.

Two cautions. The 8.4 manual still describes FIPS 140-2 and OpenSSL 1.0.2, so map its advice onto a FIPS 140-3 provider yourself. And FIPS mode restricts ciphers but does not force encryption: an account can still connect in clear text unless you set REQUIRE SSL on the account or require_secure_transport=ON on the server.

MariaDB

MariaDB has no switch for FIPS mode inside the server. Its documentation says to enable FIPS at the kernel level or through the OpenSSL configuration, for the whole system or just the MariaDB process. What matters more is which library the binary uses:

• DEB and RPM packages link the system OpenSSL dynamically, so they inherit the operating system's FIPS configuration.
• Linux binary tarballs and the Windows MSI and ZIP packages link MariaDB's bundled wolfSSL statically. MariaDB notes that the standard wolfSSL is not certified and the certified variant's licence is incompatible with MariaDB, so these packages are not a route to FIPS.

SHOW GLOBAL VARIABLES LIKE 'have_openssl'; returns YES when the server is linked with OpenSSL, and version_ssl_library shows which version.

Valkey and Redis

Valkey and Redis build TLS support only when asked (make BUILD_TLS=yes), against the OpenSSL development libraries on the build host. Neither project documents a FIPS mode, so the answer is the same as for MariaDB: a package that links the distribution's OpenSSL dynamically inherits its FIPS configuration, and a statically linked or self-built binary carries whatever it was built with. Check with ldd on the server binary.

How to check a running server

# Operating system: kernel FIPS flag and the active OpenSSL providers
cat /proc/sys/crypto/fips_enabled
openssl list -providers

# RHEL 9 and derivatives
fips-mode-setup --check

# PostgreSQL
SHOW ssl_library;
SELECT fips_mode();              -- PostgreSQL 18, pgcrypto installed

# MySQL
SELECT @@ssl_fips_mode;

# MariaDB
SHOW GLOBAL VARIABLES LIKE 'have_openssl';
SHOW GLOBAL VARIABLES LIKE 'version_ssl_library';

# Valkey or Redis: which libssl and libcrypto does the binary load?
ldd "$(command -v valkey-server)" | grep -E 'libssl|libcrypto'

Containers need the same check inside the image. A container uses the OpenSSL that ships in its own image, so a FIPS-enabled host does not make a database image FIPS-capable; the image's library and configuration decide.

Using the operating system's validated module

For most teams the practical route is the distribution. Red Hat documents fips-mode-setup --enable for RHEL 9 but recommends installing in FIPS mode from the start, so that every key is generated with approved algorithms, and publishes the validation status of its modules on its product compliance page. Canonical states that Ubuntu has enabled FIPS 140-3 compliance from 22.04 LTS onwards through Ubuntu Pro.

Expect one tension. A module is validated at a specific version, and security fixes change the version. Canonical says plainly that it keeps patching its FIPS modules because security matters more than strict compliance. Decide with your compliance lead which matters more for each system, write the decision down, and give it to the auditor before they ask.

What to ask a database vendor

• Which cryptographic module does each package call, and what is its CMVP certificate number?
• Is that certificate active, historical or in process, and does it list the operating system release you run?
• Does the package link that module dynamically, or does it bundle or statically link its own cryptography?
• Which features still use built-in cryptography outside the module, such as pgcrypto's crypt() before PostgreSQL 18?
• When the module is patched for a CVE, how will you tell us whether the patched version is still the validated one?

Where OSSeva fits

OSSeva builds patched PostgreSQL, MySQL, MariaDB and Redis packages for lines upstream has stopped fixing. A database build is not a cryptographic module, ours included, so the FIPS answer for an OSSeva build is the same as for a community one: which validated module it uses on your operating system and how that module is configured. Ask us that question for your platforms before you rely on it, as you should ask any vendor. What OSSeva adds is the evidence around it: signed DEB and RPM packages, tarballs and container images, and on OSSeva Assure a compliance attestation package for PostgreSQL and SBOMs with CVE remediation records for MySQL and MariaDB. OSSeva for CISOs describes the security side of the offer, priced per cluster; book a discovery call for a quote.

Frequently asked questions

Is PostgreSQL FIPS 140-3 validated?

No. PostgreSQL is not a cryptographic module and has no CMVP certificate. It can run with FIPS 140-3 validated cryptography when it uses an OpenSSL whose FIPS provider is validated and enabled, such as the OpenSSL FIPS Provider under certificate #4985 or an operating system's own validated OpenSSL.

Is MySQL FIPS compliant?

MySQL can run in FIPS mode when it is linked against an OpenSSL with an available FIPS module. Its manual says MySQL itself has no FIPS-specific code beyond passing the mode to OpenSSL, so compliance depends on that module's certificate and configuration.

What happened to FIPS 140-2 certificates in September 2026?

From 21 September 2026 the CMVP moves FIPS 140-2 certificates to the Historical list. Modules on that list can stay in existing systems but should not be chosen for new ones.

Does FIPS mode encrypt our data at rest?

No. FIPS mode restricts which algorithms the validated module will use. Whether data is encrypted on disk or in transit is a separate configuration choice, and MySQL's manual notes that FIPS mode does not even require encrypted connections.

Can we run database containers in FIPS mode?

Yes, if the image itself contains a validated module and is configured to use it. The OpenSSL inside the image does the cryptography, so a FIPS-enabled host alone is not enough.

Does a "FIPS-capable" build mean it is validated?

Not by itself. Ask for the certificate number of the module the build uses, confirm on csrc.nist.gov that it is active and covers your operating system, and check the runtime configuration on a real server.