Mister PKI

SSL Certificates * SSL Tools * Certificate Decoder

by Leave a Comment

Overview

You find an OpenSSL command in documentation or a troubleshooting guide, SSH to a server, run it, and receive:

Invalid command

Or perhaps the command exists, but an option shown in the documentation does not.

This is common when administering multiple Linux servers, containers, network appliances, or Windows systems. Two machines may both have OpenSSL installed while running different OpenSSL versions, loading different providers, or using builds with different features.

Instead of assuming every OpenSSL installation has the same capabilities, you can ask the installed OpenSSL binary directly.

The most useful commands are:

openssl version
openssl help
openssl list -commands
openssl list -providers
openssl list -disabled
openssl command -help

This guide shows how a system administrator can use these commands to quickly determine:

  • which OpenSSL version is actually running;
  • which OpenSSL commands are available;
  • which options a command supports;
  • which providers are loaded;
  • which cryptographic algorithms are available;
  • which features were disabled when OpenSSL was built;
  • why the same command may behave differently on two servers.

The official OpenSSL application command documentation groups commands such as x509, req, verify, s_client, pkcs12, ca, asn1parse, and rehash under the main openssl application.

OpenSSL command structure

OpenSSL uses a main executable followed by a subcommand:

openssl command options

For example:

openssl x509 -in certificate.pem -text -noout

Here:

openssl

is the main OpenSSL command-line application.

x509

is the subcommand.

And:

-in certificate.pem -text -noout

are options passed to x509.

The same pattern applies to:

openssl req
openssl verify
openssl s_client
openssl pkcs12
openssl pkey
openssl ca
openssl rehash

Each command has its own options and purpose.

For practical tutorials covering many of these individually, see the Mister PKI OpenSSL Commands Guide.

OpenSSL version compatibility

This article covers:

  • OpenSSL 3.0;
  • OpenSSL 3.1;
  • OpenSSL 3.2;
  • OpenSSL 3.3;
  • OpenSSL 3.4;
  • OpenSSL 3.5 LTS;
  • OpenSSL 4.0.

The basic command-discovery workflow works across these versions:

openssl version
openssl help
openssl list -commands
openssl command -help

However, the exact list of available commands, algorithms, providers, and options may vary by:

  • OpenSSL version;
  • operating system;
  • distribution package;
  • build configuration;
  • loaded providers;
  • FIPS configuration;
  • system cryptographic policy.

That is why checking the actual binary is often more useful than relying only on an online command list.

The official OpenSSL 3.5 command documentation specifically recommends the openssl list command for listing available subcommands.

Real-world scenario: the command works on one server but not another

Assume you manage two application servers.

On the first server, this command works:

openssl pkeyutl ...

On another server, a script fails because an expected command, option, algorithm, or provider is unavailable.

Before changing the script, determine whether the two systems are actually running equivalent OpenSSL environments.

A useful troubleshooting sequence is:

Check the executable
Check the version
List commands
Check command help
Check providers
Check algorithms
Check disabled features

Let’s walk through each step.

Step 1: Find the OpenSSL executable

On Linux:

command -v openssl

Example:

/usr/bin/openssl

You can also use:

which openssl

Resolve symbolic links:

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

This matters because a server may contain more than one OpenSSL installation.

For example:

/usr/bin/openssl
/usr/local/bin/openssl
/opt/openssl/bin/openssl

A shell script may therefore use a different version than the one you expected.

On Windows PowerShell:

Get-Command openssl

For more detail:

Get-Command openssl | Format-List Source,Version

You can also use:

where openssl

If OpenSSL is not installed on Windows, see How to Install OpenSSL on Windows.

Step 2: Check the OpenSSL version

Run:

openssl version

Example:

OpenSSL 3.5.5 27 January 2026

For much more information:

openssl version -a

This can show information including:

  • OpenSSL version;
  • build date;
  • platform;
  • compiler options;
  • OpenSSL directory;
  • engines directory where applicable;
  • provider modules directory.

When troubleshooting differences between machines, capture:

openssl version -a

from both systems.

