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

Here’s something that should make you slightly paranoid — in a productive way. Your server’s OpenSSL is shared. Your NGINX uses it. Your SSH daemon uses it. Your Python scripts use it. Your package manager uses it to verify downloads. One OpenSSL library, doing everything for everyone, configured to be compatible with everything and optimal for nothing.

That’s like hiring a Swiss Army knife to be a chef. Sure, it can do it. But you wouldn’t trust it with your Michelin-star kitchen.

For a high-traffic web server, “configured for everything” means carrying legacy cipher support from the 90s, disabled hardware acceleration, and compile-time choices made for mail clients and package managers — not for serving 10,000 TLS connections per second.

So we built openssl-nginx: a dedicated OpenSSL build, tuned exclusively for NGINX and Angie, that ships with our packages. Here’s what it is, what it does differently, and why it matters for your server’s performance and security.

Digital padlock representing TLS security powered by openssl-nginx dedicated OpenSSL for NGINX and Angie
openssl-nginx powers the TLS layer in every NGINX and Angie package from deb.myguard.nl

The Problem With System OpenSSL

When Debian or Ubuntu packages NGINX against the system OpenSSL, they’re making conservative choices. The system OpenSSL has to work for SSH daemons, package manager signature verification, Python and Ruby crypto modules, mail servers, database connectors — hundreds of things that expect a general-purpose library.

To support all of that, system OpenSSL includes legacy cipher support (RC4, DES, old DSA algorithms), disables newer features that might break compatibility, and links against whatever version the distro froze on — which on Debian stable might be 1–2 years behind upstream.

For a web server? That’s irrelevant baggage. You’re not running RC4 in 2026. You’re not doing DSA signatures. You are, however, terminating TLS for thousands of concurrent connections — and every microsecond of handshake overhead matters.

What openssl-nginx Does Differently

openssl-nginx is compiled with one job: serving HTTPS as fast and securely as possible. Here’s what that looks like concretely.

kTLS — Kernel TLS Offload

kTLS (Kernel TLS) offloads TLS record encryption to the Linux kernel instead of doing it in userspace. Normally, your NGINX worker process copies data between kernel space and userspace for every encrypted response. With kTLS, the kernel handles encryption in the network stack directly — meaning sendfile() works with encrypted responses and your CPU load for TLS drops significantly.

openssl-nginx enables kTLS with the enable-ktls compile flag. Your distro’s OpenSSL typically doesn’t. Think of it as giving TLS its own express lane, bypassing the usual tollbooth entirely.

ec_nistp_64_gcc_128 — Faster Elliptic Curves

This compile flag enables hand-optimised 64-bit assembly implementations of the NIST P-256, P-384, and P-521 elliptic curves — the curves used in ECDHE key exchange for TLS 1.2. The hand-tuned assembly is significantly faster than generic C implementations, which directly reduces TLS handshake latency. Available on 64-bit CPUs only (amd64, arm64, ppc64el, riscv64).

RDRAND Hardware Entropy

Modern Intel and AMD CPUs have a hardware random number generator built in — the RDRAND instruction. Cryptographic operations need high-quality randomness: ephemeral TLS keys, session IDs, nonces. Hardware entropy is faster and higher-quality than /dev/urandom under load. openssl-nginx enables RDRAND by default. Your system OpenSSL may not.

ML-KEM Post-Quantum Support

openssl-nginx 4.0 is built on OpenSSL 4.0, which includes full ML-KEM support — the NIST-standardised post-quantum key encapsulation mechanism. This means NGINX automatically negotiates the X25519MLKEM768 hybrid key exchange with browsers that support it (Chrome since 2024, Firefox since 2024). Your connections are future-proofed against quantum computer attacks — today, before quantum computers are even a real threat. See our post-quantum cryptography guide for the full story.

No Legacy Bloat

Disabled at compile time: RC2, RC4, RC5, DES, MD2, MD4, IDEA, MDC2, Seed, Blowfish, CAST, Camellia, SRP, DSA, Whirlpool. Your web server doesn’t need any of these — and removing them means a smaller binary, a smaller attack surface, and zero chance of misconfiguration accidentally enabling a cipher from 1995.

QUIC for HTTP/3

openssl-nginx is built with enable-quic, providing the QUIC API that NGINX needs for HTTP/3. System OpenSSL typically lacks QUIC support, which is why NGINX from official repos often can’t do HTTP/3. With openssl-nginx, HTTP/3 works out of the box — no patching, no BoringSSL fork, no drama.

No Conflict with System OpenSSL

openssl-nginx installs as a completely separate library — libssl-nginx.so.4 and libcrypto-nginx.so.4 — alongside your system’s libssl.so.3. They coexist without conflict. Your SSH daemon, Python scripts, and everything else keep using system OpenSSL. Only NGINX and Angie use openssl-nginx. It’s like having a specialist chef in your kitchen while the rest of the team carries on with their Swiss Army knives.

Installation

# Add the myguard repository
wget -qO- https://deb.myguard.nl/gpg.key 
  | gpg --dearmor > /usr/share/keyrings/myguard-archive-keyring.gpg
echo "deb [signed-by=/usr/share/keyrings/myguard-archive-keyring.gpg] 
  https://deb.myguard.nl stable main" 
  | tee /etc/apt/sources.list.d/myguard.list
apt update

# openssl-nginx installs automatically as a dependency
apt install nginx   # or: apt install angie

# Verify NGINX is using openssl-nginx
nginx -V 2>&1 | grep -i openssl

openssl-nginx is pulled in automatically as a dependency. No special steps needed — just install NGINX or Angie from our repository and you’re already using it.

NGINX server security hardening with openssl-nginx dedicated OpenSSL build
openssl-nginx ships as a separate library — your system OpenSSL is untouched

Frequently Asked Questions

Does openssl-nginx replace my system OpenSSL?
No. It installs as separate library files (libssl-nginx.so.4 and libcrypto-nginx.so.4) that only NGINX and Angie link against. Your system OpenSSL is completely untouched — SSH, apt, Python, and everything else keep using it as normal.
Will it conflict with my existing SSL certificates?
Not at all. Certificates are just files — they work with any OpenSSL version. Your Let’s Encrypt or commercial certificates work exactly the same with openssl-nginx as with system OpenSSL.
Is kTLS safe to use in production?
Yes. kTLS has been in the Linux kernel since 4.13 (2017) and is considered stable for production use. It’s used by major cloud providers. You need Linux kernel 5.2+ for full kTLS support with TLS 1.3.
What distributions are supported?
Debian Bookworm, Debian Trixie, Ubuntu Jammy (22.04), Ubuntu Noble (24.04), and Ubuntu Resolute (26.04). Both amd64 and arm64 architectures.
What is the difference between openssl-nginx 3.x and 4.0?
openssl-nginx 4.0 is built on OpenSSL 4.0 which includes native ML-KEM post-quantum support and drops some legacy APIs and ciphers. See our upgrade guide from 3.x to 4.0 for the full changelog.
Does this work with the nginx-minimal package?
Yes. nginx-minimal, nginx, and angie all depend on openssl-nginx. It’s a dependency of all three packages, so you get the dedicated OpenSSL regardless of which package you choose.

Related Posts