OpenSSL

OpenSSL
openssl displaying an X.509 certificate for UEFI Secure Boot
Original authors	Eric A. Young and Tim Hudson (SSLeay)
Developer	The OpenSSL Project
Initial release	December 23, 1998 (1998-12-23)
Stable release	4.0.0 / April 14, 2026 (2026-04-14)1
Written in	C, assembly, Perl
Operating system	Unix-like systems, Microsoft Windows, OpenVMS, and other platforms
Type	Cryptography library, TLS implementation
License	3.0 and later: Apache License 2.0; earlier releases: dual OpenSSL and SSLeay licenses2
Website	www.openssl.org
Repository	github.com/openssl

OpenSSL is an open-source software library and command-line toolkit that implements the Transport Layer Security (TLS) protocol and a range of cryptographic functions. It is used by Internet servers, operating systems, application frameworks, programming-language runtimes, and embedded software to provide encrypted communications and certificate-based authentication.³⁴⁵

The project began in 1998 as a continuation of SSLeay, an earlier SSL implementation written by Eric A. Young and Tim Hudson. OpenSSL became one of the most-used TLS libraries on the Internet, particularly for HTTPS. Its security, funding, and governance came under public scrutiny after the 2014 Heartbleed vulnerability, which prompted emergency patching across the Internet, new funding for critical open-source infrastructure, and forks including LibreSSL and BoringSSL.⁶⁴⁷⁸

OpenSSL 1.1.1 added support for TLS 1.3 and was a long-term-support release.⁹¹⁰ OpenSSL 3.0, released in 2021, introduced a provider architecture, restored FIPS support through a new FIPS provider, and changed the project license to the Apache License 2.0.³ Later releases added support for QUIC and post-quantum cryptography.¹¹¹ OpenSSL 4.0, released in 2026, removed several deprecated features and introduced further incompatible changes.¹

Governance changed in 2024, when the OpenSSL Management Committee was dissolved and responsibilities were divided between the OpenSSL Foundation and the OpenSSL Corporation.¹² The codebase has also influenced derivative libraries, including LibreSSL, BoringSSL, AWS-LC, and QuicTLS.

OpenSSL originated in SSLeay, an open-source implementation of SSL developed by Eric A. Young and Tim Hudson in the 1990s. SSLeay development effectively ended when Young and Hudson joined RSA Security.⁶ In late 1998, Mark Cox, Ralf Engelschall, Stephen Henson, Ben Laurie, and Paul Sutton formed the initial OpenSSL project team to continue development of the codebase.⁶¹³ The first OpenSSL release, version 0.9.1, was announced in December 1998.¹³ In a twentieth-anniversary retrospective, Cox wrote that all of the founding team except Henson were core developers of the Apache HTTP Server.⁶

During the 2000s, OpenSSL was deployed across Unix-like operating systems, web servers, mail servers, VPN software, and application runtimes. Its permissive licensing allowed use in both open-source and proprietary software, and the openssl command-line program became a common tool for generating keys, creating certificate-signing requests, inspecting certificates, testing TLS endpoints, and performing other cryptographic operations.¹⁴¹⁵

OpenSSL was also embedded as infrastructure inside larger systems. This deployment pattern meant that defects in the library could affect many unrelated applications at once, while major API or ABI changes could require coordinated work by operating-system distributions, language runtimes, and application maintainers.⁵

On April 7, 2014, OpenSSL disclosed Heartbleed, a bounds-checking error in the implementation of the TLS heartbeat extension. The bug was assigned the identifier CVE-2014-0160, affected OpenSSL 1.0.1 through 1.0.1f, and allowed an attacker to read up to 64 KB of memory from a vulnerable process per request.¹⁶¹⁷¹⁸ Because OpenSSL was deployed in HTTPS servers and other TLS-enabled software, Heartbleed triggered an Internet-wide remediation effort involving patching, certificate replacement, key rotation, and incident response.¹⁹²⁰²¹ Cryptographer Bruce Schneier described the disclosure as catastrophic, writing that on a scale of one to ten "this is an 11."⁸ A challenge run by Cloudflare in the days after disclosure produced four independent extractions of TLS private keys from a vulnerable test server, confirming that Heartbleed could expose long-term secret material rather than only session data.²²

