yum upgrades for production use, this is the repository for you.
Active subscription is required.
If you package a TLS library for NGINX, you pick a branch and you live on it for years. Every CVE you chase, every backport you carry and every customer upgrade you have to explain comes out of that one decision.
In August 2026 there are two candidates. OpenSSL 3.5, the current Long Term Support release. And OpenSSL 4.0, which landed in April. We picked 3.5, and every NGINX build we publish links it on RPM and DEB alike. This is the arithmetic, written down properly for the first time, because at least one amateur packager has run it the other way and published the opposite conclusion.
The disagreement is narrower than it sounds. A dedicated, ABI-isolated OpenSSL built for NGINX, with its own SONAMEs, in its own directory, leaving the distribution’s library untouched, is the right architecture. It is exactly the architecture we use. The only thing in dispute is which branch that isolated library should sit on.
The support arithmetic
Start with the dates, because they settle most of it before any feature comparison begins.
| Branch | LTS | Released | Supported until |
|---|---|---|---|
| OpenSSL 3.0 | Yes | September 2021 | 7 September 2026 |
| OpenSSL 3.5 | Yes | April 2025 | 8 April 2030 |
| OpenSSL 4.0 | No | 14 April 2026 | 14 May 2027 |
Those are the project’s own numbers, from its release strategy. The policy behind them is simple: one release every two years is designated LTS and supported for at least five years, and everything else after 3.5 gets thirteen months. The 4.0 release announcement says so directly, in the project’s own emphasis: OpenSSL 4.0 is not a long term stable release.
So moving an NGINX fleet from 3.5 to 4.0 today shortens its support window from three years and seven months to eight months. Not a shorter window than you would like. A shorter window than the one you already had.
The competing post puts it the other way round:
OpenSSL 3.x LTS support ends. The project is clearly moving to 4.x.
Half of that sentence is true, and it is the half that makes the mistake easy to make. OpenSSL 3.0 is an LTS release, and its support really does end, on 7 September 2026, eight days after this is written. If 3.0 is the 3.x you have in mind, the sentence reads as both urgent and correct.
But 3.5 is also 3.x. It is also LTS. And it is supported until April 2030. The end of 3.0 is an argument for leaving 3.0, which everyone should. It is not an argument for leaving the 3.x series, because the successor inside that series outlives 4.0 by nearly three years.
Post-quantum is not the reason to move
The headline benefit offered for the jump is post-quantum cryptography:
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.
Every word of that is true of OpenSSL 3.5, and has been since 3.5.0 shipped in April 2025. ML-KEM arrived in 3.5, and the hybrid group X25519MLKEM768 is not merely available there, it is the default first key share. A current Chrome or Firefox negotiates it against a stock 3.5 build with nothing configured at all. Our NGINX post-quantum TLS guide walks through verifying it, including the one common hardening directive that silently turns it back off.
Upgrading from 3.5 to 4.0 to obtain post-quantum key exchange buys a capability you were already running. The support window it costs is real.
The one thing 4.0 genuinely adds
There is a new TLS feature in 4.0, and it is a good one. From the release notes: support for Encrypted Client Hello, RFC 9849.
ECH is the last big plaintext leak in a TLS 1.3 handshake. Without it, every connection announces the hostname it wants in the clear, where anyone on the path can read it. ECH wraps the real ClientHello inside an outer one that names only a shared cover host. On multi-tenant hosting and behind shared front ends, that is a substantial privacy gain, and it is the single best reason anybody had to look at 4.0 this year.
The post arguing for the 4.0 upgrade does not mention it once.
That is the whole trade in one line. The churn was taken, and the capability that justified it went unclaimed.
We went the other way. ECH is in our packages now, on the 3.5 LTS line, through the DEfO backport: ssl_ech_file, the $ssl_ech_status and $ssl_ech_outer_server_name variables, and an nginx-ech package that rotates keys and keeps the HTTPS DNS record in step. The ECH setup guide covers the deployment, and ech-test.getpagespeed.com runs the exact stack on a public port 443 so you can point your own browser at it before you build anything.
A feature that can be backported onto the LTS line does not justify leaving the LTS line.
What 4.0 takes away
Release notes tend to be read for what is added. This one is worth reading for what is gone:
Removed support for engines. The
no-enginebuild option and theOPENSSL_NO_ENGINEmacro are always present.
ENGINE is how OpenSSL has talked to hardware for two decades. If your private keys live in an HSM, on a smartcard, or behind any PKCS#11 token, an engine is very likely how NGINX reaches them.
The consequence is not subtle. NGINX compiles its ssl_engine directive against the ENGINE API, and when that API is absent the handler is reduced to a single line that rejects the directive. Against an OpenSSL 4.0 build, a configuration that has worked for years stops loading:
nginx: [emerg] "ssl_engine" directive is not supported in /etc/nginx/nginx.conf:5
That is a failed nginx -t, not a deprecation warning.
None of this is a secret and OpenSSL is not wrong to have done it. Providers are the replacement mechanism, and a provider-based PKCS#11 path exists. But it is a different configuration that you have to build, test and roll out, and NGINX’s own ssl_engine directive is not part of it. That is migration work, on your key material, triggered by a library upgrade that delivered no new TLS capability.
On the 3.5 line the old path simply keeps working. We ship openssl35-pkcs11, which is libp11 0.4.20, the current upstream release from August 2026, built against our openssl35. Nothing to migrate.
Upgrading a shared library is not a reload
One more thing, and this one is not aimed at anybody in particular, because it catches everyone including us.
The published upgrade procedure for the 4.0 move ends like this:
apt install <vendor-openssl-package>
nginx -t && systemctl reload nginx
nginx -V 2>&1 | grep -i openssl
Both of the last two lines are doing less than they appear to.
A reload sends NGINX a HUP. The master process re-reads the configuration; it does not re-execute itself. The TLS library was mapped when the master started, and the old one stays mapped until the master goes away. Replacing libcrypto on disk and reloading leaves every worker still serving the previous library. What you need is a restart, or a USR2 binary upgrade.
And nginx -V prints the OpenSSL string recorded at compile time. It is the right check after upgrading NGINX itself, and it cannot tell you anything about a library-only upgrade, because it will happily report the new version while the process is still running the old one. Ask the process instead:
ldd "$(command -v nginx)" | grep -i ssl
Our own packages perform the graceful binary handover when NGINX itself is upgraded, so this only bites when the TLS library moves on its own. When it does, restart rather than reload. Externally, our SSL test reports post-quantum key exchange, ECH and certificate compression as first-class results, which is the honest way to confirm what your server is actually negotiating.
Check the exit before you take the on-ramp
The FAQ accompanying the 4.0 move offers a rollback: install the previous 3.x version of the library package from the same repository.
Checked against the published package indexes on 30 August 2026, that command cannot succeed. The name it tells you to pin is the source package rather than the binary one, so it resolves to nothing at all. And in every suite, the oldest binary actually sitting in the pool is a 4.0.0 build. There is no 3.x left to go back to.
Publishing a rollback procedure without once running it is the detail that separates a packaging operation from an amateur one, and it is the cheapest possible thing to check. The rule underneath it applies to any vendor, us included. A library upgrade with a working rollback is an experiment. A library upgrade without one is a commitment. Before running the install command, it is worth spending thirty seconds establishing which of the two you are being offered.
What we ship instead
openssl35 is our ABI-isolated build of OpenSSL 3.5.8 LTS. Its own SONAMEs, its own directory, its own CVE stream tracked to April 2030. Your distribution’s OpenSSL is untouched, and everything else on the machine that links it carries on exactly as before.
Every NGINX build we publish links it, on RPM and on DEB. The Debian and Ubuntu half completed in late August 2026, which put Ubuntu 20.04 users on a supported TLS library for the first time since OpenSSL 1.1.1 went end of life in 2023. On that library you get post-quantum key exchange on by default, ECH via the backport, and TLS certificate compression under RFC 8879, on amd64 and arm64 across both package families.
The policy underneath all of it is one sentence: backport onto the LTS line, do not move a fleet to a new OpenSSL major to obtain a single feature. When something you want lands in a short-lived release, the question to ask is whether it can be carried back, not whether you should follow the larger number. This time it could be, so we did.
Getting it
On RHEL, Rocky, AlmaLinux and CentOS:
sudo dnf install https://extras.getpagespeed.com/release-latest.rpm
sudo dnf install nginx
On Debian and Ubuntu, set up the APT repository, then:
sudo apt-get update
sudo apt-get install nginx
Repository metadata is public; downloading packages needs an active subscription. Subscribe to the GetPageSpeed repository to run NGINX on OpenSSL 3.5 LTS, with post-quantum key exchange, Encrypted Client Hello and certificate compression, alongside 100+ modules built against the same library, and a support window that runs to 2030.
