step CLI: X.509 work, a step-ca client, and a plugin path

step ships as a client, so the CA question comes first

Most certificate tooling assumes you already have a certificate authority, or already have OpenSSL. step takes a different position: the same binary that creates and lints certificates is also the client for a step-ca server, and the same binary handles JWT signing, TOTP tokens, password hashing and OAuth token retrieval.

That bundling is the point. An engineer setting up development HTTPS for the first time has to touch OpenSSL config files, a CSR, a CA, and a trust store, and the failure at each step is opaque.

The audience is narrow and worth naming. These are people who already know what a certificate chain is, and who want issuance and renewal as a scriptable operation rather than a workflow. Someone who has never read an RFC5280 field will get little help from the CLI itself, since the reference documentation assumes the vocabulary. Note also that step-ca is a separate repository; step does not contain a CA, it talks to one.

Certificate groups that read and write files on disk

The step certificate group is the densest part of the tool. It creates, revokes, validates, lints and bundles X.509 certificates, installs them into a system and browser trust store, and creates root and intermediate CA certificates. Keys can be RSA, ECDSA or EdDSA, and the tool both creates CSRs and signs them.

Two mechanisms matter for a decision. First, linting is not a shell wrapper around an external tool: the module list pins smallstep/zlint at a pseudo-version, so the CA/Browser Forum rules compiled into a given step build are fixed at the commit that dependency was pinned, and upgrading the CA baseline means upgrading the binary.

Second, trust store installation touches the host. Putting a root certificate into a system and browser trust store is the fastest way to make a development certificate work in a browser, and also the fastest way to break one. step removes them again through the same group, so the operation is reversible.

http-01 support narrows what the ca group can automate

The step ca group administers a step-ca server, or any CA server that speaks ACMEv2 as specified in RFC8555, the protocol behind Let's Encrypt. It can initialise an X.509 and an SSH CA in one command, obtain a certificate through any enrollment mechanism step-ca supports, distribute the root certificate, renew and revoke, and submit CSRs for signing.

The limit is worth stating plainly. With an ACME CA, step supports the http-01 challenge type. That means DNS-01 validation is not covered by the documentation for this client, and an operator whose DNS provider is the only place they can publish a token has to reach for something else to solve that step.

The group also mixes administrative and consumer actions in one namespace. Reading help output for the group as a whole is less useful than reading it per subcommand.

Any command can be replaced by a step-<name>-plugin executable

step extends itself through its filesystem rather than through a plugin registry. A plugin is an executable file named using the format step-<name>-plugin. It must be on the PATH, or in the plugins directory, which is $STEPPATH/plugins and defaults to $HOME/.step/plugins. Running step <name> then executes the matching executable automatically.

This is a small design: a team can drop a correctly named executable on the PATH or in $STEPPATH/plugins and run it as step <name>.

The repository hands installation to an external page

There is no install command anywhere in this repository's README. Installation is delegated to the project's documentation at https://smallstep.com/docs/step-cli/installation. If you are evaluating the tool, that page is the first thing to open.

For a Go 1.26 toolchain the source route is straightforward. The module declares its path and version requirement at the top of the file:

module github.com/smallstep/cli

go 1.26.0

Building from a checkout goes through the Makefile, which names the output binary, the build output directory and the install path as overridable variables, so a packager can redirect DESTDIR without patching anything:

BINNAME?=step

PREFIX?=bin

DESTDIR?=/usr/local/bin

Prebuilt packages are the other route, and the repository layout shows debian/, docker/, powershell/ and systemd/ directories, so packaging for each target is maintained in-tree.

A v0.31.0 release built against certificates v0.30.2

Here is the detail a skim misses. The most recent release tag is v0.31.0, published 2026-09-25. The module requirement in go.mod points at a slightly older server library:

github.com/smallstep/certificates v0.30.2

The CLI and the CA it talks to are released on separate schedules and pinned independently, so a step-ca newer than v0.30.2 will be a newer protocol surface than the client library the CLI was compiled against. That gap is exactly what to check before pointing a new CLI at an existing CA.

The pinned lint rules show the same pattern at a smaller scale:

github.com/smallstep/zlint v0.0.0-20220930192201-67fb4aa21910

A lint rule added to the CA/Browser Forum baseline after that commit is not in your binary until you rebuild.

On maintenance, the last push to master was on 2026-11-02 and the project ships release candidates alongside finals, so the release channel moves often. The code is Apache-2.0 licensed, which in practical terms means you can run and modify the client inside a closed product without publishing your own changes to it.

Where step stops and OpenSSL starts

The real alternative is not a competing tool, it is OpenSSL. OpenSSL is a library and a general command set that assumes nothing about where your authority lives, and it works on a certificate with no server, no config layout and no network. step is opinionated: it assumes a $STEPPATH, it assumes JWK or PEM material in known places, and its ssh group is unavailable without an online or offline step-ca instance.

That dependency is the failure mode to plan for. A laptop with a work root certificate and no reachable CA can still lint, create and bundle locally, and cannot renew. Vault, if it is in your stack, is the other comparison worth making: it stores secrets and issues from its own engine, so step sits beside it as a client rather than competing for the same job.

Choose step for issuance workflows around step-ca. Choose OpenSSL for one-off certificate surgery on a host where running a CA client is not possible.

Editorial conclusion

Adopt step when you run smallstep's own CA and want issuance, renewal and revocation from a laptop or a CI job. Do not adopt it as a general crypto toolbox, and do not expect the ssh group to work without an online or offline step-ca instance. Verify first what version your step-ca speaks and whether your existing certs pass step certificate lint, since the lint rules travel inside the binary as a pinned zlint commit.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. Project website
3. README
4. Releases
5. smallstep/cli on GitHub