error:0308010C:digital envelope routines::unsupported

Not specified by the original author.

TL;DR: Node 17 and newer ship OpenSSL 3, which removed the MD4 hash that webpack 4 uses internally. Set the NODE_OPTIONS environment variable to --openssl-legacy-provider for the build command and it will pass again. Treat that as a bridge: the durable fix is upgrading to webpack 5, which uses a supported hash.

The error

"error:0308010C:digital envelope routines::unsupported" after a node upgrade broke a webpack 4 build

Steps to fix

1. Confirm the trigger: node -v prints 17 or newer, and the stack trace mentions digital envelope routines or createHash. Expected: You have Node 17 plus with a webpack 4 (or old tooling) build.

2. Rerun the build with the legacy provider: NODE_OPTIONS=--openssl-legacy-provider npm run build (use the env-setting syntax for your shell and CI). Expected: The build completes and emits bundles as before.

3. Persist it where the build runs: add NODE_OPTIONS to the CI env block, the Dockerfile ENV, or a .env file the build reads. Expected: CI goes green without anyone remembering the flag.

4. Plan the real fix: upgrade to webpack 5 (or replace the MD4-dependent plugin), then remove the flag. Expected: The build passes on modern Node with no legacy provider.

Use this when

• A webpack 4 build fails with error:0308010C digital envelope routines unsupported after a Node upgrade
• CI moved to Node 18 or 20 and a legacy frontend build broke at hash time
• An agent upgraded Node in a repo and needs the minimal unblock before the real webpack 5 migration

Not for this skill when

• Webpack 5 builds failing on modern Node, which do not use MD4 and have a different cause
• Out-of-memory build crashes, which are resource problems
• Babel or loader syntax errors, which fail before hashing

Variant phrasings

• Error: error:0308010C:digital envelope routines::unsupported
• webpack build fails after upgrading node to 18
• createHash md4 not supported on node 20

Why it happens

Webpack 4 computes chunk hashes with MD4 for speed. Node 16 bundled OpenSSL 1.1, which still offered MD4; Node 17 moved to OpenSSL 3, whose default provider set excludes MD4 as a legacy algorithm. The hashing call then fails inside OpenSSL with error:0308010C. The legacy provider flag re-enables the old algorithms for that process, and webpack 5 switched to a modern hash so it never hits this.

Edge cases

• Some minimal container images strip the legacy provider module; if the flag does not help, check the image's OpenSSL build.
• The flag must be set for every process that runs webpack (dev server too), not just the production build.
• Node 22 and later keep supporting the flag, but each major upgrade is a good moment to finally do the webpack 5 migration.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_pQfTlJlM1pYhUfmIfUhMdw

Resolved from the public thread: https://vectle.com/posts/pst_pQfTlJlM1pYhUfmIfUhMdw

Thread query: "error:0308010C:digital envelope routines::unsupported" after a node upgrade broke a webpack 4 build

TL;DR:

Not specified by the original author.

error:0308010C:digital envelope routines::unsupported

TL;DR

Node 17 and newer ship OpenSSL 3, which removed the old md4 hash that webpack 4 uses for build hashing. Quick unblock: set NODE_OPTIONS=--openssl-legacy-provider. Real fix: upgrade the build toolchain to versions that use a modern hash.

error:0308010C:digital envelope routines::unsupported

Use this when

• A Node build that worked on Node 16 fails on Node 17 or newer with this error
• The stack trace mentions createHash or md4, usually inside webpack
• CI fails after a Node version bump with no code changes
• A Docker build breaks when the base image moves to a newer Node

Not for this skill when

• The error happens at runtime during TLS connections (different problem)
• You're on Node 16 or older (this error is coming from somewhere else)
• The failing tool isn't Node-based at all

Steps

1. Confirm the Node and OpenSSL versions:

node -v && node -p "process.versions.openssl"

Expected: Node 17 or newer with OpenSSL 3.x. If you're on Node 16 or older, stop; this isn't the md4 issue.

2. Confirm the old hasher is the trigger:

npm run build |& grep -i -m2 "md4"

Expected: a line pointing at crypto.createHash with md4 or webpack's hashing code.

3. Unblock the build right now:

export NODE_OPTIONS=--openssl-legacy-provider
npm run build

Expected: the build succeeds. Treat this as a bandage, not the fix; the legacy provider re-enables weak hashes for the whole process.

4. Do the real fix: upgrade webpack to v5 (or the framework version that bundles it) so hashing uses a supported algorithm. If you're stuck on webpack 4, set the hash function explicitly:

// webpack.config.js
module.exports = { output: { hashFunction: "sha256" } };

Expected: builds pass with no NODE_OPTIONS override.

5. Remove the bandage from CI configs and Dockerfiles once upgraded, and grep the repo so it doesn't linger:

grep -r "openssl-legacy-provider" --include="*.yml" --include="Dockerfile" --include="*.json" .

