If you serve HTTPS, your server is almost certainly running on OpenSSL (or a compatible implementation). You never touch it directly, yet when a flaw is found, a huge number of servers are affected. Here's what the library does and how to defend it.
Where it is used
The tricky thing about OpenSSL is that you're using it without ever having chosen it. Your app delegates TLS to the web server, the web server delegates crypto to OpenSSL, and that OpenSSL is shipped by the OS, a nested stack.
Normally this is convenient: crypto is left to a shared implementation written by experts. But when that shared library has a vulnerability, everyone who uses it is affected at once. That's what it means for a foundational-library flaw to have a wide impact.
OpenSSL vs SSL/TLS vs certificates
The names sound alike, so they get mixed up, but each plays a different role.
| Term | What it is | Example |
|---|---|---|
| SSL / TLS | The rules (protocol) for encrypting a connection. SSL is the old version; today you use TLS 1.2 / 1.3 | HTTPS is HTTP wrapped in TLS |
| OpenSSL | The program (library) that actually performs TLS and cryptographic operations, plus a bundled command-line tool | Nginx and Apache call it internally |
| Certificate | Data in which a certificate authority vouches that you own a domain. It contains a public key | Let's Encrypt issues them for free |
So OpenSSL is one tool that implements the TLS rules, and a certificate is data that tool uses during a connection. Other libraries implement TLS too (LibreSSL, BoringSSL, Windows Schannel and more), and which one you use depends on the OS and software.
Why the impact is so wide: one bug put the keys of many servers at risk
2014's Heartbleed (CVE-2014-0160) came from a small OpenSSL implementation mistake (trusting a claimed length without validating it) that let an outsider read server memory — which could include private keys and session data — a little at a time. Because OpenSSL was so widely used, a vast number of servers worldwide became targets simultaneously (full story → Heartbleed).
The lesson is clear: the lower in the stack a dependency sits, the wider the impact. So it's not just the dependencies your app imports directly — foundational libraries like OpenSSL running underneath deserve the same seriousness in monitoring and patching.
How to defend: avoid EOL, monitor foundational libraries
Know which OpenSSL your stack uses
You can't defend what you can't see. Inventory which OpenSSL (release line and version) your servers, container base images, and language runtimes each depend on.
Don't run end-of-life (EOL) versions
Once a release line is past support, new vulnerabilities found in it get no fix. If you keep running EOL, vulnerabilities stay unfixed even after they are found. Plan upgrades onto a supported line.
Include foundational libraries in CVE monitoring
App dependencies are easy to track with osv-scanner and the like, but the OS-shipped OpenSSL is easy to overlook. Make sure new CVEs in foundational libraries surface too (→ the CVE remediation playbook).
Patch promptly when it's serious
Heartbleed-class bugs are attacked the moment they're disclosed. Keep your update path light enough that foundational patches can ship same-day when the severity calls for it — not "at the next scheduled update."
Supported versions (as of October 2026)
The OpenSSL project releases a long-term support (LTS) version in April of odd-numbered years and supports it for at least five years. Non-LTS versions released after 3.5 are supported for 13 months from release.
| Line | Type | End of support |
|---|---|---|
| 4.0 | Regular | May 14, 2027 |
| 3.6 | Regular | November 1, 2026 |
| 3.5 | LTS | April 8, 2030 |
| 3.4 | Regular | October 22, 2026 |
| 3.0 / 1.1.1 / 1.0.2 | — | Ended (paid extended support from OpenSSL Corporation only) |
OpenSSL shipped by your OS is a different story. Many Linux distributions, Red Hat-based ones among them, pull in fixes without raising the version number (backporting). During the OS's support period, a package that still reports 3.0 may keep receiving fixes from the OS vendor. Don't judge "old means vulnerable" or "new means safe" from the number alone; check your OS vendor's security advisories.
How to check your own environment
Check the OS's OpenSSL
openssl version -a to see the version. For the package version, use dpkg -l 'libssl*' openssl on Debian/Ubuntu or rpm -q openssl on Red Hat-based systems. Compare that package version against your OS vendor's security advisories to see whether a fix is included.Check what your applications actually use
nginx -V for Nginx, python3 -c "import ssl; print(ssl.OPENSSL_VERSION)" for Python, and node -p process.versions.openssl for Node.js show the built-in version.Check container images too
Subscribe to OpenSSL security announcements
How to read vulnerability severity
The OpenSSL project rates its own vulnerabilities on four levels and changes how it ships fixes accordingly.
| Severity | Rough meaning | How the fix ships |
|---|---|---|
| Critical | Affects common configurations and is easy to exploit (significant leakage of server memory, theft of private keys, and so on) | A fix is released right away for every supported version |
| High | Less risky than Critical but still serious (less common configurations, client side only, and so on) | Prepared privately, then released for every supported version |
| Moderate | Limited to denial of service, uncommon protocols, and the like | Bundled into the next scheduled release |
| Low | Command-line tools only, unlikely combinations of conditions, and the like | Bundled into the next scheduled release |
A flaw like Heartbleed, where server memory can be read from outside, matches the definition of Critical. For Critical and High, start preparing the update as soon as you see the advance notice.
Our take: monitor foundational libraries with machines
You can't track foundational-library flaws on human memory. This site puts its own dependencies and foundations under machine CVE monitoring. The certificates you serve via Let's Encrypt still run their crypto through an OpenSSL-family implementation underneath, so listing the foundational libraries you never think about and monitoring them is the most direct way to prevent wide-impact incidents.
Read next
- Learn from an incident: Heartbleed (an OpenSSL flaw that put the private keys of many servers at risk)
- Related: What is Let's Encrypt (free TLS certs + auto-renewal) / Glossary: What is a CVE
- In practice: the CVE remediation playbook / monitor dependencies with osv-scanner
Sources (primary)
- OpenSSL Library, "Release Strategy" — openssl-library.org (LTS policy, end-of-support dates for each line)
- OpenSSL Library, "Security Policy" — openssl-library.org (four severity levels, advance notice)
- Red Hat, "Backporting Security Fixes" — access.redhat.com (why the version number alone doesn't tell you whether you're vulnerable)
- NIST NVD, "CVE-2014-0160" — nvd.nist.gov (Heartbleed)