OpenSSL on GitHub: a source-only TLS, DTLS and QUIC toolkit mirrored from a private repository

One tree produces libssl, libcrypto and the openssl command

OpenSSL is three deliverables built from one C source tree under the Apache License 2.0. libssl implements every TLS protocol version up to TLSv1.3 (RFC 8446), DTLS up to DTLSv1.3 (RFC 9147), and QUIC version 1 (RFC 9000). libcrypto is the general purpose cryptographic library underneath it, and it can be used on its own by programs that never open a TLS connection. The third piece is the openssl command line tool.

The command line tool is the part most people meet first. It creates key parameters, X.509 certificates, certificate signing requests and CRLs, calculates message digests, encrypts and decrypts data, runs SSL, TLS and DTLS client and server tests, runs QUIC client tests, and handles S/MIME signed or encrypted mail. A cryptographic module validated to conform with FIPS standards is also part of the toolkit. OpenSSL descends from the SSLeay library written by Eric A. Young and Tim J. Hudson, which is why the copyright runs back to 1995.

The project ships source tarballs and no binaries

For production use, the OpenSSL project distributes official releases only as source tarballs from openssl-library.org/source/. It does not distribute the toolkit in binary form. That is the single biggest practical fact about getting OpenSSL, and it splits readers into three groups.

On Linux and other Unix systems, the project's own recommendation is to link against the precompiled shared libraries provided by your distributor or vendor, which means your OpenSSL version is whatever your distribution ships and patches. On Windows and other systems, precompiled builds come from third parties, and the project keeps a list of them on the Binaries page of its wiki; the project does not produce those builds itself, so the trust decision is yours. Everyone else builds from source. The cost of that third path is owning updates: when a fix lands in a new release, nobody pushes it to a self-built copy.

GitHub is a public mirror of a private repository

The main OpenSSL Git repository is private. The GitHub repository is a public mirror that is updated automatically from it on every commit, so it carries the full project history and the default branch is master. For testing and development, a clone gives you that history:

git clone https://github.com/openssl/openssl.git

Contributing works differently. All development now happens through GitHub pull requests, so a contributor forks the mirror and clones the fork instead:

git clone https://github.com/yourname/openssl.git

The CONTRIBUTING.md file covers the process, and STYLE.md and REVIEW.md sit beside it at the top level. CI runs on GitHub Actions, with workflows named for an operating system matrix (os-zoo), provider compatibility, QUIC interoperability and a daily run-checker. A clone of master is development code. The last push to the mirror was on November 2, 2026, and master moves ahead of the tagged releases.

Building means reading INSTALL.md plus a platform NOTES file

The top-level README sends builders to INSTALL.md for detailed build and install instructions, and that file is amended for some platforms by separate notes. The notes linked from the README cover UNIX-like platforms, Android, Windows, DOS with DJGPP, OpenVMS, Perl and Valgrind. The repository root also carries NOTES-C99.md, NOTES-NONSTOP.md, NOTES-POSIX.md and NOTES-SANITIZERS.md.

The build entry points are the Configure script and config at the root, with platform targets under Configurations/ and VMS-specific files under VMS/ alongside config.com. The top-level README sends you to those files rather than giving one universal build line, because the exact steps depend on the platform. Notes on Perl and on Valgrind are linked next to the platform notes, so read INSTALL.md, NOTES-PERL.md and the NOTES file for your platform together before running anything. The trade-off of a source build is that every one of those platform details becomes yours to get right.

Five documentation lines are live at once

OpenSSL keeps manual pages online for the master branch and every current stable line: 4.1, 4.0, 3.6 and 3.5. The newest tags show how close together those lines move. OpenSSL 4.0.3 was released on September 29, 2026, 4.1.0-beta2 followed on October 9, and OpenSSL 4.1.0 was released on October 23, 2026.

The consequence is that any answer about an API or a command option has to name its version. Behavior documented for 4.1 may not hold on the 3.5 your distribution ships, and the reverse. The README's upgrade pointer is the ossl-guide-migration(7ossl) manual page, framed around moving to OpenSSL 3.x from earlier versions. For changes between 3.x and 4.x, check CHANGES.md and NEWS.md at the top of the tree and the manual pages for the exact line you are moving to before you rebuild dependent software.

Providers, FIPS and QUIC each have their own README

Three subsystems are complex enough to have separate top-level documents. README-PROVIDERS.md covers the provider architecture, README-FIPS.md covers using the FIPS validated module, and README-QUIC.md covers the QUIC implementation. The OpenSSL Guide adds tutorial and introductory pages on major topics, and the demos/ directory holds source code examples for various capabilities.

The repository root also lists entries named oqs-provider, gost-engine, krb5 and cloudflare-quiche next to a .gitmodules file, along with external/ and exporters/ directories. The project also runs a CI workflow dedicated to provider compatibility. For a reader deciding how to use FIPS mode or a third-party algorithm provider, start with README-PROVIDERS.md and README-FIPS.md rather than the main README, which only points at them.

The wiki is quiet and export rules are the user's responsibility

Not every support channel is equally alive. The project's own README calls its GitHub Wiki currently not very active, which matters because the Binaries list for Windows users lives there. The manual pages at docs.openssl.org and the files in the source tree are the maintained references. For help, SUPPORT.md explains which channel fits which kind of request.

There is also a legal limit the project spells out. A number of nations restrict the use or export of cryptography, and anyone potentially subject to those restrictions is told to seek legal advice before developing or distributing cryptographic code. The Apache License 2.0 permits commercial and non-commercial use as long as its conditions are met, but it does not settle export law. Teams that redistribute OpenSSL inside a product need to handle both questions separately.

Editorial conclusion

Build OpenSSL from this repository if you develop against it, contribute patches, or need a release line your platform vendor does not ship. On Linux and other Unix systems, link against the shared libraries your distributor provides instead, and on Windows take a binary from a third party on the project's Binaries wiki page. Before upgrading across the 3.x to 4.x boundary, read CHANGES.md, NEWS.md and the manual pages for the exact line you target, since master, 4.1, 4.0, 3.6 and 3.5 are all documented separately.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes