Node.js 17 drops next week, and the headline change is one that’ll cause some headaches: OpenSSL 3.0 replaces OpenSSL 1.1.1.

This isn’t a minor version bump. OpenSSL 3.0 tightens restrictions on which algorithms and key sizes are allowed by default. If your application (or more likely, one of your dependencies) uses algorithms that OpenSSL 3.0 considers legacy, you’ll start seeing ERR_OSSL_EVP_UNSUPPORTED errors. No deprecation warning period — just errors.

As a Current (non-LTS) release, Node 17 won’t run in most production environments. That’s actually the point. It gives the ecosystem time to find and fix compatibility issues before OpenSSL 3.0 ships in Node.js 18 LTS, which is the release that’ll matter for production workloads.

What OpenSSL 3.0 Changes #

The short version: algorithms and key sizes that OpenSSL previously allowed by default are now restricted unless you explicitly opt in via the legacy provider.

In practice, this means:

• MD4-based algorithms are no longer available by default
• Certain smaller key sizes for RSA and other algorithms are rejected
• Some older cipher suites that were technically supported (but shouldn’t have been used) are gone

Most modern applications won’t notice. If you’re using standard TLS configurations, SHA-256, and reasonable key sizes, nothing changes. The breakage will hit applications that interface with legacy systems — older LDAP servers, aging payment gateways, anything that negotiates down to weaker cryptography.

The workaround is the --openssl-legacy-provider flag, which re-enables the deprecated algorithms. But that’s a Band-Aid; the real fix is updating the dependency or the remote system to use modern cryptography.

Node 17 uses the quictls/openssl fork rather than upstream OpenSSL directly, which adds QUIC protocol support. That’s forward-looking — QUIC underpins HTTP/3 — but unlikely to affect most developers today.

Stack Traces Get Smarter #

A smaller but genuinely useful change: fatal exception stack traces now include the Node.js version.

Node.js v17.0.0

It shows up at the top of the crash output. Simple, but anyone who’s ever tried to reproduce a bug from a crash report without knowing which Node version was running will appreciate it. If you’re running multiple Node versions across environments (staging on Node 16, some services still on 14) this eliminates one piece of guesswork.

The --no-extra-info-on-fatal-exception flag opts out if you don’t want it — useful for environments where you parse crash output programmatically and the extra line would break your parser.

V8 9.5 and Other Changes #

The V8 engine bumps to 9.5, bringing Intl.DisplayNames v2 and the Intl.DateTimeFormat dayPeriod option. Performance improvements across the board, though nothing dramatic.

npm 8 ships as the default package manager. The biggest user-facing change is that npm install now requires --legacy-peer-deps more frequently when dependency trees have conflicts. The peer dependency resolution got stricter — which is correct behavior, but expect some noise in CI pipelines during the transition.

Readline gets a Promises-based API (experimental), and Corepack continues its slow march toward becoming the standard way to manage package manager versions. Both are worth watching but not production-ready.

Should You Upgrade? #

If you’re running production on Node 16 LTS: no. Stay where you are. Node 17 is a Current release, meaning it gets 8 months of support and no long-term maintenance.

If you maintain open-source packages: yes, test against Node 17 now. The OpenSSL 3.0 breakage is the kind of thing that’s better discovered in October 2021 than in April 2022 when Node 18 LTS drops and your users start filing issues.

If you’re starting a new project with no legacy constraints: Node 16 LTS remains the right choice. Node 17 is a preview, not a recommendation.

The upgrade that actually matters is the one from Node 16 to Node 18 LTS next year. Node 17 is the canary. Treat it as such — test early, file bugs, and give your dependencies time to adapt to the OpenSSL changes.