nginx | 05/12/2026 | By Thijs Eilander

OpenSSL 4.0 for NGINX: Upgrading openssl-nginx from 3.x to 4.0 — What Changes and Why It Matters

If you run a web server — even a small one — OpenSSL is quietly working behind the scenes every single second. It’s the library that encrypts your visitors’ connections, validates your HTTPS certificate, and makes the little padlock in the browser actually mean something.

Most people never think about it. It just works. Until it doesn’t — or until a major new version ships and you have to decide: do I upgrade, and what does that actually mean for my server?

We just upgraded our openssl-nginx package — our dedicated, stripped-down build of OpenSSL made specifically for NGINX and Angie — from OpenSSL 3.x to OpenSSL 4.0. This post explains what that means, why we did it, what you gain, what you give up, and how to upgrade safely. No PhD in cryptography required.

OpenSSL 4.0 NGINX upgrade — openssl-nginx dedicated OpenSSL build security padlock
openssl-nginx 4.0 brings post-quantum cryptography, a cleaner API, and a smaller attack surface to your web server

First: What Is openssl-nginx?

Your Linux server already has OpenSSL installed. It’s used by everything — SSH, your mail server, Python scripts, package managers. That’s great for general-purpose use. But it also means the system OpenSSL has to be conservative: it can’t be optimized for one specific thing, it can’t drop legacy support that other apps depend on, and it can’t be updated freely without risking breaking unrelated software.

openssl-nginx is exactly that. It’s a separate OpenSSL build that lives alongside your system OpenSSL without touching it. NGINX and Angie link against this dedicated build, and your system stays completely unaffected. Think of it like giving your web server its own private engine — the car still uses the road like everything else, but under the hood it’s tuned differently.

Read more: openssl-nginx: The Dedicated OpenSSL Built Just for NGINX and Angie.

OpenSSL 4.0 — What Actually Changed?

OpenSSL 4.0 is a major version bump, and major version bumps mean two things: new capabilities and breaking changes. Let’s look at both.

What’s New in OpenSSL 4.0

  • Post-Quantum Cryptography (PQC) built-in — ML-KEM and related post-quantum algorithms are now first-class citizens. No bolt-ons, no experimental flags.
  • Cleaner API — Years of deprecated, dusty old functions have been removed. Smaller, easier to audit, less likely to contain bugs from 1998.
  • Removed legacy algorithms — MD4, RC2, RC4, DES, Blowfish gone. If you’re not using them (and you shouldn’t be), this is a good thing.
  • Better TLS 1.3 internals — Session resumption, 0-RTT, and handshake performance refined under the hood.
  • Smaller binary footprint — Less code means faster load times, less memory, and a smaller attack surface.

What Was Removed

  • SSLv2 / SSLv3 support — Already disabled in 3.x, now fully gone from the codebase.
  • Many deprecated API calls — Custom NGINX modules built against older OpenSSL headers may need updating.
  • Certain legacy cipher suites — RC4-based and export ciphers are history.
  • no-ssl2, no-ssl3, no-capieng build flags — These compile-time flags no longer exist; the features are simply absent.

The Pros: Why Upgrading to OpenSSL 4.0 Is Worth It

  • Future-proof security — Post-quantum cryptography is no longer a buzzword. Chrome has been doing hybrid ML-KEM key exchange since 2024. With OpenSSL 4.0, your NGINX server can natively participate without patches.
  • Smaller and faster — Removing dead code means a smaller binary, faster load, and less memory usage. On high-traffic servers handling thousands of TLS handshakes per second, this matters.
  • Smaller attack surface — Removing MD4, RC2, Blowfish means fewer places for vulnerabilities to hide.
  • Long-term support target — OpenSSL 3.x LTS support ends. The project is clearly moving to 4.x. Upgrading now, while things are stable, is better than scrambling when a critical CVE drops.
  • Better TLS 1.3 performance — The internal TLS 1.3 engine has been refined. Session resumption is cleaner, 0-RTT is better handled.

The Cons: What to Watch Out For

  • Breaking API changes — Custom NGINX modules using OpenSSL’s C API directly may need updates. Standard modules in the myguard repository are already updated.
  • Legacy cipher suites gone — TLS 1.0, RC4, export-grade ciphers are completely unavailable. For virtually all modern deployments this is fine.
  • Newer codebase, less battle-tested — OpenSSL 3.x has years of production mileage. OpenSSL 4.0 is newer. If you run critical financial or healthcare systems, waiting a quarter before adopting is reasonable.

How to Upgrade: Step by Step

# Step 1 — Check your current version
dpkg -l openssl-nginx
nginx -V 2>&1 | grep -i openssl

# Step 2 — Update package lists
apt update

# Step 3 — Upgrade openssl-nginx (system OpenSSL is NOT touched)
apt install openssl-nginx

# Step 4 — Test config and reload
nginx -t && systemctl reload nginx
# or: angie -t && systemctl reload angie

# Step 5 — Verify
nginx -V 2>&1 | grep -i openssl
# Should show: OpenSSL 4.0.x (openssl-nginx)

Who Should Upgrade — and Who Should Wait?

Upgrade now if you run a standard modern web server (WordPress, static sites, APIs), use only TLS 1.2 and TLS 1.3, and want post-quantum TLS readiness.

Wait and test first if you use custom-compiled NGINX modules linking against OpenSSL directly, need to support very old clients with TLS 1.0 or legacy ciphers, or run a FIPS-compliant environment that hasn’t validated the 4.0 provider yet.

NGINX security with OpenSSL 4.0 openssl-nginx upgrade — hardened web server configuration
OpenSSL 4.0 in openssl-nginx: post-quantum ready, legacy-free, smaller attack surface

Frequently Asked Questions

Will upgrading openssl-nginx break my system OpenSSL?
No. openssl-nginx is a completely separate installation that lives in its own directory. It does not replace or interfere with the system OpenSSL package. SSH, mail, Python, and everything else on your server continues to use the system OpenSSL unchanged.
Do I need to change my NGINX configuration after upgrading to OpenSSL 4.0?
In most cases, no. If you’re already using TLS 1.2 and TLS 1.3 with modern cipher suites, your config works as-is. The only change needed is if your config references legacy ciphers (RC4, DES, export-grade) — those should be removed.
What is the difference between system OpenSSL and openssl-nginx?
System OpenSSL (libssl3 on Debian/Ubuntu) is used by many applications and must stay conservative. openssl-nginx is a separate, purpose-built OpenSSL compiled with specific flags for web server use — no legacy ciphers, optimised for TLS performance, linked only by NGINX and Angie.
Is OpenSSL 4.0 ready for production use?
Yes, for standard web server workloads. OpenSSL 4.0 is a stable release. The main consideration is that 3.x has more production mileage. If you’re risk-averse with a critical system, waiting a few months is reasonable. For most servers, upgrading now is fine.
Does OpenSSL 4.0 support post-quantum cryptography?
Yes — this is one of the headline features. ML-KEM and other NIST-standardized post-quantum algorithms are built in. Combined with NGINX or Angie, you can configure hybrid TLS that protects connections against both classical and quantum computer attacks.
Can I downgrade openssl-nginx if something breaks?
Yes. Because openssl-nginx is a separate package, you can install the previous version from the myguard repository with apt install openssl-nginx=3.x.x. Use apt-cache policy openssl-nginx to see available versions, then reload NGINX or Angie.

Related Posts