Heartbleed also reframed the public discussion of open-source infrastructure funding. The disclosure followed several months of heightened attention to Internet encryption after Snowden-era reporting on intelligence-service interference with cryptographic standards.²³ Wired reported that, at the time of disclosure, OpenSSL was maintained by a small team and had only one full-time developer.⁴ Steve Marquess of the OpenSSL Software Foundation wrote that pre-Heartbleed donations to the foundation had averaged about US$2,000 per year, an amount inadequate to support full-time engineering on a project of OpenSSL's scope.²⁴ Shortly after the disclosure, the Linux Foundation announced the Core Infrastructure Initiative, backed by large technology companies, to fund OpenSSL and other open-source components.⁴⁷

The incident prompted alternative approaches to OpenSSL maintenance and API design. OpenBSD developers created LibreSSL as a cleaned-up fork of OpenSSL, and Google announced BoringSSL for its own products and infrastructure later in 2014.²⁵²⁶

The OpenSSL 1.1.x series made many internal structures opaque, moved applications toward accessor functions, and reduced reliance on direct access to implementation details. OpenSSL 1.1.1, released in September 2018, added support for TLS 1.3, which the Internet Engineering Task Force had published as RFC 8446.⁹¹⁰ OpenSSL 1.1.1 was a long-term-support release and was supported until September 2023.²⁷

The shift to opaque data structures and stricter interfaces improved maintainability but created compatibility work for applications that had used OpenSSL internals directly. The same pattern of architectural change accompanied by downstream transition costs continued in the OpenSSL 3.x series.

Public planning for OpenSSL 3.0 began several years before its release; a 2019 status update from the project described the release as one of the largest engineering efforts in OpenSSL's history and outlined the goals of provider-based algorithm loading, FIPS support, and an updated license.²⁸ OpenSSL 3.0 was released on September 7, 2021. It was the first OpenSSL release under the Apache License 2.0 and introduced a provider architecture that allowed cryptographic algorithm implementations to be loaded from providers rather than being only built into the core library.³ The OpenSSL project described 3.0 as a release that was not fully backward compatible with OpenSSL 1.1.1, although most applications that worked with 1.1.1 were expected to work after recompilation, possibly with deprecation warnings.³

OpenSSL 3.0 also introduced the new FIPS provider. The project submitted the OpenSSL 3.0 FIPS module for FIPS 140-2 validation in 2021.²⁹ In 2025, OpenSSL announced that version 3.1.2 of the OpenSSL FIPS Provider had achieved FIPS 140-3 validation, with certificate #4985 valid until March 10, 2030.³⁰

OpenSSL 3.5, released in April 2025, was designated as the next long-term-support release after 3.0. The project said 3.5 would be supported until April 8, 2030, while OpenSSL 3.0 would receive full support until September 7, 2025 and security fixes until September 7, 2026.¹¹ OpenSSL 3.5 added support for post-quantum cryptographic algorithms and server-side QUIC.³¹

OpenSSL 4.0 was released on April 14, 2026. The project described it as a feature release with potentially incompatible changes.¹ The release removed or changed several deprecated behaviors and added new cryptographic and protocol features.¹ Under the release strategy in force at the time, non-LTS releases after 3.5 were supported for a minimum of 13 months, while new LTS releases were to be designated every two years and supported for at least five years.²⁷

OpenSSL is built around two libraries: libcrypto and libssl. Libcrypto provides cryptographic primitives and supporting functions, including message digests, symmetric ciphers, public-key cryptography, random-number generation, certificate parsing, and encoding utilities. Libssl implements the SSL and TLS protocol layers and uses libcrypto for the underlying cryptographic operations.¹⁴¹⁵

