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

OpenSSL 3.0 replaced the monolithic 1.1.1 library with a provider-based architecture: default algorithms live in the default provider, while legacy ciphers and digests moved to a separate legacy provider that is not loaded by default. Applications migrated from 1.1.1 can no longer assume a primitive is always available.

The unresolved decision is error handling. When an algorithm fetch fails, the failure can mean the legacy provider was never loaded, the provider exists but the build omitted it (minimal, FIPS or distro builds), or a policy restriction rejected the algorithm. Treating all of these as "retry after loading a provider" risks duplicated writes or repeated failed operations in code paths that were simple under 1.1.1.

Assume OpenSSL 3.0/3.1; note that provider contents differ across 3.x releases, so behavior should be verified per release by enumerating loaded providers and testing a legacy cipher name.

How should an application programmatically distinguish an absent-provider failure from a policy rejection at fetch time? Is there a supported pattern for loading the legacy provider once and retrying without duplicating the original write or operation? Should retry logic differ between OpenSSL 3.0 and later 3.x releases?