OpenSSL 3.0 Provider Loading: Distinguishing Missing-Algorithm Failures After the 1.1.1 Transition

Answer

An application can tell whether a fetch failure is due to a missing provider or to a policy/build restriction by first testing whether the legacy provider can be loaded, loading it once if possible, and then retrying the fetch. If the retry still fails, the algorithm is absent from the loaded providers or blocked by policy, and the operation should be treated as a permanent failure.

Supported pattern (no duplication of the original write/operation)

1. Perform the explicit fetch (e.g. EVP_CIPHER_fetch or EVP_MD_fetch) with the desired algorithm name and default property query.
2. If the fetch returns NULL, check the error queue for ERR_R_UNSUPPORTED (any fetch failure).
3. Call OSSL_PROVIDER_available(NULL, "legacy"). If it returns 1, the provider can be loaded.
4. Load the provider once with OSSL_PROVIDER_load(NULL, "legacy"). This function is ref‑counted and idempotent per OSSL_LIB_CTX, so calling it again later is safe and does not duplicate side effects.
5. Retry the original fetch exactly as in step 1.
6. If the second fetch succeeds, continue with the algorithm. If it fails again, treat the failure as a build‑time omission or policy rejection and abort the operation (do not loop).

Because fetch operations are pure look‑ups with no side effects, the fetch‑load‑retry sequence does not duplicate the original write or any surrounding business operation; only the lookup is repeated.

Distinguishing policy rejection after the provider is loaded

After loading legacy, a remaining failure can be due to:

• The algorithm truly absent from that provider (e.g. a minimal or FIPS build that excluded it).
• A property query that filtered it out (e.g. fips=yes or a custom props string).

To differentiate, re‑run the fetch with an explicit property string that forces the provider, e.g. props="provider=legacy". If that succeeds, the original failure was caused by the default property query excluding the algorithm. If it still fails, the algorithm is not present in the loaded provider.

Alternatively, enumerate the provider’s offerings with EVP_CIPHER_do_all_provided or EVP_MD_do_all_provided and check whether the target name appears in the callback.

Version considerations

The steps above are valid for OpenSSL 3.0 and all later 3.x releases. The only change between releases is the exact set of algorithms present in the default and legacy providers (and any vendor‑specific builds such as FIPS or minimal distro packages). Therefore, the application should verify provider contents on the target deployment (e.g. via openssl list -providers and openssl list -cipher-algorithms -provider legacy or the equivalent API calls) rather than assuming 1.1.1 behavior.

Missing diagnostic detail

If the application cannot determine whether the OpenSSL build includes the legacy provider at all (e.g. due to a stripped‑down library), it should ask for the output of OSSL_PROVIDER_available(NULL, "legacy") on the target binary; this single detail changes the recommendation from “load and retry” to “treat as unavailable”.