Libcrypto exposes input and output through the BIO abstraction, which presents a uniform interface to sockets, files, memory buffers, and filter chains such as base64 or digest computation.¹⁴¹⁵ Asymmetric keys, certificates, and algorithm parameters are wrapped through the EVP family of high-level interfaces, which the project recommends in preference to the older algorithm-specific functions.³²

Applications can use OpenSSL directly through its C API or indirectly through bindings in other programming languages and frameworks. Higher-level libraries, web servers, mail servers, VPNs, and application runtimes use OpenSSL as their TLS or cryptographic backend.¹⁴⁵

The openssl command-line program exposes library functions through a shell interface. It can generate private keys, create and inspect certificates, produce certificate-signing requests, test TLS handshakes, compute digests, encrypt and decrypt data, and perform certificate-authority functions.¹⁴¹⁵ The s_client and s_server subcommands act as minimal client and server implementations and are commonly used to debug TLS endpoints.¹⁴ Production applications normally use the OpenSSL libraries directly rather than invoking the command-line utility.

OpenSSL 3.0 introduced a provider architecture for cryptographic algorithm implementations. Providers can supply implementations of algorithms and can be selected by applications or configuration. The architecture was intended to make algorithm implementations more modular and to support FIPS-validated implementations, legacy algorithms, and third-party providers.³³² Providers replaced the older ENGINE interface, which had served the same role of allowing alternative cryptographic backends, including hardware accelerators, in pre-3.0 releases.³²

The provider model also changed the way applications interact with some cryptographic functionality. The OpenSSL project advised developers to migrate away from deprecated low-level APIs and toward higher-level interfaces such as the EVP APIs where possible.³³²

OpenSSL supports a range of cryptographic algorithms across several categories:

Ciphers

AES, Blowfish, Camellia, ChaCha20, Poly1305, SEED, CAST-128, DES, IDEA, RC2, RC4, RC5, Triple DES, GOST 28147-89,³³ and SM4.

Cryptographic hash functions

MD5, MD4, MD2, SHA-1, SHA-2, SHA-3, RIPEMD-160, MDC-2, GOST R 34.11-94,³³ BLAKE2, Whirlpool, and SM3.

Public-key cryptography

RSA, DSA, Diffie–Hellman key exchange, elliptic-curve variants of these (ECDSA, ECDH), and Ed25519 and X25519 from the Curve25519 family.¹⁴⁵

Post-quantum cryptography

From OpenSSL 3.5, the project added support for post-quantum key encapsulation and signature algorithms standardized by NIST, including ML-KEM and ML-DSA.³¹

FIPS 140 is a U.S. government standard and validation program for cryptographic modules. OpenSSL has had several FIPS-related modules and validations over time. OpenSSL 1.0.2 supported use of the OpenSSL FIPS Object Module 2.0, while OpenSSL 3.x replaced the older model with the FIPS provider architecture.²⁹³⁰

The OpenSSL 3.0 FIPS Provider was submitted for FIPS 140-2 validation shortly after the OpenSSL 3.0 release.²⁹ In March 2025, OpenSSL announced that the OpenSSL 3.1.2 FIPS Provider had achieved FIPS 140-3 validation under certificate #4985.³⁰

For much of its early history, OpenSSL was maintained by a small group of volunteer and part-time developers. The project's limited resources became a public issue after Heartbleed, when coverage of the incident drew attention to the dependence of commercial and public infrastructure on lightly funded open-source components.⁴⁷²⁴

OpenSSL was historically represented by the OpenSSL Software Foundation for legal and community matters and by OpenSSL Software Services for commercial support. In 2024, the project announced a new governance framework in which the OpenSSL Management Committee was dissolved and responsibilities were divided between two co-equal entities, the OpenSSL Foundation and the OpenSSL Corporation.¹² Each organization elected a ten-member board of directors; the project described the Foundation as focused on non-commercial communities and the Corporation as focused on commercial communities.¹²