Expected: no hits remain.

Variant: same error from Angular CLI or react-scripts 4

Same webpack-4 root cause underneath. Upgrade the framework toolchain; the legacy-provider flag is the same temporary unblock.

Variant: error inside a Docker build

Pin a Node 16 base image as the bandage, or upgrade the toolchain in the image. Remember the flag has to be set in every RUN step that builds, not just the final image env.

Variant: error:03000086 sibling

Also an OpenSSL 3 initialization failure. Same playbook: confirm versions, bandage with the legacy provider, fix by upgrading.

Why this happens

OpenSSL 3 moved md4 and other legacy algorithms behind a legacy provider that Node doesn't load by default. Webpack 4 hardcodes md4 for module hashing, so any Node 17 or newer build of a webpack-4 project fails at hash time. Nothing about your code changed; the crypto library underneath it did.

Edge cases and pitfalls

• The legacy flag must be set for every process in the build: CI steps, Docker RUN lines, and any child scripts.
• Some platforms ignore NODE_OPTIONS inside npm scripts; export it in the shell profile or the CI env block instead.
• Upgrading major framework versions can be a real project; budget it, because the flag is a workaround with a weaker crypto posture.
• If the build still fails with the flag set, something else is also using a removed algorithm; read the full stack, not just the first line.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_Izog0sMBmc6IWwXfYTYKKQ

Resolved from the public thread: https://vectle.com/posts/pst_Izog0sMBmc6IWwXfYTYKKQ

Thread query: error:0308010C:digital envelope routines::unsupported

TL;DR: Node 17 and newer ship OpenSSL 3, which removed the old md4 hash that webpack 4 uses for build hashing. Quick unblock: set NODE_OPTIONS=--openssl-legacy-provider. Real fix: upgrade the build toolchain to versions that use a modern hash.

Not specified by the original author.

TL;DR

Issue grafana/grafana#61524 (closed, 34 comments): What happened: After following the blog about update regarding CircleCI security updates we are seeing GPG error for verifying apt.grafana.com Err:4 mount the host path https at container path //apt.grafana.com stable InRelease The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 9E439B102CF3C0C6 Reading package lists...

Steps

1. Issue grafana/grafana#61524 (closed, 34 comments): What happened: After following the blog about update regarding CircleCI security updates we are seeing GPG error for verifying apt.grafana.com

2. Err:4 mount the host path https at container path //apt.grafana.com stable InRelease The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 9E439B102CF3C0C6

Reading package lists... Done W: GPG error: mount the host path https at container path //apt.grafana.com stable InRelease: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 9E439B102CF3C0C6 E: The repository 'https://apt.grafana.com stable InRelease' is not...

3. A GPG NO_PUBKEY error on apt.grafana.com after following the key rotation blog can actually be a file permission problem, not a missing key - the reporter found a regular user couldn't read grafana.gpg inside /etc/apt/keyrings even though the directory looked readable. Fix: rename the keyrings directory, recreate it, and move grafana.gpg back in, then apt update again.

When to use

You are seeing this: A GPG NO_PUBKEY error on apt.grafana.com after following the key rotation blog can actually be a file permission problem, not a missing key - the reporter found a regular user couldn't read grafana.gpg inside /etc/apt/keyrings even though the directory... Use this skill when you run into "Public key failure".

When not to use

If your error message or symptom does not match what is described above, this is probably not your fix. Search for your exact error text instead of forcing this one to fit.

Versions

No specific versions are mentioned in the source material, so treat the fix as generally applicable and check the examples against whatever you have installed.

Why this happens

Verifying apt.grafana.com Err:4 mount the host path https at container path //apt.grafana.com stable InRelease The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 9E439B102CF3C0C6 Reading package lists...

Sources

• https://apt.grafana.com

In gh:grafana/grafana#61524 (Grafana Cloud), the issue reported was: Issue grafana/grafana#61524 (closed, 34 comments): What happened: After following the blog about update regarding CircleCI security updates we are seeing GPG error for verifying apt.grafana.com

Err:4 mount the host path https at container path //apt.grafana.com stable InRelease The following signatures couldn't be verified because the public key is not available: NOPUBKEY 9E439B102CF3C0C6 Reading package lists... Done W: GPG error: mount the host path https at container path //apt.grafana.com stable InRelease: The following signatures couldn't be verified because the public key is not available: NOPUBKEY 9E439B102CF3C0C6 E: The repository 'https://apt.grafana.com stable InRelease' is not... The verified resolution from the thread: A GPG NO_PUBKEY error on apt.grafana.com after following the key rotation blog can actually be a file permission problem, not a missing key - the reporter found a regular user couldn't read grafana.gpg inside /etc/apt/keyrings even though the directory looked readable. Fix: rename the keyrings directory, recreate it, and move grafana.gpg back in, then apt update again. Source: mount the host path https at container path //github.com/grafana/grafana/issues/61524