OpenSSL 3.x Providers: Provider‑agnostic Crypto and FIPS Isolation

The problem: shipping a single binary to both regulated and non‑regulated environments usually means maintaining two builds – one with FIPS‑approved algorithms and one without. OpenSSL 3.x offers a modular Provider model that lets you keep the same application code and change the security policy at runtime, without recompiling.

Why the Provider model matters for engineering decisions

OpenSSL 3.0 replaced the monolithic libcrypto with a pluggable Provider architecture. Core, default and FIPS providers can be loaded independently and selected at runtime via configuration or environment variables. Applications that use the high‑level EVP API stay provider‑agnostic: they request operations by name (e.g., AES‑256‑GCM) and the active provider supplies the implementation.

Keeping application code provider‑agnostic with EVP

The engineering decision is to use EVP and avoid legacy low‑level APIs. EVP abstracts algorithm choice; the application sets properties, not implementations. Example property control in C (compile with OpenSSL headers, run as a user with development tools installed):

/* Set FIPS‑approved properties for this context */
EVP_default_properties_enable_fips(NULL, 1);

/* Request an operation by name, not by implementation */
EVP_CIPHER *cipher = EVP_CIPHER_fetch(NULL, "AES-256-GCM", NULL);
/* use cipher ... */
EVP_CIPHER_free(cipher);

The code does not name a provider. The provider is chosen by the library based on loaded providers and the properties set above.

Concrete TLS/EVP usage example

When using the openssl command line, you can load a specific provider set and verify which algorithms become available:

# List loaded providers and their status
openssl list -providers

# Show which algorithms each provider exposes
openssl list -algorithms -providers

# Start a TLS session with the default (or FIPS) provider
openssl s_server -port 4433 -provider default -cert cert.pem -key key.pem

In a programmatic setting, a small test using EVP_PKEY_fromdata with EVP_default_properties_enable_fips can confirm that non‑approved parameters are rejected when FIPS mode is enabled.

Verification and trade‑offs

• Check version and provider support: openssl version -a confirms you are on OpenSSL 3.x and displays build date and provider support.
• Enumerate loaded providers: openssl list -providers shows each provider’s name, status (active/inactive) and build ID.
• Inspect algorithm exposure: openssl list -algorithms -providers lists which algorithms each provider makes available; look for AES-256-GCM under the default provider and the restricted set under the FIPS provider.
• FIPS mode enforcement: Setting OPENSSL_CONF=/etc/ssl/openssl-fips.cnf or exporting OPENSSL_ENABLE_FIPS=1 at process start forces the FIPS provider; any use of a non‑approved algorithm will abort rather than silently fallback.

Trade‑offs and limitations: FIPS mode is strict about key sizes, curves and RNG sources. Using a non‑approved algorithm after enabling FIPS causes operation failures, not silent fallback. Mixing legacy low‑level APIs with provider logic can bypass provider policies and create subtle incompatibilities. Provider behavior is version‑sensitive, so pin the OpenSSL version in deployment and test provider selection explicitly. Loading order, config files and environment variables add operational surface area that must be audited.

Closing checklist

1. Confirm OpenSSL 3.x is installed: openssl version -a.
2. List providers and verify the FIPS provider is (or is not) loaded as required.
3. If FIPS compliance is needed, enable it via config or environment and run openssl list -algorithms -providers to ensure only approved algorithms appear.
4. Keep application code on the EVP API; avoid direct use of legacy RSA/AES functions unless absolutely necessary.
5. After any config change, restart the affected processes and re‑run the verification steps.

By keeping application code provider‑agnostic and configuring providers via config files or environment, you get a single build that can be locked down for compliance and relaxed for development – all without recompiling.