If you’ve tried to build aws-lc NGINX in the last two years and gave up because of header collisions, missing OCSP stapling, or general handwaving about “BoringSSL forks aren’t ready” – the situation has changed. NGINX upstream landed aws-lc support in 1.29.2, OCSP stapling stopped being a real production requirement, and the only remaining obstacle to a packaged NGINX-MOD-AWS-LC is one we can name precisely. Here’s the honest current state of TLS for NGINX on Enterprise Linux in 2026.
Why we packaged aws-lc on EL
We ship aws-lc-libs and aws-lc-devel in the GetPageSpeed extras repo so users can run aws-lc on Enterprise Linux without compiling from source. The packages install isolated under /usr/lib64/aws-lc with their own SONAMEs (libcrypto-aws-lc.so.0, libssl-aws-lc.so.0), so they coexist with system OpenSSL without conflict. Builds cover EL 6/7/8/9/10, Amazon Linux 2/2023, Fedora, and openSUSE.
aws-lc is AWS’s general-purpose crypto library, derived from BoringSSL and OpenSSL. It’s the TLS stack behind a chunk of AWS infrastructure and, increasingly, third-party servers. The natural follow-up question every subscriber eventually asks is whether we’ll ship an aws-lc NGINX variant for HTTP/3. This post answers that directly. However, the path through the answer matters: most published commentary on aws-lc NGINX is two years out of date and points at problems that have since been solved.
Will GetPageSpeed ship NGINX-MOD linked against aws-lc?
Short answer: not today, but for very different reasons than you’d guess. The objections that historically blocked this combination have closed or are closing. What’s left is a maintenance and demand calculation, not a technical wall.
The big news: NGINX upstream supports aws-lc as of 1.29.2
For years, the answer to “can I build NGINX with aws-lc?” was: “only with downstream patches.” That changed in December 2025.
NGINX upstream issue #185 was closed by pluknet with a one-liner: “Closing this as AWS-LC is now supported starting with nginx 1.29.2.” Our NGINX-MOD package already builds on top of NGINX 1.30.0, so the upstream aws-lc NGINX support is sitting in the source tree we ship – it just isn’t wired up at build time.
The compile-time header collision errors people remember from 2024 (e.g. aws-lc issue #1827, where enum ssl_encryption_level_t and struct ssl_quic_method_st were redefined between aws-lc and NGINX’s old QUIC compatibility shim) are resolved upstream. Therefore, if you tried this two years ago and gave up, the situation has changed.
If you want to verify yourself today, the recipe is roughly:
# Build aws-lc with shared libraries enabled
cmake -GNinja -DBUILD_SHARED_LIBS=1 -DCMAKE_INSTALL_PREFIX=/opt/aws-lc ..
ninja install
# Configure NGINX 1.29.2+ against the installed aws-lc
./configure --with-cc-opt="-I/opt/aws-lc/include" \
--with-ld-opt="-L/opt/aws-lc/lib64 -Wl,-rpath,/opt/aws-lc/lib64" \
--with-http_v3_module
make
The compatibility shim no longer fights aws-lc’s native QUIC headers, and the resulting binary speaks HTTP/3 against modern clients.
The other historical objection (OCSP stapling) is also fading
The standard line for a decade was: “BoringSSL and aws-lc don’t implement server-side OCSP stapling, so NGINX behind it can’t ssl_stapling on;” – see Apache Traffic Server issue #3748 from 2018. Still technically true.
However, OCSP itself is being decommissioned across the public web:
- The CA/Browser Forum made OCSP optional for publicly trusted CAs as of March 15, 2024 (ballot SC-063). CRLs are the only required revocation channel now.
- Let’s Encrypt completely shut down its OCSP responder on August 6, 2025. Must-Staple support was removed in January 2025.
- Chrome never performed live OCSP checks. Firefox is transitioning away.
For the majority of subscribers using Let’s Encrypt certificates, ssl_stapling on; has been a no-op since August 2025. There’s nothing to staple.
There’s still a long tail of paid CAs publishing OCSP responses, plus some compliance regimes that mandate stapling. Those users would notice if NGINX couldn’t staple. Even so, this is no longer the universal blocker for aws-lc NGINX adoption that it used to be. For most production sites, removing ssl_stapling on; from your config and switching to the CRL-based revocation that browsers actually consult costs nothing.
What aws-lc does well in 2026
To be fair, the library is solid:
- TLS 1.3 including 0-RTT/early data. HAProxy ships aws-lc 1.65.1 in production with this enabled.
- BoringSSL-style QUIC API. Works for HAProxy today and for NGINX 1.29.2+.
- FIPS mode (separate aws-lc-fips track upstream).
- Strong throughput under contention. The HAProxy “State of SSL Stacks” survey (May 2025) measured 183k connections/sec for aws-lc, notably better than OpenSSL 3.x in multi-threaded benchmarks.
Additionally, the AWS team is responsive on integration issues. They run aws-lc as their own production crypto library at AWS’s scale, so the underlying code gets serious adversarial use every day. Stability concerns about aws-lc are usually really concerns about API stability (covered below), not about the library crashing or producing wrong output.
What aws-lc drops by design
aws-lc inherits BoringSSL’s removal of legacy ciphers, including DHE and CCM cipher suites. For server administrators, this matters only if you must serve clients without ECDHE – practically OpenSSL versions before 1.0.0 (RHEL/CentOS 5, Windows XP, Java 6 era).
EL6 ships OpenSSL 1.0.1 and EL7 ships OpenSSL 1.0.2 (after 7.4). Both have ECDHE and negotiate ECDHE-RSA-AES256-GCM-SHA384 against modern NGINX configurations without issue. Therefore, if your audience is anything more recent than RHEL 5, dropping DHE costs you nothing. Worth checking your access logs for the $ssl_cipher field if you’re unsure – in practice, almost every modern client picks an ECDHE suite first.
For a quick audit, log the cipher in use and grep:
log_format ssl_audit '$remote_addr "$ssl_protocol/$ssl_cipher" "$request"';
access_log /var/log/nginx/ssl-audit.log ssl_audit;
sudo awk -F'"' '{print $2}' /var/log/nginx/ssl-audit.log | sort | uniq -c | sort -rn | head
If you see no DHE-* entries in the top results, switching to aws-lc would not change anything client-visible on cipher negotiation.
So why aren’t we shipping NGINX-MOD-AWS-LC today?
The honest current bottleneck for aws-lc NGINX packaging isn’t a technical principle – it’s maintenance overhead:
Module rebuild matrix. aws-lc is API-compatible with OpenSSL but explicitly NOT ABI-compatible. Every TLS-touching dynamic module we ship – lua-nginx-module, ModSecurity, JWT validators, OpenTelemetry, and others – needs rebuilding against aws-lc headers, with per-module source patches. The sk_X509_NAME_find argument-count difference between aws-lc and OpenSSL, documented in our aws-lc-rpm README, is one example among several. Each module’s patch needs maintaining for as long as we ship it.
API churn. aws-lc inherits BoringSSL’s “no stable API” stance. Module patches need ongoing maintenance across aws-lc releases. There’s no STABILITY.md or semver guarantee published. For a packaging shop maintaining out-of-tree patches across many distros, this is a real ongoing cost. Moreover, when aws-lc rotates a function signature, every consumer rebuilds and re-tests – including ours.
Customer-demand check. Subscribers haven’t been asking for aws-lc-backed NGINX specifically. quictls plus HTTP/3 covers production needs today. We’re not going to invest in maintaining a parallel module-rebuild matrix ahead of demand.
Translation: this is now a commercial decision (build vs. wait for demand), not a technical one. The technical path for aws-lc NGINX is open.
What about quictls itself?
A reasonable follow-up: NGINX-MOD currently links against quictls 3.1.7, which is OpenSSL 3.1.x plus the QUIC API patches. The original quictls/openssl repository was archived on April 10, 2025 – it only ever tracked through OpenSSL 3.1.7. There’s a new project at quictls/quictls that aims to be the successor (a full fork from OpenSSL 3.3, jointly maintained by Akamai and Microsoft, with plans to land at the Apache Software Foundation).
The new project is not yet a drop-in replacement for production builds. As of April 2026 the issue tracker still shows open reports against alert handling (ssl3_dispatch_alert infinite loop), ARM assembler build failures, and missing packager documentation. It’s actively developed, but not yet at the maturity bar we’d require to swap a TLS dependency under thousands of subscribers’ nginx binaries.
So we’re staying on the archived 3.1.7 line for now. It’s a known quantity, the QUIC API behaves correctly under production load, and OpenSSL 3.1.x is still patched for security in the broader ecosystem. We re-evaluate as either the new quictls project stabilizes or aws-lc NGINX demand picks up – whichever happens first.
Where the field is heading
OpenSSL 3.5 added native QUIC APIs, but they’re incompatible with the BoringSSL-style API that the rest of the ecosystem (BoringSSL, aws-lc, ngtcp2, quiche) has used for years. Adoption is unclear.
aws-lc continues to gain integration support: HAProxy 2.9+, NGINX 1.29.2+, more on the way. The long-term unifier could be aws-lc/BoringSSL-API winning, OpenSSL 3.5 winning, or persistent fragmentation. Hard to call.
What’s clearer is that aws-lc NGINX is no longer the “doesn’t work” combination it was. It works. Whether it makes sense to ship as a packaged variant is a different question, and the answer depends on how many subscribers need it.
What to install today
For HTTP/3 NGINX on Enterprise Linux: install NGINX-MOD from extras. It’s quictls-backed, runs in production, and supports HTTP/3 today.
For aws-lc as a standalone library on EL: dnf install aws-lc-libs aws-lc-devel from extras.getpagespeed.com. Use it for curl, AWS SDK consumers, your own custom NGINX builds against aws-lc, or anything else that wants BoringSSL-API compatibility without disturbing system OpenSSL.
For a hardened TLS configuration in either case, see our NGINX TLS 1.3 hardening guide.
If you’re a subscriber who actively wants NGINX-MOD-AWS-LC as a shipped variant – tell us. That demand signal is what tips the build-vs-wait calculus.