Home / Alt manpages / openssl-version(1ssl)

  • openssl-version(1ssl)
  • OpenSSL command
  • linux

Read OpenSSL Build Details with openssl version

When a TLS bug report needs an exact build fingerprint, openssl version gives you one in seconds. It reports the version your shell runs, the library it loads, the build date, install directories, compiler flags and platform settings. It only reports information, so none of these checks touch keys, certificates, services or configuration.

Allow about five minutes. You need a shell and the OpenSSL executable you want to inspect. No elevated privileges are required. The examples use the command found by your current PATH, which matters when a distribution copy and a manually installed copy coexist.

1. Identify the executable

Find the command your shell will actually run before you trust anything it prints:

command -v openssl
readlink -f "$(command -v openssl)"

The first line prints the selected command path; the second resolves a symlink where the platform provides readlink. If the command is missing, install OpenSSL using your operating system's normal package method and repeat this check. Do not assume a manpage and an executable of the same name came from the same installation.

2. Read the short version report

Print the version of the executable and the library it is using:

openssl version

On the machine used for this guide, the result is:

OpenSSL 3.6.1 27 Jan 2026 (Library: OpenSSL 3.6.1 27 Jan 2026)

The exact version and date will differ elsewhere. The parenthesised library value matters because the command can be one installation while its shared library comes from another entirely.

Checkpoint

If the two versions differ, stop before diagnosing a package or application. Check the executable path, your dynamic library search path, and the process environment first.

3. Collect the full diagnostic

Ask for every report category in one command, the report normally worth attaching to an OpenSSL bug report:

openssl version -a

It combines the individual switches:

  • -v prints the current OpenSSL version.
  • -b prints the build date.
  • -o prints internal option information.
  • -f prints compiler flags.
  • -p prints the target platform.
  • -d prints the OPENSSLDIR setting.
  • -e prints the engines directory.
  • -m prints the modules directory.
  • -r prints random seeding source settings.
  • -c prints CPU settings information.

Warning

These values describe how this copy was built and where it expects supporting files. They are not instructions to edit those directories. Do not delete, replace or recursively change anything under OPENSSLDIR, the engines directory or the modules directory just because a path looks unexpected: those changes can break applications or alter cryptographic provider behaviour.

4. Inspect one detail at a time

Use a single switch when a script or a support request needs one field. The following commands are all read-only:

openssl version -v
openssl version -b
openssl version -p
openssl version -d
openssl version -e
openssl version -m
openssl version -r
openssl version -c

The local executable, for example, reports a build platform of linux-x86_64 and an OPENSSLDIR of /home/linuxbrew/.linuxbrew/etc/openssl@3. Treat paths as output, not portable constants: a Debian package may use different directories, and a container or virtual environment may intentionally use its own installation.

The -o and -f fields are especially useful when comparing two builds. Compiler options can explain performance, portability or hardening differences, but they do not by themselves prove an application is loading this library. If the problem shows up in a service, inspect that service's actual executable and environment too.

5. Check the interface before copying examples

Display the options supported by the executable you are about to script:

openssl version -help

OpenSSL 3.6.1 lists -a, -v, -b, -o, -f, -p, -d, -e, -m, -r and -c. The installed manpage is dated for the system's OpenSSL 3.0.13 package, while the executable selected in this shell is OpenSSL 3.6.1 from Linuxbrew. That mismatch is a useful warning: read the help for the executable you will actually run, and record both versions when reporting a problem.

Do not parse the human-readable full report by assuming every line exists on every release. If automation needs a stable value, use the smallest supported command and validate its output for the specific OpenSSL versions in your fleet. Keep the command's standard output and exit status in your diagnostic record.

Common traps

  • Wrong installation: openssl version answers for the first matching executable in PATH. Use command -v and an absolute path when comparing installations.
  • Confusing package and library versions: a package manager's version describes its package, not necessarily the binary your current shell selects. Record the package query and command path separately.
  • Sharing sensitive output: the report is usually safe as a build diagnostic, but paths can reveal usernames, deployment layout or custom directories. Review it before posting publicly, and never paste private keys, passphrases or certificate files alongside it.
  • Expecting a repair: this command does not update OpenSSL, reload a daemon or fix a provider. Changing a package or service needs a separate backup and change-management step, and there is nothing to undo from the examples above because they make no state changes.

Done means

  • Executable identified. You know which openssl your shell selects.
  • Versions read. openssl version reports the executable and library versions.
  • Build details captured. openssl version -a has recorded the build and directory details.
  • Interface confirmed. openssl version -help has confirmed the options that executable supports.
  • Records kept separate. Package metadata, command paths and OpenSSL output stayed distinct.