Steven Foerster

Writing

Verifying FIPS 140-2: OpenSSL 3

FIPS compliance with OpenSSL 3 is about enabling the FIPS provider and proving it is actually in use, not just installed.

Cryptography Compliance OpenSSL FIPS

Originally published on LinkedIn. Lightly edited for clarity.

OpenSSL 3 introduced the provider model, which changes how FIPS mode is enabled and verified.

It is not enough to install the FIPS module. You need to confirm that the running application is actually using it.

What needs to be true

For OpenSSL 3 in FIPS mode, all of the following should be true:

  • The FIPS provider module is installed and validated.
  • The OpenSSL configuration loads the FIPS provider.
  • The application links against the correct OpenSSL build.

If any of those are missing, the system may appear compliant but is not.

Verify the provider is loaded

A basic check is to list providers and confirm the FIPS provider is active:

openssl list -providers

You should see the FIPS provider listed as “active.”

If it is present but inactive, check the config file and environment variables such as OPENSSL_CONF and OPENSSL_MODULES.

Validate algorithms against the FIPS provider

Confirm that algorithms are being served by the FIPS provider:

openssl list -digest-algorithms -provider fips

If this command fails or returns empty, the provider is not engaged.

Common failure modes

  • The app links against system OpenSSL instead of the FIPS build.
  • The FIPS module is installed but not referenced in openssl.cnf.
  • The module directory is not in the runtime search path.
  • Containers include the module but not the config file.

Treat the verification steps as part of your deployment pipeline, not a one-off audit task.

2026 Perspective

The move toward FIPS 140-3 is raising the bar on evidence and repeatability.

The process above still matters because it proves the runtime state, not just installed packages. Automated checks are the only reliable way to keep that proof current.