Do not assume the operating-system version alone tells you exactly which OpenSSL package and revision are installed.

Step 3: Display OpenSSL help

Run:

openssl help

You can also run:

openssl -help

The output provides a broad command summary.

Depending on the installation, commands are grouped into categories such as:

Standard commands
Message Digest commands
Cipher commands

For administrators who simply need to remember whether the command is named pkey, pkeyutl, pkcs8, or pkcs12, this is often the fastest place to start.

Step 4: List available OpenSSL commands

For a cleaner list, use:

openssl list -commands

OpenSSL documents -commands as a way to display its standard commands.

You may see commands such as:

asn1parse
ca
ciphers
cmp
cms
crl
dgst
enc
genpkey
info
list
ocsp
pkcs12
pkcs7
pkcs8
pkey
pkeyutl
rand
rehash
req
s_client
s_server
storeutl
verify
version
x509

The exact output depends on the OpenSSL installation.

This is preferable to assuming that a command listed in documentation is necessarily available on the server you are troubleshooting.

Step 5: Put each command on its own line

For scripts or easier searching, use:

openssl list -1 -commands

The -1 option places commands in a single column.

Example:

asn1parse
ca
ciphers
cmp
cms
crl
dgst
...
verify
version
x509

This makes the output easy to use with utilities such as grep.

For example:

openssl list -1 -commands | grep '^s_client$'

Or:

openssl list -1 -commands | grep '^pkcs12$'

Step 6: Check whether a particular command exists

Suppose an automation script requires:

storeutl

Check for it:

openssl list -1 -commands | grep -Fx storeutl

A result indicates that it is present.

For shell automation:

if openssl list -1 -commands | grep -Fxq storeutl; then
    echo "storeutl is available"
else
    echo "storeutl is not available"
fi

This is useful when maintaining scripts across several OpenSSL versions or operating systems.

Another way: openssl no-command

OpenSSL provides another mechanism for testing whether a command is available.

For example:

openssl no-rsa

The behavior is unusual:

  • if the requested command or cipher exists, OpenSSL prints its name and returns a nonzero status;
  • if it does not exist, OpenSSL prints no-NAME and returns success.

The official documentation describes this primarily as a way for shell scripts to test whether a named command or cipher is available.

Because the return-code behavior is counterintuitive, administrators may find this clearer:

openssl list -1 -commands

when working interactively.

Step 7: Get help for a specific command

Every OpenSSL subcommand provides:

-help

For example:

openssl x509 -help

For certificate verification:

openssl verify -help

For certificate requests:

openssl req -help

For TLS troubleshooting:

openssl s_client -help

For private-key operations:

openssl pkey -help

This is one of the most important troubleshooting habits when working with multiple OpenSSL releases:

Check the help produced by the OpenSSL binary that will actually execute the command.

Online documentation may describe a newer version than the server has installed.

Step 8: Search a command’s help output

Some commands have dozens of options.

Search for a particular option:

openssl s_client -help 2>&1 | grep verify

Or:

openssl x509 -help 2>&1 | grep fingerprint

For a CSR-related option:

openssl req -help 2>&1 | grep addext

This quickly answers the question:

Does this exact OpenSSL installation support the option I want to use?

That is especially useful in automation where a newer option may not exist on every managed server.

Step 9: Read the local manual page

On Linux systems with OpenSSL manual pages installed, use:

man openssl

For a particular command:

man openssl-x509

Or:

man openssl-s_client

The openssl-cmds documentation explains that OpenSSL command manual pages use the openssl-command naming convention.

For example:

man openssl-dgst

This is preferable to older references that may tell you to run:

man dgst

The unprefixed manual-page aliases were deprecated beginning in OpenSSL 3.0, with the OpenSSL project planning their removal in OpenSSL 4.0.

For documentation intended to cover OpenSSL 3 and 4, use:

openssl-command

when referring to manual page names.

Step 10: Find OpenSSL documentation for your version

When researching online, make sure the documentation version matches your system.

If your server reports:

OpenSSL 3.0.x

use the OpenSSL 3.0 documentation.

