ERR_OSSL_EVP_UNSUPPORTED / error:0308010C — Find the Crypto Consumer

Diagnostic flow — boundary → owner → supported remediation

Fix #2 — confirm whether the runtime boundary changed

Node 17 introduced OpenSSL 3.0 and documented tighter restrictions on allowed algorithms/key sizes; Node exposed --openssl-legacy-provider as a temporary workaround for applications affected by those restrictions. Do not assume every current occurrence is “a Node 17 bug”: modern projects may hit the same error family when old crypto assumptions meet a newer Node/OpenSSL policy.

Compare the failing environment with the last known working one: local vs CI, Docker base image, build image, deployment runtime and version-manager selection. Check what actually runs rather than what package.json merely declares. A lockfile can be identical while the Node/OpenSSL runtime changes underneath it. process.execPath identifies the executable running that diagnostic process; for npm scripts, also print the same values inside the failing script/job because shell PATH/version-manager behavior can differ from your interactive terminal.

For containers and CI, record the image tag/digest and run the version check inside the failing job/container. A developer shell's node -v does not prove what a Docker build stage, CI runner or deployment image executes.

Verify: You can explain whether the failure correlates with a runtime/environment change and which Node binary executes the failing workflow.

Fix #3 — if build tooling owns it, repair the toolchain

If the first useful stack frames point into webpack, a framework CLI, loader/plugin or another dependency, identify the owning package and its installed version. Do not upgrade every package blindly. Trace the direct/transitive relationship, then check the framework/tool's supported Node matrix and release path.

If webpack is actually the owner, prefer the framework/webpack upgrade path supported by that project. Webpack's current documentation still documents output.hashFunction with md4 as the baseline option and notes xxhash64 support from webpack 5.54+, so the exact framework/configuration still matters. Avoid cargo-cult edits such as forcing a hash function in generated configuration that the framework owns or will overwrite.

Verify: After a supported dependency/framework upgrade, rerun the exact build under the intended Node version without legacy-provider compatibility.

Fix #4 — if your application owns the crypto call, migrate the crypto behavior

If the stack reaches your own crypto.createHash(), signing, encryption or key-loading code, inspect the exact algorithm, key format/size and operation being requested. Do not replace an algorithm merely because another name “works”; crypto choices are protocol/security decisions and may need compatibility with stored data or external systems.

Use Node's supported crypto APIs and the algorithm/protocol requirements appropriate to your application. If this protects real credentials, signatures or encrypted data, treat migration as a security/protocol change—not a syntax fix. Identify whether the algorithm is used for non-security build hashing, password hashing, signatures, encryption, key derivation or an external protocol. Those use cases are not interchangeable.

Verify: The same application test succeeds on the intended Node/OpenSSL runtime using the supported crypto design, and any required interoperability/security tests still pass.

Fix #5 — use legacy provider only as a diagnostic/temporary bridge

Node provides the --openssl-legacy-provider option to enable OpenSSL 3's legacy provider. Node introduced it specifically as a temporary workaround for tightened OpenSSL 3 restrictions. If enabling it makes the exact failing workflow succeed, that is strong evidence that legacy crypto behavior is involved—but it still does not tell you which package owns the request.

For npm scripts, environment-specific ways of setting NODE_OPTIONS differ across shells and CI systems. Node processes NODE_OPTIONS before command-line options; command-line singleton options can override the corresponding environment option. That makes a hidden NODE_OPTIONS in a CI secret/variable, Docker ENV, shell profile or process manager easy to miss while comparing environments.

Important: process.execArgv shows Node-specific options passed explicitly for the current process; inspect process.env.NODE_OPTIONS separately when hunting inherited compatibility flags. Prefer an explicit, short-lived diagnostic run and document why it exists. Avoid silently baking the legacy-provider flag into global shell profiles, base images, organization-wide CI variables or production process-manager configuration.

Verify: The bridge changes the failure as expected, you have identified the owner, and the final supported remediation works after the bridge is removed.

Fix #6 — make sure this is actually the same OpenSSL problem

ERR_OSSL_EVP_UNSUPPORTED is specific enough to investigate EVP/crypto support, but “OpenSSL error” is not. Certificate verification failures, TLS protocol negotiation, native-addon ABI problems and missing shared libraries have different evidence and fixes. Preserve the complete Node error code and top stack frames before applying this guide.

Verify: The final diagnosis explains the original error code and stack—not merely that a compatibility flag made one command proceed.

Still seeing ERR_OSSL_EVP_UNSUPPORTED?

Escalate with the runtime boundary and ownership evidence. “It works with legacy provider” is useful evidence, but it is not a root-cause report.

Official references