The OpenSSL Corporation's 2025 annual report stated that 2025 revenue came from commercial support contracts and that the organization ended the year close to break-even under a conservative financial model.³⁴ The Foundation also began publishing annual reports as part of a transparency effort after the governance changes.³⁵

OpenSSL follows a scheduled release strategy. Under the strategy adopted from OpenSSL 3.5 onward, the project planned new releases every April and October, a new long-term-support release every two years, and, beginning with OpenSSL 5.0, a major release every two years.²⁷ LTS releases are supported for at least five years, with the final year limited to security fixes; non-LTS releases after 3.5 are supported for at least 13 months.²⁷

OpenSSL's security history reflects the library's deployment scale. The project maintains a security policy and classifies vulnerabilities by severity, taking into account affected versions, defaults, use cases, and exploitability.³⁶ Not every OpenSSL vulnerability has had the same public impact; the incidents below involved broad deployment, private-key or plaintext exposure, or systemic consequences for the wider Internet.

In 2008, Debian disclosed that a Debian-specific patch to OpenSSL had weakened the random-number generator used by Debian and Debian-derived systems. The change, introduced in 2006, reduced the number of possible keys that could be generated, affecting SSH, TLS certificates, and other cryptographic material produced on vulnerable systems.³⁷ The defect was not in upstream OpenSSL, but the incident illustrated how downstream changes to cryptographic libraries can have severe security consequences. OpenSSL later replaced its earlier entropy-handling code with a deterministic random bit generator (DRBG) consistent with NIST guidance.¹⁴

Heartbleed is the most prominent OpenSSL vulnerability by public impact. It was caused by a missing bounds check in the TLS heartbeat implementation and allowed attackers to read memory from vulnerable servers and clients.¹⁶¹⁷ At disclosure, Netcraft estimated that about half a million trusted HTTPS servers were vulnerable.¹⁹ Cloudflare's public challenge demonstrated that the bug could be used to extract TLS private keys, not only session data.²² Remediation included upgrading OpenSSL, restarting affected services, revoking and replacing certificates, and rotating potentially exposed credentials.²⁰²¹

OpenSSL has disclosed many vulnerabilities besides Heartbleed; most have been addressed through the project's security-advisory process.³⁸ A 2003 issue in OpenSSL 0.9.6k allowed certain malformed ASN.1 sequences to trigger excessive recursion that could crash a vulnerable process.³⁸ An OCSP-stapling parsing flaw disclosed in 2011 (CVE-2011-0014) affected OpenSSL 0.9.8h–0.9.8q and 1.0.0–1.0.0c and could be used either as a denial-of-service vector or, depending on the calling application, to read adjacent memory.³⁹ An ASN.1 BIO heap-overflow vulnerability disclosed in April 2012 (CVE-2012-2110) affected applications that used the ASN.1 read functions on untrusted DER input.⁴⁰ In February 2013, Royal Holloway researchers Nadhem AlFardan and Kenny Paterson disclosed the "Lucky Thirteen attack" (CVE-2013-0169), a timing attack against CBC-mode cipher suites in SSL, TLS, and DTLS that affected OpenSSL among other implementations.⁴¹ In June 2014, OpenSSL fixed a ChangeCipherSpec injection vulnerability (CVE-2014-0224) that could allow a man-in-the-middle attack in limited circumstances when both client and server were vulnerable.⁴² In March 2015, OpenSSL fixed a denial-of-service vulnerability (CVE-2015-0291) caused by handling of the signature_algorithms extension in ClientHello during renegotiation.⁴³ In 2016, OpenSSL fixed a high-severity issue involving Diffie–Hellman small subgroups (CVE-2016-0701) that could permit key recovery in particular configurations.⁴⁴

OpenSSL's role as a general-purpose TLS and cryptography library has produced several forks and derivative projects. These were generally created to meet different security, governance, API-stability, or product-integration requirements rather than to replace OpenSSL outright.⁵

Agglomerated SSL, or assl, was an OpenBSD-related wrapper project created by Marco Peereboom to provide a simpler interface on top of OpenSSL's API. It was later superseded by the LibreSSL effort and is no longer central to the OpenSSL ecosystem.⁴⁵