For OpenSSL 3.5:

OpenSSL 3.5 documentation

For OpenSSL 4.0:

OpenSSL 4.0 documentation

A command may exist in all three releases while individual options or behavior differ.

This MisterPKI OpenSSL series therefore uses OpenSSL 3.5 LTS as its primary documentation target while noting relevant differences for OpenSSL 3.0 through OpenSSL 4.0.

Step 11: List loaded OpenSSL providers

OpenSSL 3 introduced the provider architecture.

To see which providers are currently loaded:

openssl list -providers

OpenSSL documents this as displaying loaded provider names, versions, and status.

Typical output may include:

Providers:
  default
    name: OpenSSL Default Provider
    version: 3.5.5
    status: active

Depending on configuration, you may also see providers such as:

base
legacy
fips

The exact set depends on your OpenSSL build and configuration.

Provider differences can explain why:

  • an algorithm works on one host but not another;
  • a legacy PKCS#12 file opens on one machine but fails elsewhere;
  • an old cipher is unavailable;
  • a FIPS-configured host behaves differently from a general-purpose host.

Step 12: Get verbose provider information

Run:

openssl list -providers -verbose

Verbose output provides additional provider information and parameters.

When comparing two machines, run:

openssl list -providers -verbose

on both.

This can reveal that the OpenSSL versions match but the provider configurations do not.

Step 13: List available digest algorithms

Run:

openssl list -digest-algorithms

This displays digest implementations available through the configured providers.

Common examples may include:

SHA1
SHA224
SHA256
SHA384
SHA512
SHA3-256
SHA3-384
SHA3-512

Do not assume that every algorithm printed by documentation is enabled in every environment.

To calculate a SHA-256 digest of a file, for example:

openssl dgst -sha256 package.tar.gz

The official OpenSSL 3.5 documentation recommends -digest-algorithms instead of the older -digest-commands option, which was deprecated in OpenSSL 3.0.

Step 14: List available cipher algorithms

Run:

openssl list -cipher-algorithms

This lists symmetric cipher algorithms exposed by the active providers.

The older option:

openssl list -cipher-commands

is deprecated. OpenSSL recommends:

openssl list -cipher-algorithms

instead.

This distinction is useful when writing new scripts that should remain compatible with future OpenSSL releases.

Step 15: List public-key algorithms

Run:

openssl list -public-key-algorithms

For more implementation-oriented information:

openssl list -public-key-methods

You can also query specific algorithm categories, including:

openssl list -signature-algorithms
openssl list -key-exchange-algorithms
openssl list -asymcipher-algorithms

These commands can help determine whether a server’s OpenSSL installation supports the cryptographic operation required by an application or automation script.

Step 16: List KDF and MAC algorithms

For key derivation functions:

openssl list -kdf-algorithms

For message authentication codes:

openssl list -mac-algorithms

These are particularly useful when investigating modern OpenSSL applications that use the provider APIs rather than legacy command aliases.

Step 17: List TLS groups

On versions that support the relevant list options, inspect TLS groups with:

openssl list -tls-groups

You can narrow the output by TLS version:

openssl list -tls-groups -tls1_2

or:

openssl list -tls-groups -tls1_3

This becomes useful when troubleshooting key-exchange compatibility between a client and server.

For live TLS testing, see OpenSSL s_client Commands and Examples.

Step 18: Check what was disabled at build time

Run:

openssl list -disabled

OpenSSL documents this option as listing features that were compiled out of the installation.

This is a particularly useful command when:

  • using a vendor-provided OpenSSL build;
  • troubleshooting an appliance;
  • running OpenSSL inside a container;
  • comparing distribution packages;
  • using a security-hardened build;
  • working with custom-compiled OpenSSL.

If a feature was removed at build time, changing runtime configuration may not make it available.

Step 19: List all algorithms

For a broad inventory:

openssl list -all-algorithms

OpenSSL 3.5 uses this to display multiple algorithm categories including ciphers, digests, encoders, decoders, KDFs, key exchange algorithms, MACs, random generators, signatures, and store loaders.

