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.

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.

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
- OpenSSL 4.0 for NGINX: Upgrading openssl-nginx from 3.x to 4.0 — what changed in the major version upgrade and how to migrate
- Post-Quantum Cryptography with NGINX: ML-KEM and Hybrid TLS — how openssl-nginx enables quantum-safe connections today
- TLS Configuration for NGINX: Getting A+ on SSL Labs — the TLS config that pairs perfectly with openssl-nginx
- How to Optimize NGINX and Angie for Maximum Performance and Security — the full performance and hardening guide