In April 2014, after Heartbleed, members of the OpenBSD project forked OpenSSL 1.0.1g to create LibreSSL.²⁵ OpenBSD developers said the fork was motivated by auditability, removal of obsolete code, safer defaults, and a desire to simplify the codebase. Early reporting described the project as a cleanup of OpenSSL, including removal of large amounts of unused or legacy code.⁴⁶ LibreSSL became the TLS library in OpenBSD and was later made available as LibreSSL Portable for other operating systems.

In June 2014, Google announced BoringSSL, another OpenSSL-derived library.²⁶ Unlike OpenSSL, BoringSSL is not intended to provide a stable general-purpose API for third-party operating-system distributions. It is developed for Google's own products and infrastructure, including Chromium and Android-related uses. Google said it expected to continue exchanging fixes with OpenSSL and LibreSSL where appropriate.⁴⁷

AWS-LC is a general-purpose cryptographic library maintained by Amazon Web Services. It is based on code from OpenSSL and BoringSSL and is used in AWS cryptographic software.⁴⁸ The project reflects a pattern in which large infrastructure providers maintain TLS and cryptographic libraries adapted to their own platform, performance, FIPS, and operational requirements.

QuicTLS is an OpenSSL-derived fork created to provide QUIC-related TLS APIs before comparable support was available in OpenSSL releases.⁴⁹ It was used by some projects that wanted OpenSSL compatibility together with the QUIC APIs needed for HTTP/3 development. OpenSSL later added QUIC functionality in the 3.x series, including client-side QUIC in OpenSSL 3.2 and additional QUIC support in later releases.³¹

OpenSSL's API history, release cadence, and role as a dependency for many unrelated applications have made major version transitions difficult. Compatibility concerns appeared during the move to OpenSSL 1.1.x, the OpenSSL 3.0 provider architecture, and later QUIC-related API work.³⁵⁰

OpenSSL has not guaranteed source or binary compatibility across all major versions. The 1.1.x series made many structures opaque and required applications to use accessor functions rather than direct structure access. OpenSSL 3.0 introduced provider-based algorithm loading, a new FIPS model, and deprecation of many older APIs.³³² These changes were intended to improve maintainability, extensibility, and compliance support; they also required software maintainers and operating-system vendors to update dependent packages.

The OpenSSL 3.0 transition combined a new provider architecture, relicensing under Apache-2.0, and a new FIPS provider. Red Hat described the work of bringing OpenSSL 3.0 into Fedora and Red Hat Enterprise Linux as a substantial transition involving rebuilds, compatibility patches, and adjustments by dependent packages.⁵⁰ Some users and downstream projects reported performance regressions or compatibility problems after moving from OpenSSL 1.1.1 to OpenSSL 3.x, particularly in workloads involving repeated parsing, key loading, or provider-related operations.³

OpenSSL's handling of QUIC support became a recurring criticism among HTTP/3 and QUIC implementers. QUIC requires TLS library support for functions that differ from conventional TLS-over-TCP use. BoringSSL and other libraries added QUIC-related APIs earlier, while OpenSSL delayed adoption of the commonly used API and later developed its own approach.⁵¹⁵² The delay contributed to the use of QuicTLS by projects that wanted OpenSSL compatibility together with QUIC APIs.⁴⁹

OpenSSL releases before 3.0 are covered by the dual OpenSSL and SSLeay licenses.² The older OpenSSL license included advertising-clause-style language and was incompatible with the GNU General Public License without an exception, which led some GPL-licensed projects either to add an explicit OpenSSL exception or to use alternative TLS libraries such as GnuTLS or Network Security Services.⁵³

In 2015, the project announced a relicensing effort that required most contributors to sign contributor license agreements. The relicensing process was completed before the OpenSSL 3.0 release, and OpenSSL 3.0 and later releases are licensed under the Apache License 2.0.⁵⁴³²