The output can be substantial.

For troubleshooting, it is usually better to ask a specific question:

openssl list -providers

or:

openssl list -digest-algorithms

rather than dumping every algorithm.

Step 20: Find options for a command with openssl list

OpenSSL list can also display the options recognized by another command.

For example:

openssl list -options x509

For verify:

openssl list -options verify

For s_client:

openssl list -options s_client

This is particularly useful in scripts because the output is easier to process than a full help screen.

For interactive troubleshooting, however, this is usually more readable:

openssl x509 -help

Step 21: Compare two servers

Suppose a certificate automation script works on Server A but fails on Server B.

Collect the following information from both:

openssl version -a

openssl list -1 -commands

openssl list -providers

openssl list -disabled

If the failure involves a cryptographic algorithm:

openssl list -digest-algorithms

or:

openssl list -cipher-algorithms

Save the results:

{
  openssl version -a
  echo
  openssl list -providers
  echo
  openssl list -disabled
  echo
  openssl list -1 -commands
} > openssl-inventory.txt

Do the same on the second server and compare them:

diff -u \
  server-a-openssl.txt \
  server-b-openssl.txt

This is much more useful than simply saying:

OpenSSL is installed on both machines.

The two installations may differ in important ways.

Step 22: Check a command before using it in automation

Suppose a deployment script depends on:

openssl rehash

Test for it first:

if ! openssl list -1 -commands | grep -Fxq rehash; then
    echo "ERROR: openssl rehash is unavailable" >&2
    exit 1
fi

Then execute:

openssl rehash /path/to/trust

See OpenSSL rehash: Create a Hashed CA Certificate Directory for the complete workflow.

The same approach works for other commands:

required_commands=(
  pkey
  req
  verify
  x509
)
for cmd in "${required_commands[@]}"; do
  if ! openssl list -1 -commands | grep -Fxq "$cmd"; then
    echo "Missing OpenSSL command: $cmd" >&2
    exit 1
  fi
done

This allows automation to fail with a useful message before reaching a certificate operation.

Step 23: Check an option before using it

Command availability is only half of the compatibility question.

A command may exist while an individual option does not.

For example:

if openssl req -help 2>&1 | grep -q -- '-addext'; then
    echo "The req command supports -addext"
else
    echo "The req command does not support -addext"
fi

This technique is useful for scripts intended to run across multiple OpenSSL 3.x releases.

For long-lived automation, prefer features available across your supported baseline rather than continually branching around version-specific options.

OpenSSL 3.0, 3.5, and 4.0 differences

The core command structure remains:

openssl command options

across OpenSSL 3.0, 3.5, and 4.0.

But the available command set evolves.

OpenSSL 3.0

OpenSSL 3.0 introduced the modern provider architecture and deprecated several older interfaces.

For example, the following openssl list options were already deprecated in OpenSSL 3.0:

-engines
-digest-commands
-cipher-commands

OpenSSL recommends the algorithm-oriented replacements where applicable.

OpenSSL 3.5 LTS

OpenSSL 3.5 expands the provider and algorithm inventory capabilities.

For example, the openssl list documentation notes that:

-skey-managers

was added in OpenSSL 3.5.

This is a good example of why a script targeting OpenSSL 3.0 through 4.0 should not assume every option documented in the 3.5 manual exists on the minimum supported version.

OpenSSL 4.0

OpenSSL 4.0 removes additional deprecated legacy functionality.

One documentation-related change is particularly relevant to this article: OpenSSL 3.0 deprecated the old unprefixed command manual-page aliases in favor of names such as:

openssl-x509
openssl-req
openssl-dgst

The openssl-cmds documentation states that the unprefixed manual-page entries were scheduled for removal in OpenSSL 4.0.

For documentation and automation intended to survive the OpenSSL 3-to-4 transition, prefer current command and manual-page naming conventions.

Commands versus algorithms

An important distinction is that an OpenSSL command is not necessarily the same thing as an available cryptographic algorithm.

For example:

openssl list -commands

lists applications such as:

x509
req
verify
dgst
pkey

