easy-rsa: a shell-based CA utility for OpenVPN-style PKI

What easy-rsa solves, and who it is for

The README states that easy-rsa is a CLI utility to build and manage a PKI CA, which in its own words means creating a root certificate authority, requesting and signing certificates including intermediate CAs, and producing certificate revocation lists. That is the whole scope. It does not run a network service, it does not store certificates in a database, and it does not manage the lifecycle of the machines that hold the keys.

The audience is narrow and specific. If you run OpenVPN and need to issue a certificate per client, easy-rsa is the tool that ships alongside that ecosystem, and the README says development co-exists with OpenVPN even though they are separate projects. It also fits any service that consumes standard X.509 material and where an operator is willing to run shell commands. If you want a certificate authority that a web application can call over HTTP, this is the wrong shape of tool.

How the shell scripts drive OpenSSL

easy-rsa is a set of shell scripts that wrap OpenSSL invocations. The repository keeps the working code under easyrsa3/, with documentation in doc/ and README.quickstart.md, and the top level also holds ChangeLog, KNOWN_ISSUES and a Licensing/ directory. The README states that the project attempts to adhere to the POSIX standard, which is why the same scripts can run on Linux, macOS and Windows under a POSIX shell.

The state of your CA lives in a directory tree, not in a daemon. The scripts read a configuration file (vars) for defaults such as key size and the distinguished name fields, then call OpenSSL to generate keys, build a certificate signing request, and sign it with the CA key. Revocation writes to the CRL through the same OpenSSL machinery. Because everything is files on disk, backup and audit are ordinary filesystem operations, and the security of the CA reduces to the permissions on the CA private key.

The README is explicit that master is a rolling branch: it may be broken at any time, and it recommends using a release. That is a real operational constraint, not a footnote. Pin a tag.

Installing easy-rsa on Ubuntu, Debian or Windows

The README points to the GitHub releases section for release downloads and notes that releases are also available as source checkouts using named tags. It does not publish a package manager command, so the reliable path is to take a release and run the scripts from the checkout.

A source checkout of a release tag gives you the tree to work in:

git clone https://github.com/OpenVPN/easy-rsa.git
cd easy-rsa/easyrsa3

Inside easyrsa3/ the entry point is the easyrsa script. The quickstart document is the place to read before running it, and the README names README.quickstart.md and the doc/ directory as the 3.x documentation. On Windows the same scripts run under a POSIX shell, which is why the repository carries wop-test.bat and wop-test.sh alongside the Unix op-test.sh; the README does not describe a native Windows installer.

Once you have a checkout, the first real operation is initialising a PKI directory and building the CA. The exact command set is documented in README.quickstart.md rather than in the README itself, so read that file before you type anything, then keep the resulting pki/ directory out of version control.

Where easy-rsa is the wrong tool

The most direct limitation is the one the README states about branches. The 3.0.6, 3.0.5, 3.0.4 and release/3.0 branches are marked as not compatible with OpenSSL version 3, and release/2.x and release/1.x are archived or unmaintained. If your distribution ships OpenSSL 3 and you are running an old easy-rsa branch, you are on a combination the project has declared incompatible. Check the branch before you debug anything else.

Second, this is an operator-driven tool. There is no API, no scheduler and no automatic renewal. If a certificate expires because nobody ran the scripts, easy-rsa will not warn you. That is a design choice consistent with a POSIX shell utility, but it means the surrounding process is yours to build.

Third, the CA private key is a file on the machine where you run the scripts. Anyone with read access to that file can mint certificates for your PKI. The README offers no guidance on hardware tokens or offline signing ceremonies, so if your threat model requires a CA key that never touches a general-purpose filesystem, easy-rsa is not the layer that provides it.

easy-rsa compared with calling OpenSSL directly

The alternative most people weigh against easy-rsa is OpenSSL itself. The difference is not cryptographic capability, since easy-rsa is a wrapper over the same library. The difference is that OpenSSL exposes a large set of subcommands, flags and config file directives, and every PKI operation becomes a sequence you assemble and remember. easy-rsa fixes that sequence into named scripts with sane defaults, so issuing a client certificate is one invocation rather than a hand-built openssl req followed by openssl ca with the right -config, -extensions and database arguments.

A hosted or service-oriented CA is the other direction. Those systems typically expose an API and handle issuance programmatically, which easy-rsa deliberately does not do. The trade-off is control against automation: easy-rsa gives you a small, readable, offline-capable set of scripts you can audit line by line, and in exchange you own the operational discipline around it.

The README does not compare easy-rsa to any other CA tool, so any claim about feature parity would be guesswork. The honest summary is that easy-rsa is the OpenSSL workflow with the sharp edges filed down and the steps named.

Maintenance, releases and licence status

The last push to the repository was on 2026-09-19, the same day as the v3.2.7 release. The preceding releases were v3.2.6 on 2026-03-13 and v3.2.5 on 2025-12-13, so the cadence over the past year has been roughly one release per quarter with the most recent arriving in September. The repository is not archived.

Upgrade cost is low in the normal case because the scripts are self-contained and the CA material is just files. Moving between 3.2.x releases means replacing the checkout while keeping the pki/ directory. The README does not document a rollback procedure, so keep a copy of the CA directory before you swap versions.

The licence situation needs care. The repository metadata reports the licence as NOASSERTION, meaning GitHub could not classify it automatically, and the README directs readers to COPYING.md for 3.x licensing information, with a Licensing/ directory at the top level. Read those files yourself and have whoever handles licensing at your organisation sign off. Version 3.x and the older 1.x and 2.x branches may not carry the same terms, so do not assume the licence of a release you used years ago still applies to the current one.

Editorial conclusion

Adopt easy-rsa if you run OpenVPN or another OpenSSL-based service and want a CA you can read end to end in shell. Do not adopt it if you need a hosted CA with an API or automatic certificate rotation. Before committing, read README.quickstart.md and doc/ for your platform, check that your OpenSSL is version 3 compatible since the README lists older 3.0.x branches as not compatible with OpenSSL 3, and confirm that the release you pin is the one you intend to run rather than master.

Frequently asked questions

Official sources

1. Issues
2. OpenVPN/easy-rsa on GitHub
3. README
4. Releases