While:

openssl list -digest-algorithms

lists algorithms such as:

SHA256
SHA384
SHA512

And:

openssl list -cipher-algorithms

lists cipher implementations.

This distinction matters with OpenSSL 3 because algorithm implementations are often supplied by providers.

A command may exist while the algorithm you want to use is unavailable.

Common OpenSSL command categories

For a system administrator, the huge command list becomes easier to understand when grouped by task.

Certificate management

x509
req
verify
ca
crl
ocsp

Use these for:

  • inspecting certificates;
  • creating CSRs;
  • validating certificate chains;
  • operating a basic CA;
  • managing CRLs;
  • checking revocation.

For chain validation examples, see OpenSSL Verify: Certificate, Chain, CRL, and Key Examples.

Private and public keys

genpkey
pkey
pkeyutl
pkcs8
rsa
ec

Use these for:

  • generating keys;
  • inspecting keys;
  • converting key formats;
  • performing public-key operations.

Modern procedures should generally prefer the generic genpkey and pkey interfaces where practical instead of older algorithm-specific generation commands.

Certificate and key containers

pkcs7
pkcs8
pkcs12
cms

These manage commonly encountered PKI formats and cryptographic message structures.

TLS troubleshooting

s_client
s_server
s_time
ciphers

Of these, s_client is one of the most valuable commands for administrators because it can connect directly to TLS services and expose certificate-chain and handshake information.

See OpenSSL s_client Commands and Examples.

Data inspection

asn1parse
storeutl

asn1parse is particularly useful when troubleshooting malformed or unfamiliar PKI structures.

See OpenSSL asn1parse: Decode Certificates and ASN.1 Data.

Trust-store management

rehash
verify

Use rehash to prepare hashed CApath directories and verify to test trust relationships.

See OpenSSL rehash.

Certificate authority operations

ca
ocsp
crl

OpenSSL can also be used to operate a small test certificate authority.

For a practical lab example, see How to Create a Private CA with OpenSSL CA.pl.

Deprecated does not mean immediately removed

OpenSSL documentation may describe a command or option as:

deprecated

That does not necessarily mean it stops working immediately.

It means administrators should avoid designing new processes around it when a supported replacement exists.

Examples from modern OpenSSL documentation include older command interfaces being superseded by more general commands.

For scripts that need to survive future OpenSSL upgrades:

  1. check whether a feature is deprecated;
  2. identify the documented replacement;
  3. test the replacement on your minimum supported OpenSSL version;
  4. migrate before the older interface is removed.

Common troubleshooting situations

“Invalid command”

First list commands:

openssl list -1 -commands

Search for the command:

openssl list -1 -commands | grep -Fx command_name

Then check:

openssl version -a

The command may not exist in that version or build.

“Unknown option”

Display the installed command’s help:

openssl command -help

For example:

openssl verify -help

Do not assume options from OpenSSL 3.5 documentation exist on OpenSSL 3.0.

Algorithm unsupported

Check loaded providers:

openssl list -providers

Then query the relevant algorithms:

openssl list -cipher-algorithms

or:

openssl list -digest-algorithms

The problem may be provider availability rather than command availability.

Works as root but not as another user

Check:

command -v openssl
openssl version -a
env | grep '^OPENSSL'

Different users may have:

  • different PATH values;
  • different configuration variables;
  • different OpenSSL installations;
  • different permissions on provider modules or configuration files.

Works interactively but fails in a service

A systemd service, container, cron job, or application may run with a different:

PATH
OPENSSL_CONF
OPENSSL_MODULES
working directory
user account

Use absolute executable paths in automation where consistency matters:

/usr/bin/openssl version

Useful OpenSSL discovery commands

For everyday administration:

# Version
openssl version
# Detailed version and build data
openssl version -a
# General help
openssl help
# List commands
openssl list -1 -commands
# Help for one command
openssl x509 -help
# List loaded providers
openssl list -providers
# List disabled build features
openssl list -disabled
# List digest algorithms
openssl list -digest-algorithms
# List cipher algorithms
openssl list -cipher-algorithms
# List public-key algorithms
openssl list -public-key-algorithms
# List signature algorithms
openssl list -signature-algorithms
# Display options accepted by a command
openssl list -options x509

A useful OpenSSL server inventory script

When troubleshooting an unfamiliar Linux server, create a quick inventory:

#!/usr/bin/env bash
set -u
echo "=== Executable ==="
command -v openssl
echo
echo "=== Version ==="
openssl version -a
echo
echo "=== Providers ==="
openssl list -providers
echo
echo "=== Disabled Features ==="
openssl list -disabled
echo
echo "=== Commands ==="
openssl list -1 -commands

Save it as:

openssl-inventory.sh

Run:

chmod +x openssl-inventory.sh
./openssl-inventory.sh

This gives you a useful baseline before troubleshooting certificate or cryptographic problems.

Do not publish the complete output without reviewing it first. Build paths, configuration locations, provider locations, host-specific information, or other environmental details may be visible.

Security and privacy considerations

OpenSSL discovery commands are generally safe because they do not modify certificates or keys.

However, command output can disclose details about the environment, including:

  • filesystem paths;
  • custom OpenSSL installation locations;
  • provider names;
  • FIPS configuration;
  • build information;
  • software versions;
  • configuration directories.

Before placing output in:

  • a public GitHub issue;
  • a vendor ticket;
  • a blog post;
  • a screenshot;
  • a forum;
  • an AI prompt;

review the output and replace environment-specific information with generic placeholders where appropriate.

Never include:

  • private key contents;
  • passwords;
  • passphrases;
  • production hostnames;
  • internal domain names;
  • personal usernames;
  • private certificate data that should not be disclosed.

Frequently asked questions

How do I list all OpenSSL commands?

Run:

openssl list -commands

For one command per line:

openssl list -1 -commands

How do I get help for an OpenSSL command?

Add -help to the command:

openssl x509 -help

Replace x509 with the command you want to inspect.

How do I check my OpenSSL version?

Run:

openssl version

For build and installation information:

openssl version -a

How do I see which OpenSSL providers are loaded?

Run:

openssl list -providers

For more detail:

openssl list -providers -verbose

How do I list supported OpenSSL ciphers?

To list cipher algorithms:

openssl list -cipher-algorithms

For TLS cipher-suite troubleshooting, the separate openssl ciphers command is usually more appropriate.

How do I list OpenSSL digest algorithms?

Run:

openssl list -digest-algorithms

How do I see which features were disabled?

Run:

openssl list -disabled

This reports features that were disabled when the OpenSSL installation was built.

Why does an OpenSSL command work on one server but not another?

Common causes include:

  • different OpenSSL versions;
  • different OpenSSL executables;
  • different build options;
  • different providers;
  • different OpenSSL configuration;
  • operating-system cryptographic policies;
  • command or option deprecation;
  • features compiled out of one build.

Start by comparing:

openssl version -a
openssl list -providers
openssl list -disabled
openssl list -1 -commands

Does openssl-cmds run as a command?

No.

You do not normally run:

openssl cmds

openssl-cmds is the name of an OpenSSL manual page that documents the collection of OpenSSL application subcommands. The installed command list can be obtained with:

openssl list -commands

Related OpenSSL guides

External references

Conclusion

The OpenSSL command list is not just a reference for memorizing command names.

For system administrators, it is a way to determine what an OpenSSL installation is actually capable of before modifying a certificate, debugging TLS, or deploying automation.

Start with:

openssl version -a
openssl list -1 -commands
openssl list -providers
openssl list -disabled

Then inspect the command you intend to use:

openssl command -help

For example:

openssl s_client -help

This approach is especially useful when supporting OpenSSL 3.0 through OpenSSL 4.0 because commands, individual options, providers, algorithms, and deprecated interfaces can differ between releases.

Rather than assuming two machines have identical OpenSSL capabilities, ask each installation directly.

That simple habit can save considerable time when diagnosing scripts that work on one server but fail on another.

Reader Interactions

Leave a Reply

Your email address will not be published. Required fields are marked *